פיתוח אפליקציית מובייל לבוט מסחר ל-iOS ול-Android

מדוע אפליקציית המובייל של בוט המסחר מפסידה עסקאות

הלקוח מתחבר לזרם הציטוטים דרך ממשק הבורסה Binance, אך בין הגעת המחיר לבין הופעתו על המסך עומדים ערוץ התקשורת, פירוק הזרם בטלפון עצמו ורינדור מחדש של הרשימה.

בשוק שקט ההשהיה בציטוטים בלקוח אינה מורגשת, ובתנועה חדה היא גדלה לשניות — הסוחר רואה מחיר שכבר אינו קיים ומקבל החלטה על סמך תמונה מיושנת.

צוואר הבקבוק השני — רגע הכניסה. בזמן שהאפליקציה מדביקה את השוק, האות כבר מומש, הכניסה לפוזיציה הוחמצה, והעסקה יוצאת במחיר גרוע באופן ניכר מהמחיר המחושב.

גרוע מכך הוא מצב שבו תגובת הבורסה לא הגיעה: שליחה חוזרת של פקודה בלי בדיקת מצב החשבון יוצרת שתי פוזיציות במקום אחת, וטיפול ידני בפקודות מיותרות אוכל את הזמן שהיה בדיוק הקריטי.

סוג הכשל השלישי — הממשק עצמו. בתנודתיות תדירות העדכונים גדלה פי כמה, רשימת הפקודות מתרנדרת מחדש במלואה, והלקוח קופא: הכפתורים לא מגיבים, הסטופ לא מוצב, והמשימה ברקע ממשיכה לחשב לפי נתונים שכבר אינם נכונים. בהמשך נפרט כיצד זה נסגר — מתרשים הסקר ועיבוד הזרם ועד אישור העסקאות.

מה משתנה לאחר ההשקה: מהירות, יציבות, שליטה

את האפקט של לקוח שעובד מחדש רואים לא במצגת אלא בשלושה מדדים שנמדדים בחשבון אמיתי.

את זמן התגובה של הממשק — מהלחיצה ועד אישור הפעולה — אנו מודדים בערוץ חלש ובתנודתיות גבוהה: לאחר העבודה מחדש הוא מפסיק להיות תלוי בעומס של הפלטפורמה, משום שתצוגה מקדימה של הפקודה, חישוב המינוף והבדיקות מחושבים מקומית, ולליבת המסחר נשלחת פקודה מוכנה. המשתמש מקבל תגובה לפני שהוא מספיק ללחוץ שוב.

שיעור הפקודות הנדחות יורד לא מעצמו, אלא משום שהלקוח יודע מראש את כללי הפלטפורמה: צעד המחיר, הנפח המינימלי, דרישות המרווח ומשקל הפקודה נבדקים לפני השליחה. פקודות כאלה נדחו בעבר בצד הבורסה והפכו לשגיאה בלתי מובנת למשתמש.

סוג כשל נפרד — שליחה בקישוריות לא יציבה. מפתח אידמפוטנטי של הפקודה ותור מקומי של פעולות שאינן מאושרות מצמצמים את התוצאה לשתי אפשרויות: הפקודה התקבלה או שהיא בוודאות לא נשלחה. המצב «שלחנו אבל איננו יודעים» נעלם יחד עם כפילויות של פוזיציות.

בעת ניתוק הקשר הפוזיציה נשמרת: הלקוח משחזר את התמונה לפי היומן המקומי, משלים אירועים שהוחמצו וממשיך להציג נפחים מעודכנים. הפוזיציות הפתוחות ופקודות הסטופ נשארות בצד הבורסה ולא בתוך האפליקציה — אובדן רשת, מזעור הלקוח או מעבר בין רשתות אינם הופכים לטיפול ידני בעסקאות. מערך כזה בדקנו בפלטפורמות כמו Binance, כולל ניתוקים כפויים של החיבור בזמן פוזיציה פעילה.

מצבי עבודה: הזנה ידנית, אותות, מסחר אוטומטי

הלקוח של בוט המסחר הוא שלט שליטה לליבת המסחר, ולא מבצע עצמאי: המצב נקבע לפי מדיניות בצד השירות, האפליקציה מעבירה פקודות ומציגה את מצב הפוזיציות. לכן המצב נבחר לא «לכל האפליקציה» אלא לכל אסטרטגיה בנפרד — ומשתנה בלי להתקין מחדש את הלקוח.

מתי איזה מצב

המצבים תואמים זה לזה: מעבר ממצב צל למצב מבצעי הוא החלפת מדיניות ולא בנייה מחדש. אפשר להשאיר אישור ידני של פקודות פעיל גם במסחר אלגוריתמי — למשל רק עבור פקודות מעל גודל מוגדר.

אמצעי הביטחון זהים בכל המצבים: גודל פוזיציה מרבי, מספר עסקאות יומי, עצירת האסטרטגיה כאשר המחיר סוטה מהמצופה ויומן של כל החלטה. הדבר מאפשר להשיק לוגיקה חדשה בהדרגה, בלי לחשוף את כל ההון בבת אחת.

סדר העבודה: מביקורת אינטגרציות ועד מסירת גרסאות

העבודה מתנהלת בשלבים, וכל שלב נסגר בתוצר שאפשר לבדוק לפני המעבר הלאה. סדר כזה מסיר את הסיכון העיקרי: לגלות בהדגמה הסופית שלוגיקת המסחר באפליקציה סוטה מאופן ביצוען בפועל של הפקודות בפלטפורמה.

1. ביקורת אינטגרציות. אנו עורכים מיפוי של הפלטפורמות והרשתות, סוגי הפקודות, מגבלות תדירות הבקשות, הרשאות המפתחות ומקומות אחסון הסודות. בתוצר — מטריצה «תרחיש — מקור נתונים — מגבלה» ורשימת צווארי בקבוק שאנו מסירים לפני הפיתוח.
2. תרשים זרמי הנתונים. אנו מגדירים מה נחשב למקור האמת: זרם הציטוטים, סטטוסים של פקודות, יתרות. קובעים היכן המטמון, כיצד האפליקציה שורדת אי-התאמה של נתונים ותגובה חוזרת של הפלטפורמה.
3. מערך הדגמה. אנו מקימים סביבת ארגז חול של הפלטפורמה ורשתות בדיקה, מחברים אליהן את האפליקציה ומריצים תרחישי מסחר בלי כספים אמיתיים — בשלב זה רואים את התנהגות המערכת בשלמותה.
4. בניית האפליקציה. אנו מממשים את הממשק, המשימות ברקע וההתראות, ומוציאים גרסאות פנימיות ל-iOS ול-Android באיטרציות, כדי שהתיקונים ייבדקו במערך חי ולא על סקיצות.
5. בדיקות קבלה. אנו מריצים כשלים: ניתוק הקשר ברגע שליחת הפקודה, כפילות, ביצוע חלקי, הפעלה מחדש של האפליקציה. כל תרחיש נרשם בפרוטוקול — מה צפינו ומה התקבל.
6. מסירת גרסאות והרשאות גישה. אנו מוסרים גרסאות חתומות, מפתחות חתימה, קונפיגורציות של סביבות, גישות לחנויות האפליקציות ותקנון לשחרור עדכונים, כדי שצוות הלקוח יוכל לפתח את המוצר בעצמו.

מה אנחנו מוסרים לידיים: קונפיגורציות, תרשימים, תקנונים

אנחנו מוסרים לא «קוד שעובד» אלא ערכה שלפיה הצוות שלכם — או קבלן אחר — יוכל לבנות, לשחרר ולתחזק את האפליקציה בלעדינו. כל תוצר נבדק בקבלה: אם לפיו אי אפשר להקים מערך ולנתח תקרית מאפס, העבודה לא נסגרה.

• קונפיגורציה של סביבות — תיאור מערכי הפיתוח, הבדיקות והעבודה, רשימה מלאה של משתנים ותבניות להקמה מאפס. הסודות נמצאים בנפרד מהקוד, וההרשאות לאחסון נשארות בידיכם.
• תרשים האינטגרציה עם הבורסה — רצף הקריאות, פורמטי ההודעות, טיפול בניתוקי חיבור, מגבלות בקשות והלוגיקה של ניסיונות חוזרים. ברשימה נפרדת — תרחישים שכבר נבדקו בזרם ציטוטים חי.
• מדיניות גישה לחשבונות — מפתחות מסחר בלי הרשאת משיכת כספים, מפתחות נפרדים למסחר ולמשימות תפעוליות, סדר רוטציה והענקת גישות לעובדים חדשים.
• תקנון שחרור גרסאות — כיצד נבנית הגרסה, אילו בדיקות עוברות לפני הפרסום, כיצד היא מופצת לחלק מהמשתמשים וכיצד חוזרים לגרסה קודמת בחנויות.
• הוראות לצוות התמיכה — פניות אופייניות: הציטוטים לא מתעדכנים, הפקודה נדחתה, היתרה אינה תואמת. לכל אחת: סימנים, מה לבדוק והיכן גבול ההסלמה לפיתוח.
• מדדים וספי התראות — מה להסתכל בגרפים, באילו ערכים מופעל האות ולמי הוא מגיע.
• מסמכים לבנייה ולפרסום — חתימות, תעודות, גישות לחשבונות המפתחים וסדר שחרור העדכונים.

הערכה נאספת למאגר אחד עם ניהול גרסאות, ולכן בעת החלפת קבלן אין צורך לשחזר את ההקשר מהתכתבות. חודש לאחר המסירה אנו מקיימים העברת ידע עם המהנדסים שלכם ועונים על שאלות בכל סעיף.

מקרה בוחן: כיצד הסרנו אובדן פקודות בשיא התנודתיות

הלקוח — צוות למסחר אלגוריתמי — הגיע עם תלונה שקשה לתפוס במערך בדיקות: בשוק שקט האפליקציה עבדה כשורה, ובתנועות חדות חלק מהפקודות לא הגיע.

הפעלנו מונים בצד האפליקציה והשווינו אותם ליומן העסקאות: בשעות שיא של חצי שעה עד 7% מהפקודות נדחו או אבדו בשליחה, והאות מהאסטרטגיה ועד לפקודה שהוצבה לקח שנייה וחצי עד שתיים — בתנועת מחיר מהירה זה מספיק כדי שהכניסה תהפוך להפסדית.

הניתוח חשף שלוש סיבות. החיבור לשער הבורסה Binance הוקם רק כשהמסך היה פעיל ונסגר כשהאפליקציה עוברת לרקע. תור הפקודות היוצאות חי בזיכרון ונעלם בעת הפעלה מחדש. השליחה החוזרת לא הייתה אידמפוטנטית: בתגובה בלתי ודאית הפקודה או שוכפלה או נעלמה בשקט.

מה שינינו ומה יצא

את החיבור העברנו למצב רקע בשתי הפלטפורמות, ואת התור — ליומן מקומי: הפקודה נרשמת במכשיר לפני השליחה ומקבלת מפתח שלפיו הבורסה מסננת כפילות. בעת ניתוק הקשר השליחה מתחדשת אוטומטית, ומצב הפוזיציות משוחזר מהיומן ולא מהזיכרון של התהליך.

זמן התגובה לאות הצטמצם לעשיריות השנייה, וההשבתה בתנועה חדה בשוק — מלמעלה מדקה למספר שניות של התחברות מחדש.

התוצאה בשני חודשי תצפית: שיעור הפקודות הנדחות בתקופות שיא ירד מ-7% ל-0.2%, ולא נותרו אותות שהוחמצו במעבר בין אינטרנט סלולרי ל-Wi-Fi. בנוסף הוספנו יומן אי-התאמות, שמשווה רשומות מקומיות להיסטוריית העסקאות ומסמן אי-התאמות — כעת כשלים כאלה נראים לפני שהם הופכים להפסדים.

במה נבדל לקוח נייטיבי מלקוח חוצה-פלטפורמות?

עבור בוט מסחר השאלה אינה באופנה טכנולוגית אלא במה שהלקוח חייב לעשות ברגע האות. אם ההתראה מגיעה באיחור או לא מגיעה כשהאפליקציה סגורה, הכניסה לפוזיציה מתרחשת במחיר אחר — וההיגיון של האסטרטגיה מאבד את משמעותו.

פיתוח נייטיבי לשתי פלטפורמות נותן גישה ישירה להתראות מערכת ולמשימות רקע: הלקוח מקבל אירוע מזרם הציטוטים, יעיר את המכשיר, יציג התראה ויבצע את התרחיש לפי כללי הפלטפורמה. תגובת הממשק נשארת יציבה בזרם נתונים צפוף, והעדכונים יוצאים כשהפלטפורמה משנה את כללי העבודה ברקע.

בסיס קוד אחיד מנצח במקום שבו השרת מחשב והאפליקציה מציגה מצב ומאשרת פעולות: מהירות שחרור העדכונים גבוהה יותר, ותמיכה בשתי פלטפורמות דורשת פחות עבודה. המגבלה — ההתנהגות של משימות רקע והתראות מערכת שונה בכל פלטפורמה, וחלק מהתרחישים בכל זאת נסגרים במודול נייטיבי.

לכן את הבחירה עושים לפי פרופיל העומס: באיזו תדירות מגיעים האותות, האם הבוט צריך לעבוד כשהאפליקציה סגורה, והאם השהיה של כמה שניות קבילה. היברידי הוא פשרה עובדת, אך כדאי להטמיע אותו מלכתחילה ולא כשינוי בהול.

מה מבררים המהנדסים לפני תחילת העבודה

ניתוק החיבור בזמן פוזיציה פתוחה הוא התרחיש הנפוץ ביותר ששובר תרשים נאיבי: הרשת מאבדת את הערוץ, האפליקציה עוברת לרקע, הטלפון מתרוקן. לכן את מצב הפוזיציה ואת פקודות ההגנה מחזיקים בצד השרת, ואת הטלפון משאירים כלקוח דק — הוא מקבל תמונת מצב ושולח פקודות, אך אינו מחזיק את לוגיקת המסחר.

לוגיקה סגורה של אלגוריתם מפורקת לכללי «תנאי — פעולה» ומתועדת במפרט, כדי שאפשר יהיה לשנותה בלי לבנות מחדש את האפליקציה. בדיקת החישובים לפני עסקאות אמיתיות מתבצעת בשלב נפרד: תחילה הרצה על נתונים היסטוריים, ואחר כך מערך בדיקה עם השוואה של אותות, נפחים וסטיות במחיר הביצוע.

כיצד לוודא שהלוגיקה הסגורה של האלגוריתם הועברה נכון?

כללי הכניסה והיציאה מועברים למפרט כצמד תנאים ופעולות, ואת הנכונות מאשרים בדוח עסקאות שבו החישוב מושווה להתנהגות המצופה. בנפרד אנו בודקים תרחישים נדירים: מחסור בנזילות, פער מחיר חד, ביטול פקודה. המפרט והתיעוד נשארים בידי המזמין — את התחזוקה אפשר להעביר לצוות אחר.

האם אפשר לחבר בהמשך פלטפורמת מסחר שנייה?

כן, אם מלכתחילה הופרדה שכבת ביצוע: כללי האסטרטגיה אינם תלויים בפלטפורמה מסוימת, וההבדלים — פורמט הפקודות, גובה העמלה, הזוגות הזמינים — נסגרים במודול נפרד. חיבור של פלטפורמה שנייה אז אינו נוגע בממשק ובלוגיקת החישוב.

בואו נדון במשימה: מה נדרש מכם לצורך הערכה

כדי שההערכה תתבסס על היקף עבודה אמיתי ולא על מילים כלליות, אנו זקוקים לנתוני פתיחה בארבעה נושאים: היכן הבוט סוחר, כיצד הוא מקבל החלטות, מה רואה הלקוח באפליקציה ובאיזו סביבה אנו בודקים את הלוגיקה לפני היציאה לחשבון אמיתי.

• גישות לחשבונות מסחר — מפתחות בדיקה עם הרשאות למסחר בלבד, בלי משיכת כספים, וחשבון אחד שאפשר להריץ עליו את האסטרטגיה בבטחה.
• תיאור תרחישי המסחר — כלים ומרווחי עבודה, תנאי כניסה ויציאה, גודל הפוזיציה, התנהגות הבוט בניתוק קשר ובתנועה חדה בשוק.
• דרישות לממשק הלקוח — אילו מסכים נדרשים, מה מציגים במסך הראשי (פוזיציות פתוחות, היסטוריית עסקאות, תשואה), האם נדרשים השהיה ידנית, סגירת פוזיציה והתראות מיידיות.
• מערך לבדיקות — סביבת בדיקה של הבורסה, גישה להיסטוריית ציטוטים לתקופה הנדרשת ומגבלות ברורות על תדירות הבקשות.
• כללי ניהול סיכונים — פוזיציה מרבית, סטופ יומי לפי הפסד, ומה עושה הבוט לאחר סדרה של עסקאות כושלות.
• עומס ותפקידים — כמה חשבונות ומשתמשים עובדים במקביל, והאם נדרשות הרשאות שונות לבעלים ולצופה.
• מגבלות לפי פלטפורמות — לאילו גרסאות iOS ו-Android אנו בונים, והאם נדרשים כניסה ביומטרית ועבודה ברקע של האפליקציה.

זה מספיק כדי לחזור עם הערכה ותוכנית: תרשים הקשר בין האפליקציה לבורסה, השלבים, הרכב הגרסה הראשונה וסדר הבדיקות לפני ההשקה בחשבון אמיתי. תארו את המשימה בצורה חופשית — נברר את החסר ונשלח תוכנית עבודה.