Розробка AR-порталу для iOS: віртуальна сцена в мобільному застосунку

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-сцени й фіксація умов, у яких застосунку доведеться працювати.

1. Аудит AR-сцени. Обстежуємо майданчик: освітленість у різний час доби, характер поверхонь, перепади висот, ширину проходів, поведінку камери під час руху. Фіксуємо, які об'єкти мають розпізнаватися і з якої відстані — це вхідні дані для схеми.
2. Цільові сценарії та схема сцени. Описуємо маршрут користувача, точки прив'язки віртуальних об'єктів, тригери й резервні сценарії на випадок, якщо розпізнавання не спрацювало з першого разу. Схема узгоджується до початку розробки — правки на цьому етапі обходяться на порядок дешевше.
3. Збірка застосунку. Портал збирається як окремий модуль поверх інтерфейсу застосунку: логіка сцени, завантаження контенту, робота з камерою, аналітика подій. Контент виносимо в окремий шар, щоб заміна візуальної частини не потребувала перезбирання релізу.
4. Тестування на пристроях. Перевіряємо не лише в лабораторії, а й на реальному парку моделей, зокрема бюджетних. Дивимося частку успішних запусків сцени, час до першого кадру, поведінку при слабкому світлі й на ходу.
5. Перевірка на майданчику. Після монтажу калібруємо прив'язки, замірюємо утримання сцени на реальному потоці людей і коригуємо пороги спрацювання. Без цього кроку застосунок стабільно працює лише в розробника.
6. Передача та навчання. Віддаємо відповідальним регламенти: як оновлювати контент, що робити при збої розпізнавання, як збирати діагностику з пристрою. Плюс коротке навчання персоналу майданчика.
7. Підтримка після запуску. Моніторимо частку успішних сесій за пристроями й версіями системи, оновлюємо контент і ядро сцени в міру виходу нових версій мобільної системи.

Такий порядок скорочує переробки: прив'язки й пороги фіксуються в живих умовах, а не в припущеннях. Строки та склад робіт за кожним етапом оцінюємо після аудиту — опишіть майданчик і завдання, повернемося з планом.

Конфігурації, схеми сцен і регламенти оновлення контенту

Передаємо проєкт не архівом файлів, а робочою системою: ваші інженери можуть зібрати збірку, змінити сцену й випустити оновлення без нас.

Тому до комплекту входять не лише вихідні файли, а й конфігурації, схеми сцен і регламенти — за ними нова людина в команді розбирається за дні, а не тижні.

• Конфігурація AR-порталу: набори параметрів для внутрішніх збірок, тестування й публікації в магазині застосунків — які сцени й ресурси входять до кожного каналу, які дозволи запитуються в користувача.
• Схеми сцен: структура кожної віртуальної сцени — прив'язка до маркерів і площин, точки появи об'єктів, порядок підвантаження ресурсів і обмеження за обсягом, щоб сцена відкривалася на середньому пристрої.
• Документація щодо AR-сцени: як додати модель, замінити текстуру, виправити анімацію й положення якоря, які імена й формати файлів очікує збірка.
• Політики доступу: ролі редакторів і тих, хто публікує, права на зміну сцени й відкат версії, журнал дій за кожною зміною.
• Регламент оновлення контенту: цикл «правка → перевірка на пристроях → публікація», хто погоджує зміни, як відкочується невдалий випуск.
• Інструкція зі збірки та випуску: послідовність кроків, робота з підписом і сховищем ключів, перевірки перед відправленням у магазин.
• План передачі проєкту: розбір схем разом із вашою командою, спільний випуск першого оновлення й точка, після якої підтримка йде за вашим регламентом.

Кейс: шоурум меблів — запуск сцени скоротили у сім разів

Що було до

Меблевий шоурум «Формат» вивів віртуальну вітрину в мобільний застосунок: покупець наводить телефон на мітку в залі й потрапляє в сцену, де товар стоїть в інтер'єрі.

Перша збірка AR-порталу відкривалася 11 секунд, а на пристроях середнього класу запуск зривався в 28% випадків — людина бачила чорний екран і закривала застосунок, так і не дійшовши до картки товару.

Що змінили і що вийшло

Ми перебудували конвеєр підготовки сцени: моделі стиснули й попередньо завантажуємо до входу в портал, текстури підтягуються в міру наближення камери, якість рендерингу підбирається за класом пристрою.

Портал збирається з незалежних модулів — мітка, сцена, інтерфейс покупки, — тому зміна колекції не зачіпає решту логіки.

Метрики до і після:

• час до першого кадру — 11 секунд проти 1,6;
• частка невдалих запусків — 28% проти 3%;
• частка користувачів, які доходять до замовлення, — 4% проти 17%.

Віртуальна вітрина перестала бути демонстрацією технології й стала робочим каналом продажів. Сцена відкривається швидше, ніж покупець устигає відвести телефон, відмовні запуски зійшли на рівень фонових збоїв, а частка замовлень із вітрини зросла вчетверо.

Що робити, якщо застосунок уже зібрано, а сцена нестабільна

Готова збірка й нестабільна AR-сцена — часто два різні шари проблеми.

Якщо сцена не запускається на частині пристроїв або розвалюється через кілька секунд, причина зазвичай не в коді застосунку, а в контенті: перевантажені моделі, важкі текстури, немає запасного сценарію при втраті трекінгу. Перший крок — розібрати збірку за шарами й зрозуміти, де втрачається керування.

Без переписування продукту лікується багато що: оптимізація геометрії та матеріалів, розбиття сцени на частини, що підвантажуються, коректна обробка втрати трекінгу й повернення в сцену, калібрування під слабкі пристрої.

Доопрацювання наявного застосунку тут швидше й дешевше за повне перезбирання: нативна частина й інтерфейс залишаються, змінюється лише те, що заважає стабільності.

Перезбирати доводиться там, де контент вшито в збірку: модель лежить у коді, окремого шару завантаження сцен немає, будь-яка правка потребує публікації в магазинах застосунків.

Тоді ми виносимо AR-контент в окреме сховище з версіонуванням, додаємо завантаження сцен на вимогу й кеш на пристрої — оновлення перестає залежати від випуску нової версії застосунку.

Міграція AR-контенту йде поетапно: спочатку переносимо сцени без зміни геометрії, потім правимо матеріали й точки прив'язки, наприкінці замірюємо, на якій частці пристроїв сцена ініціалізується з першого разу й скільки займає запуск.

За кожним блоком окремо вирішуємо — доопрацювання чи перезбирання, — і зберігаємо можливість відкотитися до робочого варіанта.

Технічні сумніви: сумісність, прив'язка, оновлення

До старту замовники ставлять той самий набір запитань: на чиїх пристроях це запрацює, наскільки точно сцена тримається на об'єкті, як змінювати контент після релізу й що залишається на нашому боці. Нижче — відповіді з окресленими межами, а не обіцянка «працює всюди».

Наскільки точно сцена тримається на об'єкті?

Точність прив'язки визначає опора: площина, зображення-мітка або заздалегідь розмічена точка. Для статичної вітрини достатньо мітки, для обходу об'єкта ставимо кілька опор і уточнюємо положення — сцена не відходить від предмета й при повторному запуску стає на те саме місце.

Чи можна оновити сцену, не випускаючи новий застосунок?

Так: контент винесено окремим шаром — моделі, тексти й порядок кроків підвантажуються при запуску, без перезбирання клієнта й повторної перевірки в магазині. Якщо змінюється логіка взаємодії, потрібна нова версія застосунку; такі правки плануємо заздалегідь.

Як оновлення доходить до користувачів?

Актуальна сцена кешується на пристрої, тому повторний запуск іде без затримки й працює без мережі. Нова версія підтягується при наступному підключенні, а попередня композиція зберігається — є куди відкотитися, якщо оновлення дало несподіваний результат.

Що входить у підтримку порталу після запуску?

Стежимо за часткою успішних сесій, оновлюємо контент за заявкою, відстежуємо зміни платформи, щоб застосунок не відмовляв після чергового оновлення системи. Строки реакції на звернення й відповідальний інженер фіксуються до старту робіт.

Що уточнюємо перед стартом: сценарії, пристрої, контент

Перша зустріч щодо AR-порталу потрібна не для презентації, а щоб зняти ввідні, від яких залежать і оцінка AR-проєкту, і план робіт з AR. Поки не зафіксовано майданчик, парк пристроїв і перелік об'єктів, будь-які строки — припущення, а не розрахунок. Нижче — що уточнюємо до старту.

• Майданчик і умови. Освітленість, приміщення чи вулиця, площа, однотонні й відбивні поверхні. Від цього залежить, чи потрібні опорні маркери, чи достатньо розпізнавання площин.
• Парк пристроїв. Які моделі в ходу в співробітників і клієнтів, чи є датчик глибини, яку мінімальну версію системи готові підтримувати. Це задає межу між повною віртуальною сценою й спрощеним режимом.
• Перелік об'єктів. Скільки моделей, у якому вигляді прийдуть вихідні файли, чи потрібно полегшувати геометрію й текстури під мобільний рендер.
• Сценарії використання AR. Одиночний показ, гід по об'єкту, примірка, навчання персоналу — набір жестів і логіка переходів будуються під конкретний сценарій.
• Хто веде контент. Чи залишається наповнення в замовника, чи потрібна панель керування, як сцени оновлюються без випуску нової версії застосунку.
• Офлайн і зв'язок. Чи працює портал у приміщенні без стабільного інтернету, чи кешуються моделі на пристрої, що відбувається при втраті мережі.
• Доступи, тестові точки й підтримка. Тестові облікові записи, доступ до реального майданчика для перевірки на місці, режим підготовки до запуску й порядок передачі оновлень.

Зібраних ввідних достатньо, щоб повернутися з оцінкою етапів і складом робіт.