פורטל AR ב-iOS: איפה בדיוק נשברת הסצנה הווירטואלית
התקלה מתחילה במקום שבו הסצנה הווירטואלית באפליקציה יוצאת לראשונה ממכשיר המפתח. מטריצות מצלמה שונות, ערכות חיישנים שונות וממדי מסך פיזיים שונים פירושם שהפרספקטיבה, קנה המידה של האובייקט ונקודת העיגון מחושבים מחדש בכל מכשיר.
אם פרמטרי המצלמה וההנחות לגבי גודל הסצנה מוטבעים בנכסים עבור מכשיר אחד, במכשירים האחרים המודל סוטה: האובייקט או תלוי באוויר, או נכנס לפריים רק ממרחק רב. בהדגמה זה נראה כמו «עובד רק בטלפון אחד», ובפרודקשן — כמו כשל בחצי מצי המכשירים.
התקלה האופיינית השנייה היא סחיפה. פורטל AR מחזיק את האובייקט ביחס לזירה הפיזית באמצעות טראקינג ויזואלי, וזה צובר שגיאה בכל שנייה.
משטחים אחידים וחלקים, השתקפויות, חלונות ראווה מזכוכית ותאורה משתנה מספקים מעט נקודות עיגון: הסצנה מתחילה כשורה, אבל בתוך חצי דקה של תנועה העוגן סוטה בעשרות סנטימטרים, והמודל מפסיק להתאים למקום.
הפתרון אינו «אלגוריתם מדויק יותר», אלא ארכיטקטורת עיגון — מרקרים התחלתיים, הערכה חוזרת של המישור ותיקון העוגן תוך כדי תנועה.
הכשל השלישי הוא זמן ההפעלה. כשהמודל, הטקסטורות והסצנה נטענים ברגע הפתיחה, המשתמש מחזיק את הטלפון וממתין עשרות שניות, וסשן הטראקינג מאותחל עד שיקלוט פריים מתאים.
הפתרון הוא הפרדה לשלבים: שלד קל של הסצנה, טעינה מראש של נכסים, טעינת פרטים נוספים לאחר ההתחלה, ומסך המתנה נפרד עם סטטוס ברור — עד כדי רמז לאן לכוון את המצלמה.
זו בדיוק הסיבה שאנחנו מתחילים את הפיתוח של פורטל AR ב-iOS ממטריצת מכשירים, כיול לכל דגם ופרופיל ביצועים, ולא מסצנה יפה. בהמשך נפרט כיצד נסגר כל אחד מהכשלים האלה.
אפקט מדיד: הפעלת הסצנה, כשלים, ביקורים חוזרים
לאחר עיבוד מחדש של הסצנה, המדדים נמדדים בשלוש נקודות: הזמן עד להופעת האובייקט הראשון על המסך, שיעור ההפעלות הכושלות ושיעור הפניות החוזרות לתרחיש. הם בדיוק מראים אם פורטל AR מחזיק את המשתמש או נשאר אטרקציה חד-פעמית, שנפתחה פעם אחת ונסגרה.
מהקשה ועד הפריים הראשון
הסצנה מחולקת לשני רבדים: שלד קל עם רמזים ומודלים שנטענים בהדרגה. השלד מופיע תוך 1-2 שניות, טקסטורות ואנימציות כבדות נטענות ברקע בזמן שהמשתמש כבר מכוון את המצלמה. זמן טעינת הסצנה הצטמצם מ-6-9 שניות ל-1.5-2, ושיעור ההפעלות הנטושות של סצנת AR ירד מ-40% ל-12%.
כשלים ויציבות
היציבות של אפליקציה לנייד נשענת על שלושה דברים: תקציב גיאומטריה לכל מכשיר ספציפי, דעיכת אפקטים במקום כשל, והפעלה מחדש של הסשן בעת אובדן זיהוי בלי לצאת מהאפליקציה. שיעור כשלי האפליקציה בתרחישים עם מצלמה וגרפיקה תלת-ממדית ירד מ-8% מהסשנים ל-0.5-1%.
סטטיסטיקת התקלות וההרצה המוקדמת בקבוצת בטא נאספות דרך TestFlight, כדי שהמספרים יאומתו לא על מכשיר הדגמה אחד.
חזרות לתרחיש
פתיחות חוזרות של מצב AR באותו מכשיר עלו מ-9% ל-24% בחודש הראשון. החזרה מגיעה מכרטיס האובייקט ומתזכורת — התרחיש הפך לחלק ממסלול השימוש באפליקציה. אנחנו סופרים בדיוק את החזרה לסצנה, ולא את הפעלת האפליקציה בכלל: כך רואים שהפורטל מחזיק עניין בעצמו, בלי תמיכה של מדורים אחרים.
מצבי עבודה של פורטל AR: דפדפן, אפליקציה, אופליין
את אופן הצגת הסצנה בוחרים לא לפי טעם, אלא לפי הזירה: היכן ייפתח פורטל AR, איזה מכשיר יש למבקר והאם יש קליטה במקום. דפדפן מאפשר מעבר בקישור בלי התקנה, אפליקציה נייטיבית — גישה מלאה למצלמה ולסצנה עשירה, ומהדורת אופליין — עבודה במקומות שבהם הרשת אינה יציבה. המגבלות של כל אפשרות שונות, והן בדיוק קובעות איזה מצב יהיה הראשי.
בפועל המצבים לא מתחרים זה בזה: הסצנה נבנית פעם אחת ומוצגת במספר מעטפות, ובמכשירים חלשים האפקטים מוחלשים עד כדי צפייה שטוחה — בלי לאבד את כיסוי הקהל.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| פורטל AR בדפדפן | הפעלה בקישור מפרסומת, כיסוי בלי התקנה | לא כל המכשירים וגרסאות הדפדפן מספקים גישה למצלמה; חלק מהאפקטים מצומצם |
| אפליקציה נייטיבית עם AR | סשנים קבועים, טראקינג מדויק, סצנה מורכבת | נדרשת התקנה: חלק מהקהל נושר כבר בהורדה; מהדורות נפרדות לכל פלטפורמה |
| מצב אופליין של סצנת AR | זירות בלי קליטה יציבה: שורומים, תערוכות, נקודות ניידות | משאבי הסצנה מוגבלים לזיכרון המכשיר; עדכון תוכן — רק בטעינה מראש |
לכן בפרויקט אנחנו מחזיקים רובד נתונים משותף של הסצנה ומספר מעטפות הצגה, ואת התאימות בודקים על מטריצת מכשירים — מדגמים ישנים ועד עדכניים. המבקר מקבל את אותה סצנה בדיוק, לא משנה באיזו דרך נכנס אליה, והצוות לא בונה מחדש את התוכן לכל מצב.
שלבי ההטמעה: מביקורת הסצנה ועד מסירת הנהלים
הטמעת פורטל AR בנויה אחרת מפיתוח רגיל של אפליקציה לנייד: הזירה הפיזית הופכת לחלק מהמערכת, וטעות בסימון הסצנה מתגלה כבר אצל המבקר. לכן הצעד הראשון אינו הבנייה, אלא ביקורת של סצנת AR ותיעוד התנאים שבהם האפליקציה תצטרך לעבוד.
- ביקורת סצנת AR. סוקרים את הזירה: תאורה בשעות שונות של היום, אופי המשטחים, הפרשי גובה, רוחב המעברים, התנהגות המצלמה בתנועה. מתעדים אילו אובייקטים צריכים להיות מזוהים ומאיזה מרחק — אלה נתוני הקלט לסכמה.
- תרחישי יעד וסכמת הסצנה. מתארים את מסלול המשתמש, נקודות העיגון של האובייקטים הווירטואליים, טריגרים ותרחישי גיבוי למקרה שהזיהוי לא עבד בפעם הראשונה. הסכמה מאושרת לפני תחילת הפיתוח — תיקונים בשלב הזה זולים בסדר גודל.
- בניית האפליקציה. הפורטל נבנה כמודול נפרד מעל ממשק האפליקציה: לוגיקת הסצנה, טעינת תוכן, עבודה עם המצלמה, אנליטיקת אירועים. את התוכן מוציאים לרובד נפרד, כך שהחלפת החלק הוויזואלי לא תחייב בנייה מחדש של הריליס.
- בדיקות על מכשירים. בודקים לא רק במעבדה, אלא גם על מצי מכשירים אמיתי, כולל דגמים זולים. בוחנים את שיעור ההפעלות המוצלחות של הסצנה, את הזמן עד לפריים הראשון ואת ההתנהגות באור חלש ובתנועה.
- בדיקה בזירה. לאחר ההתקנה מכיילים את העיגונים, מודדים את אחיזת הסצנה בזרימת אנשים אמיתית ומתקנים את ספי ההפעלה. בלי הצעד הזה האפליקציה עובדת יציב רק אצל המפתח.
- מסירה והדרכה. מוסרים לאחראים נהלים: איך לעדכן תוכן, מה לעשות בעת כשל בזיהוי, איך לאסוף דיאגנוסטיקה מהמכשיר. בנוסף, הדרכה קצרה לצוות הזירה.
- תמיכה לאחר ההשקה. מנטרים את שיעור הסשנים המוצלחים לפי מכשירים וגרסאות מערכת, מעדכנים תוכן ואת ליבת הסצנה עם יציאתן של גרסאות חדשות של מערכת ההפעלה לנייד.
סדר כזה מצמצם עבודות חוזרות: העיגונים והספים נקבעים בתנאים אמיתיים, ולא בהשערות. לוחות הזמנים והיקף העבודה בכל שלב נאמדים לאחר הביקורת — תארו את הזירה ואת המשימה, ונחזור עם תוכנית.
קונפיגורציות, סכמות סצנות ונהלי עדכון תוכן
אנחנו מוסרים את הפרויקט לא כארכיון קבצים, אלא כמערכת עובדת: המהנדסים שלכם יכולים לבנות מהדורה, לשנות סצנה ולהוציא עדכון בלעדינו. לכן החבילה כוללת לא רק קוד מקור, אלא גם קונפיגורציות, סכמות סצנות ונהלים — לפיהם אדם חדש בצוות מתמצא תוך ימים, ולא שבועות.
- קונפיגורציה של פורטל AR: מערכי פרמטרים למהדורות פנימיות, לבדיקות ולפרסום בחנות האפליקציות — אילו סצנות ומשאבים נכללים בכל ערוץ, ואילו הרשאות מתבקשות מהמשתמש.
- סכמות סצנות: המבנה של כל סצנה וירטואלית — עיגון למרקרים ולמישורים, נקודות ההופעה של האובייקטים, סדר טעינת המשאבים ומגבלות נפח, כדי שהסצנה תיפתח במכשיר בינוני.
- תיעוד לסצנת AR: איך להוסיף מודל, להחליף טקסטורה, לתקן אנימציה ומיקום עוגן, ואילו שמות ופורמטים של קבצים המהדורה מצפה להם.
- מדיניות הרשאות: תפקידי עורכים ומפרסמים, הרשאות לשינוי סצנה ולחזרה לגרסה קודמת, ויומן פעולות לכל שינוי.
- נוהל עדכון תוכן: המחזור «תיקון → בדיקה על מכשירים → פרסום», מי מאשר שינויים, ואיך מבטלים מהדורה כושלת.
- הוראות בנייה והוצאה: רצף השלבים, עבודה עם חתימה ומאגר מפתחות, ובדיקות לפני שליחה לחנות.
- תוכנית מסירת הפרויקט: מעבר על הסכמות יחד עם הצוות שלכם, הוצאה משותפת של העדכון הראשון, והנקודה שממנה והלאה התמיכה מתנהלת לפי הנהלים שלכם.
מקרה בוחן: שורום רהיטים — זמן הפעלת הסצנה קוצר פי שבעה
מה היה לפני
שורום רהיטים «Формат» העלה חלון ראווה וירטואלי לאפליקציה לנייד: הקונה מכוון את הטלפון אל סימן באולם ונכנס לסצנה שבה המוצר מוצג בתוך חלל מעוצב.
המהדורה הראשונה של פורטל AR נפתחה ב-11 שניות, ובמכשירים מהדרג הבינוני ההפעלה נכשלה ב-28% מהמקרים — המשתמש ראה מסך שחור וסגר את האפליקציה, בלי להגיע לכרטיס המוצר.
מה שינינו ומה יצא
בנינו מחדש את קו ההכנה של הסצנה: המודלים כווצו ונטענים מראש לפני הכניסה לפורטל, הטקסטורות נטענות ככל שהמצלמה מתקרבת, ואיכות הרינדור נבחרת לפי סוג המכשיר. הפורטל מורכב ממודולים בלתי תלויים — סימן, סצנה, ממשק רכישה — ולכן החלפת קולקציה לא משפיעה על שאר הלוגיקה.
מדדים לפני ואחרי:
- זמן עד לפריים הראשון — 11 שניות לעומת 1.6;
- שיעור ההפעלות הכושלות — 28% לעומת 3%;
- שיעור המשתמשים שמגיעים עד להזמנה — 4% לעומת 17%.
חלון הראווה הווירטואלי הפסיק להיות הדגמה טכנולוגית והפך לערוץ מכירה עובד. הסצנה נפתחת מהר יותר מכפי שהקונה מספיק להוריד את הטלפון, ההפעלות הכושלות ירדו לרמת תקלות רקע, ושיעור ההזמנות מחלון הראווה גדל פי ארבעה.
מה לעשות אם האפליקציה כבר בנויה והסצנה לא יציבה
מהדורה מוכנה וסצנת AR לא יציבה הם לעיתים קרובות שני רבדים שונים של אותה בעיה. אם הסצנה לא עולה בחלק מהמכשירים או מתפרקת אחרי כמה שניות, הסיבה היא בדרך כלל לא בקוד האפליקציה אלא בתוכן: מודלים עמוסים מדי, טקסטורות כבדות, והיעדר תרחיש גיבוי בעת אובדן טראקינג. הצעד הראשון הוא לפרק את המהדורה לרבדים ולהבין היכן אובדת השליטה.
בלי לכתוב את המוצר מחדש אפשר לפתור הרבה: אופטימיזציה של גיאומטריה וחומרים, פיצול הסצנה לחלקים נטענים, טיפול נכון באובדן טראקינג ובחזרה לסצנה, וכיול למכשירים חלשים. שדרוג האפליקציה הקיימת מהיר וזול יותר מבנייה מחדש מלאה: החלק הנייטיבי והממשק נשארים, ומשתנה רק מה שמפריע ליציבות.
בנייה מחדש נדרשת במקומות שבהם התוכן מוטבע במהדורה: המודל יושב בקוד, אין רובד נפרד לטעינת סצנות, וכל תיקון מחייב פרסום בחנויות האפליקציות.
במקרים כאלה אנחנו מוציאים את תוכן ה-AR למאגר נפרד עם ניהול גרסאות, מוסיפים טעינת סצנות לפי דרישה ומטמון במכשיר — והעדכון מפסיק להיות תלוי בהוצאת גרסה חדשה של האפליקציה.
ההגירה של תוכן ה-AR מתבצעת בשלבים: תחילה מעבירים את הסצנות בלי לשנות את הגיאומטריה, אחר כך מתקנים חומרים ונקודות עיגון, ולבסוף מודדים באיזה שיעור מהמכשירים הסצנה מאותחלת בפעם הראשונה וכמה זמן נמשכת ההפעלה. לגבי כל בלוק מחליטים בנפרד — שדרוג או בנייה מחדש — ושומרים על אפשרות לחזור לגרסה העובדת.
ספקות טכניים: תאימות, עיגון, עדכונים
לפני תחילת העבודה הלקוחות שואלים את אותה קבוצת שאלות: על אילו מכשירים זה יעבוד, באיזו דיוק הסצנה מחזיקה את האובייקט, איך משנים תוכן אחרי הריליס ומה נשאר בצד שלנו. להלן תשובות עם גבולות מוגדרים, ולא הבטחה ש«עובד בכל מקום».
עם אילו מכשירים האפליקציה תואמת?
אנחנו נשענים על הכלים המובנים של הפלטפורמה, ולכן אין צורך בציוד נפרד. לפני ההתחלה מריצים את הסצנה על מטריצת דגמים וגרסאות מערכת עדכניים; במכשירים חלשים מופעל מצב מוקל עם אפקטים מצומצמים, אך בלי לאבד את התרחיש.
באיזו דיוק הסצנה מחזיקה את האובייקט?
את דיוק העיגון קובע הבסיס: מישור, תמונת סימן או נקודה מסומנת מראש. לחלון ראווה סטטי מספיק סימן; להקפה של אובייקט מציבים כמה בסיסים ומדייקים את המיקום — הסצנה לא סוטה מהחפץ, ובהפעלה חוזרת מתייצבת באותו מקום.
אפשר לעדכן את הסצנה בלי להוציא אפליקציה חדשה?
כן: התוכן מוציא לרובד נפרד — מודלים, טקסטים וסדר השלבים נטענים בעת ההפעלה, בלי בנייה מחדש של הלקוח ובלי בדיקה חוזרת בחנות. אם משתנה לוגיקת האינטראקציה, נדרשת גרסה חדשה של האפליקציה; תיקונים כאלה מתכננים מראש.
איך העדכון מגיע למשתמשים?
הסצנה העדכנית נשמרת במטמון במכשיר, ולכן הפעלה חוזרת נעשית בלי השהיה ועובדת גם בלי רשת. הגרסה החדשה נטענת בחיבור הבא, והקומפוזיציה הקודמת נשמרת — יש לאן לחזור אם העדכון הניב תוצאה לא צפויה.
מה כוללת התמיכה בפורטל לאחר ההשקה?
אנחנו עוקבים אחר שיעור הסשנים המוצלחים, מעדכנים תוכן לפי בקשה, ועוקבים אחר שינויים בפלטפורמה כדי שהאפליקציה לא תפסיק לעבוד אחרי עדכון מערכת נוסף. זמני התגובה לפנייה והמהנדס האחראי נקבעים לפני תחילת העבודה.
מה מבררים לפני ההתחלה: תרחישים, מכשירים, תוכן
הפגישה הראשונה על פורטל AR נועדה לא למצגת, אלא לאיסוף הנתונים שמהם תלויים גם אומדן פרויקט ה-AR וגם תוכנית העבודה על AR. כל עוד הזירה, מצי המכשירים ורשימת האובייקטים לא תועדו, כל לוח זמנים הוא השערה ולא חישוב. להלן מה מבררים לפני ההתחלה.
- הזירה והתנאים. תאורה, חלל פנימי או חוץ, שטח, משטחים אחידים ומחזירי אור. מזה תלוי אם נדרשים מרקרים לעיגון או שמספיק זיהוי מישורים.
- מצי המכשירים. אילו דגמים בשימוש אצל העובדים והלקוחות, האם יש חיישן עומק, ואיזו גרסת מערכת מינימלית מוכנים לתמוך בה. זה קובע את הגבול בין סצנה וירטואלית מלאה למצב מפושט.
- רשימת האובייקטים. כמה מודלים, באיזה מצב יגיעו קבצי המקור, והאם יהיה צורך להקל את הגיאומטריה והטקסטורות לרינדור נייד.
- תרחישי שימוש ב-AR. תצוגה בודדת, מדריך לאובייקט, הלבשה וירטואלית, הדרכת צוות — מערך המחוות ולוגיקת המעברים נבנים לפי התרחיש הספציפי.
- מי מנהל את התוכן. האם המילוי נשאר אצל הלקוח, האם נדרש ממשק ניהול, ואיך סצנות מתעדכנות בלי להוציא גרסה חדשה של האפליקציה.
- אופליין וקליטה. האם הפורטל עובד בחלל פנימי בלי אינטרנט יציב, האם המודלים נשמרים במטמון במכשיר, ומה קורה בעת אובדן רשת.
- הרשאות, נקודות בדיקה ותמיכה. חשבונות בדיקה, גישה לזירה האמיתית לבדיקה במקום, מצב ההיערכות להשקה וסדר מסירת העדכונים.
הנתונים שנאספו מספיקים כדי לחזור עם אומדן לשלבים והיקף העבודה.