המשגר מסתכל על המפה — 40 משאיות, ושלוש מהן לא עדכנו את המיקום שלהן כבר 20 דקות. האם השידור תקוע? אין רשת בהרים? או שמא האנטנת GPS כובתה בכוונה? אלה שלושה תרחישים שונים הדורשים תגובות שונות, והאפליקציה חייבת להבחין ביניהם — לא רק להפוך את הנקודה לאפורה. לצוות שלנו יש ניסיון של 5+ שנים בבניית מערכות כאלה. אנו מציעים פיתוח אפליקציות מפתח, כולל אינטגרציה עם פלטפורמות טלמטיקה פופולריות וצד שרת לעיבוד נתונים. זו לא רק מפה עם סמנים — זו מערכת בזמן אמת שבה כל נקודה מכילה מטא-דאטה: מהירות, כיוון, מצב מנוע, רמת סוללת מעקב. אם הרכב נייח יותר מ-5 דקות, המערכת בודקת אוטומטית קישוריות רשת (דופק מעקב) ומצב הצתה. רק אז אפשר להבחין בין תקלה לעצירה מתוכננת.
מה המשגר באמת צריך
אפליקציית ניטור היא לא רק "סמנים על מפה." המשגר מנהל צי של 20–200 יחידות וצריך:
- נתונים בזמן אמת עם מטא-דאטה: קואורדינטות + מהירות + כיוון + מצב מנוע + רמת סוללת מעקב
- היסטוריית מסלולים: מסלול יומי/שבועי עם כתובות עצירה מקודדות גיאוגרפית
- גיאופנסינג: התראה על כניסה/יציאה ממחסן, אתר בנייה, אזור מוגבל
- התראות: מהירות מופרזת, סרק ממושך עם מנוע דולק, סטייה מהמסלול
כל זה דורש ארכיטקטורות לקוח שונות. כבר יישמנו פרויקטים עם ציים מ-50 עד 500 יחידות, כך שאנו יודעים כיצד להגדיל את הפתרון לכל משימה.
כיצד אנו מקבלים נתוני טלמטיקה בזמן אמת
יחידות טלמטיקה (Teltonika FMB, Wialon TK, Navixy OEM) שולחות נתונים דרך TCP או GPRS לשרת. אפליקציית המובייל אינה מתחברת למעקבים ישירות — היא מקבלת את הזרם המעובד דרך WebSocket או לקוח MQTT.
תהליך קבלת הנתונים:
- המעקב שולח נתונים גולמיים לשרת דרך פרוטוקול היצרן (TCP, GPRS).
- השרת מנתח את הנתונים, מעשיר אותם במידע מטא, ומפרסם לנושא MQTT.
- אפליקציית המובייל נרשמת לנושא דרך WebSocket ומקבלת עדכונים בזמן אמת.
באנדרואיד, אנו משתמשים ב-OkHttp WebSocket עם EventBus או SharedFlow כדי לספק עדכונים ל-ViewModel. ב-iOS, URLSessionWebSocketTask (iOS 13+) או Starscream עבור יעדים ישנים יותר. עדכונים מגיעים כ-JSON או protobuf — protobuf עדיף עבור ציים גדולים: חבילה של 40 רכבים × 10 שדות ב-protobuf תופסת ~1.5 KB לעומת ~8 KB ב-JSON, חוסכת פי 5 בתעבורה. זה מפחית עלויות אינטרנט סלולרי עבור משגרים. לפי תיעוד protobuf, הפורמט הבינארי יכול להפחית את גודל הנתונים פי 3-10 בהשוואה ל-JSON.
כיצד להבטיח ביצועי מפה עם צי גדול
200 סמנים על מפה עם אנימציית תנועה זה כבר מלחיץ. פתרונות מרכזיים:
Annotations במקום שכבת SVG
ב-iOS, MKAnnotationView מתמודד עם עד ~300 סמנים ללא פיגור ניכר. מעבר לכך, אנו משתמשים ב-MKOverlay עם renderer מותאם אישית שמצייר את כל הנקודות ב-CALayer יחיד. באנדרואיד, Google Maps SDK עם MarkerOptions מתדרדר אחרי ~500 סמנים — אנו עוברים ל-Mapbox Maps SDK v10 עם SymbolLayer המבוסס על מקור GeoJSON: כל הצי מתעדכן בקריאת source.setGeoJson(featureCollection) אחת.
Clustering בצד השרת
ברמת זום < 11, אשכולות מחושבים בשרת (PostGIS ST_ClusterKMeans), והלקוח מקבל centroids מוכנים עם מונה. Clustering מקומי (Supercluster) עובד עבור ציים עד 300–400 יחידות.
אנימציית תנועה
מיקומי מעקב מתעדכנים כל 10–30 שניות — סמנים לא צריכים "לקפוץ." ValueAnimator עם LatLngInterpolator (אנדרואיד) או CABasicAnimation עם אינטרפולציית CGPoint (iOS) — הסמן "גולש" בצורה חלקה לנקודה החדשה.
השוואת שיטות clustering:
| שיטה | מקסימום סמנים | זמן השהיה |
|---|---|---|
| Supercluster (לקוח) | ~400 | <100ms |
| PostGIS ST_ClusterKMeans (שרת) | ללא הגבלה | <50ms (עם אינדקס) |
השוואת פורמטי נתונים:
| פורמט | גודל חבילה (40 רכבים) | חיסכון בתעבורה |
|---|---|---|
| JSON | ~8 KB | — |
| Protobuf | ~1.5 KB | פי 5 |
כיצד נבנים היסטוריית מסלולים וגיאוקידינג
מסלול של יום הוא 2000–8000 נקודות תלוי במרווח הרישום. אנו מציגים אותו דרך Polyline / MKPolyline, אבל לא את כל המסלול בבת אחת: אנו טוענים את bbox המפה הנראה ומבקשים נקודות רק עבורו. ברמת זום "יום שלם", אנו מפחיתים את המסלול באמצעות אלגוריתם Douglas-Peucker בשרת.
כתובות עצירה — גיאוקידינג הפוך דרך Google Maps Geocoding API או OpenStreetMap Nominatim (מאוחסן עצמאית). אנו שומרים תוצאות במטמון ב-SQLite כדי למנוע בקשות חוזרות בעת גלילה בהיסטוריה.
מה לעשות עם התראות והודעות?
מהירות מופרזת, אירועי גיאופנס, סרק ממושך — טריגרים מחושבים בשרת, הודעות push מגיעות דרך FCM/APNs. ב-iOS, אנו משתמשים ב-UNNotificationCategory עם UNNotificationAction — ישירות מההודעה, ניתן לפתוח את המפה עם הרכב הספציפי.
גיאופנסים — מצולעי GeoJSON, נבדקים עם ST_Contains ב-PostgreSQL + PostGIS על כל הודעת מעקב נכנסת. לקוח המובייל מציג רק גיאופנסים ומקבל התראות — הוא לא מחשב חיתוכים מקומית.
טעויות נפוצות ביישום הודעות
- אין טיפול במצב רקע: האפליקציה לא מקבלת push אם המשתמש הורג את התהליך. השתמש ב-
background fetchכדי להתחבר מחדש ל-WebSocket. - הגדרת גיאופנס שגויה: אם מצולע מורכב מדי (100+ קודקודים),
ST_Containsשל PostGIS מאט. בצע אופטימיזציה למצולעים עם פישוט Ramer-Douglas-Peucker בשרת. - שכחת טוקני APNs/FCM: כשמתקינים מכשיר חדש, הטוקן הישן הופך ללא תקף — תמיד עדכן אותו בשרת.
מה כלול בפיתוח?
- ניתוח פרוטוקולים של מכשירי טלמטיקה ו-API של פלטפורמות קיימות
- עיצוב ממשק משגר: מפה, רשימת רכבים, היסטוריה, הודעות
- פיתוח כל המודולים: קבלת נתונים, תצוגת מפה, גיאופנסים, התראות, היסטוריית מסלולים
- בדיקות עומס עם סימולציה של 200+ מעקבים
- פרסום ב-App Store וב-Google Play, הגדרת הודעות push
- תיעוד והדרכת משגרים
- תמיכה טכנית לאחר השקה
כמה זמן לוקח הפיתוח?
MVP (מפה + זמן אמת + היסטוריה): 6–10 שבועות. פלטפורמה מלאה עם גיאופנסים, התראות, ניתוח קילומטראז' ודוחות: 3–5 חודשים. התמחור מחושב באופן אישי לאחר ביקורת על התשתית שלך.
אנו מבטיחים פעולה יציבה בעומס של עד 500 יחידות רכב. צור קשר להערכת פרויקט — קבל ייעוץ על ארכיטקטורה ולוחות זמנים. בקש הערכת עלות.