תמיכה טכנית לאחר השקת אפליקציית VR
שחררתם אפליקציית VR ב-Meta Horizon Store או ב-Steam — ומיד אחרי עדכון הפלטפורמה הבא, באגים מתחילים לזרום פנימה. אנחנו רואים את זה כל הזמן: גרסאות יציבות נשברות ללא אזהרה. במקום לפתח תכונות חדשות, אתם מתחילים להגיב למה ששבור עבור משתמשים אמיתיים עם חומרה אמיתית. הדרישות המיוחדות של VR קשות במיוחד: עדכוני Horizon OS ו-SteamVR יכולים לשבור אפליקציה שעובדת, ואין לכם שבועות להגיב. הצוות שלנו מתחזק פרויקטי VR כבר 8 שנים (מעל 50 גרסאות ב-Quest וב-Steam), ואנחנו יודעים איך למזער זמן השבתה.
למה תמיכה באפליקציות VR דורשת גישה מיוחדת?
בניגוד לאפליקציות מובייל רגילות, מוצרי VR תלויים במאפייני חומרה — מעקב, עיבוד בקצב פריימים גבוה, passthrough. עדכוני SDK (Oculus Integration, XR Interaction Toolkit, AR Foundation) יכולים לשבור פונקציונליות לחלוטין. לדוגמה, אחרי שחרור XR Interaction Toolkit 3.x, לגרסאות מוקדמות היו רגרסיות באינטראקציית אחיזה — אפליקציות שעדכנו מיד קיבלו אחיזות לא תקינות. אנחנו ממתינים 2–4 שבועות אחרי שחרור משמעותי, עוקבים אחרי בעיות בקהילה, ורק אז מעדכנים.
מה נשבר אחרי עדכוני פלטפורמה
Meta מעדכנת את Horizon OS באופן קבוע — מעל עשרה תיקונים משמעותיים בשנה האחרונה. כל אחד יכול לשבור משהו באפליקציה שעובדת. בעיות אופייניות: שינויים בהתנהגות של OVRCameraRig בעת עדכון Oculus Integration SDK (גרסאות ישנות מפסיקות לעקוב אחרי מיקום בצורה נכונה אם הפרויקט לא מעודכן לגרסה תואמת). או שינויים ב-compositor של passthrough, שלאחריהם אפליקציות MR מציגות שכבות לא מיושרות.
SteamVR מתנהג באופן דומה. אחרי עדכוני OpenVR API, החתימות של קריאות חוזרות (callbacks) משתנות מעת לעת — EVREventType.VREvent_InputFocusChanged מפסיק להגיע, והאפליקציה מאבדת פוקוס ללא טיפול מתאים. משתמשים רואים בקר קפוא בסצנה.
עדכוני מערכת ל-iOS ול-Android משפיעים גם על אפליקציות ARKit/ARCore: הרשאות מצלמה משתנות, ARCore בחלק מהקושחות של Android 14 דורש הרשאה מחודשת של ARCore Services.
איך התמיכה מאורגנת
ניטור שגיאות — באמצעות מערכות דיווח קריסה משולבות בגרסת השחרור. עבור פרויקטי Unity אנחנו משתמשים ב-Firebase Crashlytics או ב-Sentry Unity SDK, המוגדרים עם symbolication עבור מחסניות מקוריות (native stacks). ללא symbolication, מחסנית הקריסה עבור build מסוג IL2CPP היא רק קבוצה של כתובות hex — חסרת תועלת. עם symbolication — מחסנית C# מלאה כולל שורות קוד.
עבור Meta Quest בנוסף — Meta Developer Hub עם ADB logcat במצב ניטור. קריסות ייחודיות ל-Quest עם קודי SIGABRT או SIGSEGV בשכבת ה-Oculus runtime המקורית דורשות ניתוח נפרד באמצעות NDK stack unwinder.
סיווג אירועים לפי עדיפות: P1 — קריסה בהפעלה או בנתיב קריטי (>5% מהסשנים מושפעים), P2 — ירידה בתפקוד ללא קריסה מלאה, P3 — תקלות חזותיות או כשלים במקרי קצה. עבור P1 — תגובה ותיקון חם תוך 24–48 שעות.
עדכון תאימות לגרסאות SDK חדשות
משימה קבועה בתמיכה לאחר השקה היא עדכון תלויות. ל-Oculus Integration SDK, XR Interaction Toolkit, AR Foundation יש הערות שחרור עם שינויים שוברי תאימות. מחזור אופייני: גרסת SDK חדשה שוחררה → בדיקה מקומית על build בסטייג'ינג → בדיקת נתיבים קריטיים → פרסום עדכון.
חשוב לא לעדכן לגרסאות ראשיות מיד לאחר השחרור. ל-XR Interaction Toolkit 3.x היו מספר רגרסיות בגרסאות מוקדמות בהשוואה ל-2.x — אפליקציות שעדכנו מיד קיבלו אינטראקציות אחיזה שבורות. המתנה של 2–4 שבועות אחרי שחרור ראשי וניטור בעיות בקהילה הם חלק מהתהליך.
איך אנחנו מבטיחים תאימות ל-SDK חדשים?
אנחנו משווים שינויי API בין גרסאות ומבצעים אוטומציה של בדיקות נתיבים קריטיים. לדוגמה, אנחנו מוודאים פעולה תקינה של OVRCameraRig אחרי עדכון Oculus Integration. אם אנחנו מוצאים רגרסיה — אנחנו מתקנים אותה לפני הפרסום. גישה זו מפחיתה את מספר התקלות ב-30% בהשוואה לעדכון ריאקטיבי. מחזור העדכון המנוסה שלנו מפחית את סיכון הרגרסיות ב-80% בהשוואה לעדכונים מיידיים.
| גישה | זמן עדכון | סיכון לרגרסיות |
|---|---|---|
| עדכון מיידי | 1–2 ימים | גבוה (40–50%) |
| המתנה + בדיקה (שלנו) | 2–4 שבועות | נמוך (<10%) |
תהליך תמיכה שלב אחר שלב
- הקמת ניטור קריסות ו-symbolication.
- ניטור רציף של אירועים וביקורות משתמשים.
- תיעדוף באגים לפי חומרה (P1–P3).
- פיתוח ובדיקת תיקונים חמים על builds בסטייג'ינג.
- פריסת עדכונים ואימות יציבות.
טיפול בביקורות משתמשים ודוחות קריסה
ביקורות בחנות מכילות אותות על בעיות טכניות שלא מגיעות לדיווחי קריסה אוטומטיים — "המעקב שלי נשבר באור חזק", "לא נפתח ב-Quest 2 אחרי העדכון". סיסטמטיזציה של ביקורות וקורלציה עם נתוני Crashlytics מאפשרת לנו לתעדף תיקונים.
עבור אפליקציות Steam — ניטור Steam Discussions, Steam Workshop (אם נעשה בו שימוש), ו-Steam Reviews. באגים המדווחים על ידי הקהילה מכילים לעיתים קרובות תצורות חומרה ספציפיות שמשחזרות את הבעיה: GPU ספציפי + headset + גרסת דרייבר.
מה כלול
- גישה למערכת ניטור קריסות ולדשבורד אירועים
- דוח חודשי על מצב האפליקציה (קריסות, ביצועים, תאימות)
- עדכוני SDK ותלויות עם בדיקות בסטייג'ינג
- טיפול בעדיפות עליונה בבאגים קריטיים (SLA: 24 שעות עבור P1)
- ייעוץ בנושא אופטימיזציה והכנה לעדכוני פלטפורמה
מעל 50 פרויקטים, יותר מ-300 באגים שתוקנו, זמן תגובה ממוצע של פחות מ-8 שעות לאירועים קריטיים. אנחנו מבטיחים שהאפליקציית VR שלכם תישאר תואמת למכשירים חדשים ולגרסאות פלטפורמה. צרו קשר כדי לדון בתמיכה בפרויקט שלכם — נעריך את ההיקף ונציע את החבילה האופטימלית.