אנחנו מפתחים יישומי מסחר ניידים כבר למעלה מ-5 שנים והשלמנו למעלה מ-30 פרויקטים עם אינטגרציית נתונים בזמן אמת. אחד הרכיבים התובעניים ביותר הוא ספר ההזמנות (Order Book). הנתונים מתעדכנים כל 100 אלפיות השנייה, הרשימה יכולה להכיל עד 500 רמות מחיר, והממשק חייב להישאר מגיב גם בעומס שיא. ללא אופטימיזציה, האפליקציה קופאת כבר ב-50 רמות — והמשתמשים בורחים למתחרים. אנחנו מתמודדים עם כל האתגרים הטכניים: מבחירת פרוטוקול וסנכרון snapshots ועד וירטואליזציית רינדור וטיפול בדיוק עשרוני. צרו קשר לייעוץ על יישום ספר הזמנות מותאם לבורסה שלכם.
איך להימנע מפיגורים ברינדור ספר ההזמנות
רינדור ספר ההזמנות הוא מקור עיקרי לבעיות ביצועים. 100 רמות מחיר × עדכונים כל 100 אלפיות השנייה = 10,000 עדכונים בשנייה. במכשיר נייד, זה גורם לפיגורים ללא אופטימיזציות.
וירטואליזציה היא הטכניקה המרכזית. אנחנו מציגים רק רמות גלויות, לא את כל ה-100. ב-iOS — UITableView עם reloadRows(at:with:) לשורות שהשתנו, לא reloadData(). באנדרואיד — RecyclerView עם DiffUtil לחישוב שינויים מינימליים. ב-Flutter — ListView.builder עם itemCount. זה מפחית את עומס הממשק פי 2.5.
עדכונים מצטברים (Batching). אל תעדכנו את הרשימה על כל אירוע WebSocket. אנחנו צוברים עדכונים ומיישמים אותם כל 250–500 אלפיות השנייה. המשתמש לא מבחין בהבדל, והמנוע מבצע פי 2.5 פחות עבודה.
| גישה | iOS | Android | Flutter |
|---|---|---|---|
| וירטואליזציה | UITableView | RecyclerView | ListView.builder |
| עדכון | reloadRows | DiffUtil | itemBuilder |
| עדכונים מצטברים | CADisplayLink | Choreographer | Timer |
צבעים והדגשות: בירידת מחיר — רקע אדום, בעלייה — ירוק, ואז חזרה חלקה לנייטרלי. אנחנו מיישמים זאת באמצעות אנימציית צבע עם CABasicAnimation (iOS) או ValueAnimator (Android). אל תשמרו טיימרים על כל שורה — השתמשו בטיימר אחד לכל הרשימה.
מקור הנתונים: WebSocket
ספר ההזמנות של הבורסה מתעדכן דרך WebSocket — שאילתות HTTP אינן מקובלות בגלל השהיה. WebSocket מספק השהיה נמוכה פי 10+ משאילתות, וזה קריטי למסחר. גישה סטנדרטית: קבלת snapshot דרך REST, ואז הרשמה לעדכונים מצטברים דרך WS.
דוגמה ל-Binance API (תבנית בשימוש ברוב הבורסות):
GET https://api.binance.com/api/v3/depth?symbol=BTCUSDT&limit=100 → snapshot с полными bids и asks
WSS wss://stream.binance.com:9443/ws/btcusdt@depth@100ms → incremental updates каждые 100msיישום עדכונים מצטברים: אם רמת מחיר כבר קיימת בספר, עדכנו את הכמות. אם הכמות היא GET https://api.binance.com/api/v3/depth?symbol=BTCUSDT&limit=100 → snapshot с полными bids и asks WSS wss://stream.binance.com:9443/ws/btcusdt@depth@100ms → incremental updates каждые 100ms , הסירו את הרמה. אם המחיר חדש, הוסיפו אותו. זהו אלגוריתם ה-diff הסטנדרטי לספר הזמנות. תיעוד ה-API של Binance מתאר שיטה זו.
איך לסנכרן Snapshot וסטרים?
נקודה קריטית שלעיתים מיושמת לא נכון: ה-WebSocket מתחיל לשלוח עדכונים לפני ששאילתת ה-REST ל-snapshot חזרה. חייבים לאגור אירועי WS, לקבל את ה-snapshot עם 0 שלו, ואז ליישם את כל האירועים המאוגרים עם lastUpdateId. פספסתם אירוע? יצאתם מסנכרון? הדרך היחידה היא להתחבר מחדש ולקבל snapshot חדש. אל תנסו לשחזר מצב מנתונים חלקיים.
למה דיוק מספרים קריטי לספר ההזמנות?
מחירים ונפחים בבורסות הם מספרים עשרוניים בדיוק גבוה. BTC נסחר עם 8 ספרות עשרוניות. שימוש ב-firstUpdateId <= lastUpdateId + 1 מוביל לשגיאות עיגול. אנחנו משתמשים ב-Double (iOS) או Decimal (Android) לתצוגה וסיכום נכונים. השוואה: Double נותן שגיאה של עד 0.0001% על פני 1000 פעולות, בעוד Decimal נותן אפס. עיצוב: לזוגות מסחר שונים יש גדלי tick שונים (צעד מחיר מינימלי). עבור BTC/USDT גודל ה-tick הוא 0.01, עבור אלטקוינים עד 8 ספרות עשרוניות. מספר הספרות המוצגות נלקח ממטא-נתונים של הזוג, לא מקודד קשיח.
השוואת גישות סנכרון
ישנן שלוש דרכים עיקריות לסנכרן נתוני ספר הזמנות. הראשונה היא בקשות snapshot מלאות תקופתיות: פשוט ליישום, אבל יוצרת תעבורה גבוהה ומגבירה השהיה. השנייה היא הרשמה לעדכונים מצטברים דרך WebSocket: השהיה נמוכה, אבל סנכרון מורכב, במיוחד באובדן מנות. האופטימלית היא היברידית: snapshot חד-פעמי בעת החיבור, ואז עדכונים מצטברים. גישה זו דורשת אגירת אירועי WS עד קבלת ה-snapshot ותיקון סדר, אבל נותנת את האיזון הטוב ביותר בין ביצועים ואמינות. אנחנו משתמשים בזה בכל הפרויקטים — זה מפחית תעבורה פי 20 בהשוואה ל-snapshot מלא ומספק השהיית עדכון מתחת ל-50 אלפיות השנייה.
יישום סנכרון שלב אחר שלב
- יצירת חיבור WebSocket והתחלת אגירת כל ההודעות הנכנסות.
- שליחת בקשת REST לקבלת snapshot עם מזהה העדכון האחרון.
- לאחר קבלת ה-snapshot, יישום אירועים מאוגרים עם firstUpdateId <= lastUpdateId + 1.
- אם מתגלה אובדן אירועים או יציאה מסנכרון — התחברו מחדש וחזרו על שלבים 1-3.
- לאחר סנכרון מוצלח, מעבר לעיבוד סטרים בזמן אמת באמצעות אלגוריתם ה-diff.
תרשים עומק (Depth Chart)
המחישו נפחים באמצעות היסטוגרמה מצטברת (depth chart) — אנחנו צוברים נפח מהמחיר הטוב ביותר לגרוע ביותר. ציירו באמצעות BigDecimal / CAShapeLayer / Canvas ב-Flutter. עדכנו לא יותר מפעם בשנייה — זו ויזואליזציה, לא כלי מסחר.
מצב לא מקוון וחיבור מחדש
בעת אובדן חיבור, אנחנו מנקים את הספר ומציגים מצב "אין נתונים / מתחבר מחדש". אל תציגו ספר מיושן כעדכני — זה מטעה במהלך מסחר. לוגיקת חיבור מחדש: backoff אקספוננציאלי מ-1 שנייה עד 30 שניות. לאחר השחזור, אנו מביאים מחדש את ה-snapshot ונרשמים מחדש.
מה כלול
- ארכיטקטורת חיבור WebSocket עם סנכרון snapshot/עדכונים מצטברים.
- יישום רשימה וירטואלית עם עדכונים מצטברים ואנימציה.
- אינטגרציה של depth chart ועיצוב מספרים עם גודל tick.
- טיפול במצב לא מקוון וחיבור מחדש עם backoff אקספוננציאלי.
- בדיקות על נתונים אמיתיים ואופטימיזציית ביצועים.
- מסירת תיעוד וקוד מקור.
עלות וחיסכון
עלות יישום ספר ההזמנות מחושבת באופן אישי — היא תלויה במורכבות האינטגרציה, במספר זוגות המסחר ובצרכי ההתאמה האישית. בממוצע, הזמנת מודול מוכן עולה 30-50% פחות מפיתוח מאפס וחוסכת 2-4 שבועות מזמן הצוות. צרו קשר להערכת פרויקט.
אנחנו מבטיחים סנכרון נכון וממשק מגיב בכל עומס. קבלו ייעוץ — ננתח את ה-API שלכם ונציע את הפתרון האופטימלי.