אנחנו מפתחים פתרונות AR כבר יותר מ-5 שנים והשלמנו 30+ פרויקטים המשלבים מציאות רבודה עם מערכות ארגוניות. אחת המשימות הנפוצות היא חיבור אפליקציית AR למאגרי נתונים חיצוניים.
אפליקציית AR לניהול מלאי במחסן מציגה לעובד מידע על המוצר ישירות מעל הקופסה הפיזית. הנתונים נשלפים מה-ERP בזמן אמת. זמן השהייה של 800 אלפיות השנייה פירושו שההערה מופיעה אחרי שהעובד כבר הסיט את מבטו. זו לא ניואנס של חוויית משתמש—זה כשל ישיר בתרחיש השימוש. שילוב AR עם מאגרי נתונים חיצוניים דורש גישה שונה לארכיטקטורת שאילתות מאשר אפליקציות מובייל רגילות. הניסיון שלנו מראה שפתרונות סטנדרטיים לא עובדים כאן.
אילו אתגרים טכניים מתעוררים בשילוב AR עם מאגר נתונים?
זמן השהייה ב-AR הוא קריטי יותר מאשר בכל הקשר מובייל אחר. המשתמש מכוון את המצלמה לאובייקט ומצפה לתגובה מיידית. 300 אלפיות השנייה מקובלות, 800 אלפיות השנייה זה עיכוב ניכר, 2 שניות גורמות לאפליקציה להיראות שבורה.
המקורות העיקריים לזמן השהייה:
- נסיעת רשת הלוך-חזור לשרת (100–300 אלפיות השנייה ב-4G, 20–50 אלפיות השנייה ב-WiFi)
- זמן עיבוד שאילתה בצד השרת (שאילתת SQL ללא אינדקס על טבלה של 5 מיליון שורות יכולה בקלות לקחת 500 אלפיות השנייה)
- פירוק JSON בצד הלקוח
הפתרון הוא טעינה חזויה וקאשינג. באפליקציית AR במחסן, כשהמשתמש מכוון למדף, אנחנו יודעים שב-30 השניות הבאות הוא יעבוד עם האזור הזה. טעינה מוקדמת מבקשת נתונים עבור כל הפריטים באזור בבקשה אחת מרוכזת ברגע שמזהה המדף מזוהה, ומאחסנת אותם בקאש מקומי. כשהמשתמש מכוון לקופסה ספציפית, הנתונים כבר מוכנים. גישה זו מספקת שיפור של פי 2–3 במהירות התגובה בהשוואה לבקשות בודדות.
מצב לא מקוון הוא הנקודה הקריטית השנייה. במחסנים, סדנאות תעשייתיות ומתקנים רפואיים עם מחיצות מתכת, האות לא יציב. אפליקציית ה-AR חייבת לעבוד עם נתונים שמורים במטמון ולסנכרן שינויים כשהחיבור משוחזר. קונפליקטים של מיזוג (משתמש משנה כמות ב-AR, משתמש אחר משנה את אותו שדה ב-ERP) מטופלים באמצעות חותמות זמן + כתיבה אחרונה מנצחת או באמצעות ממשק משתמש מפורש לפתרון קונפליקטים.
ארכיטקטורת מודול האינטגרציה
אנחנו בונים על שלוש שכבות:
שכבת גישה לנתונים — הפשטה מעל מקור הנתונים. IProductRepository עם מתודות GetByBarcode(string code), GetByZone(string zoneId), UpdateQuantity(string id, int delta). היישום הקונקרטי יכול להיות REST, GraphQL, gRPC או SQLite ישיר—שכבת הלוגיקה של AR לא מודעת לכך.
מנוע סנכרון — מנהל קאשינג וסנכרון. SQLite דרך sqlite-net-pcl במכשיר כאחסון מקומי. SyncWorker ברקע בודק את השרת כל N שניות (ניתן להגדרה) או מגיב ל-push דרך WebSocket/SignalR. אסטרטגיית קאשינג – TTL לפי סוג ישות: נתונים המשתנים במהירות (כמות במלאי) – 30 שניות, נתוני ייחוס (שמות, מאפיינים) – 24 שעות.
שכבת קישור ל-AR — מחברת נתונים לאובייקטי AR. ב-AR Foundation: כשמתרחשת ARTrackedObjectsChangedEventArgs.added, בקש נתונים עבור האובייקט המזוהה דרך IProductRepository, אכלס את ARAnnotationController בנתונים שהתקבלו. ב-removed, הסתר את ההערה ובטל בקשות ממתינות דרך CancellationToken.
לביצועים, אנו משתמשים ב-UniTask (או ValueTask ב-.NET סטנדרטי) במקום קורוטינות רגילות – פחות הקצאות, ביטול משימות טבעי דרך CancellationToken, טיפול נכון בחריגות ב-async/await. מיקרוסופט ממליצה להשתמש ב-HttpClient כ-singleton כדי למנוע דלדול סוקטים (ראה המלצות מיקרוסופט).
אינטגרציות אופייניות בפרויקטי AR
| גישה | זמן השהייה | מורכבות | תמיכה במצב לא מקוון |
|---|---|---|---|
| REST API | בינוני (100-300 אלפיות השנייה) | נמוכה | דורש קאשינג |
| GraphQL | בינוני (בקשה אחת) | בינוני | דורש קאשינג |
| WebSocket / SignalR | נמוך (זמן אמת) | גבוהה | מורכב, דורש תור |
REST API (הנפוץ ביותר): HttpClient עם System.Net.Http, Newtonsoft.Json או System.Text.Json לפירוק. חשוב: HttpClient חייב להיות singleton או pooled – כל new HttpClient() פותח מאגר סוקטים חדש.
GraphQL: נוח במיוחד לאפליקציות AR – בקש רק את השדות הדרושים, קבל נתונים קשורים בבקשה אחת. השתמש ב-graphql-net-client או Strawberry Shake עבור .NET.
WebSocket / SignalR: לעדכונים בזמן אמת – למשל, הערות AR על פס ייצור שבו מצב הציוד משתנה כל שנייה. SignalR Core בקצה האחורי, Microsoft.AspNetCore.SignalR.Client בצד הלקוח.
אנחנו לא ממליצים על חיבורי מסד נתונים ישירים באפליקציות AR – זה אנטי-דפוס מבחינת אבטחה (אישורי מסד נתונים ב-APK) ומדרגיות.
איך להבטיח תגובה מיידית?
הטכניקה המרכזית היא טעינה מוקדמת אסינכרונית של נתונים באזור הנראה. אנו משתמשים בטעינה מוקדמת מרחבית: כשמזהה אזור (מדף, חדר) מזוהה, אנו שולחים בקשה מרוכזת עבור כל האובייקטים באזור זה. זה נותן שיפור של פי 2–3 בהשוואה לבקשות בודדות. UniTask מאפשר לבטל בקשות מיושנות ללא הקצאות. בדיקות עומס מראות שעם 1000+ אובייקטים באזור, 98% מהבקשות מעובדות ב-<200 אלפיות השנייה.
תוכנית אינטגרציה שלב אחר שלב
- ניתוח מקור הנתונים. אנו לומדים את מבנה ה-API או מסד הנתונים, קובעים דרישות לרעננות נתונים והתנהגות לא מקוונת.
- עיצוב שכבת גישה לנתונים. ממשקים, אסטרטגיית קאשינג, מדיניות לא מקוונת.
- פיתוח מנוע סנכרון. סכמת SQLite, סנכרון רקע, פתרון קונפליקטים.
- אינטגרציה עם AR Foundation. קישור נתונים לאובייקטים במעקב.
- בדיקות. תרחישים: אות חלש, לא מקוון מלא, קונפליקטי סנכרון, בדיקת עומס (1000 אובייקטים בשדה הראייה).
| היקף אינטגרציה | לוחות זמנים משוערים |
|---|---|
| REST פשוט + קאש (100–500 רשומות) | 1–2 שבועות |
| סנכרון לא מקוון + קונפליקטים | 3–5 שבועות |
| WebSocket בזמן אמת + סכמת נתונים מורכבת | 1–3 חודשים |
העלות נקבעת לאחר ניתוח מבנה הנתונים ודרישות הסנכרון.
מה כלול בעבודה
- פיתוח שכבת גישה לנתונים עם תמיכה ב-REST/GraphQL/WebSocket.
- יישום מנוע סנכרון עם קאשינג ופתרון קונפליקטים.
- אינטגרציה עם AR Foundation (Unity) או XR מקורי.
- תיעוד API וארכיטקטורה.
- הכשרת הצוות שלך לעבודה עם המודול.
- אחריות ל-6 חודשים על באגים שזוהו.
אנו מבטיחים שהמודול יעבור בדיקות עומס עם 1000+ אובייקטים בשדה הראייה. לפי Unity, קאשינג נכון מפחית את זמן ההשהייה ב-60%.
אם אתה צריך לשלב AR עם נתונים חיצוניים, צור קשר להערכת פרויקט. הזמן פיתוח מודול מפתח ביד והשג פתרון מוכן תוך 2–12 שבועות בהתאם למורכבות.
דוגמה לממשק שכבת גישה לנתונים ב-C#
public interface IProductRepository
{
UniTask<Product> GetByBarcode(string code, CancellationToken ct);
UniTask<IEnumerable<Product>> GetByZone(string zoneId, CancellationToken ct);
UniTask UpdateQuantity(string id, int delta, CancellationToken ct);
}