Persistent AR: чому сцени не зберігаються між сесіями
Проблема майже завжди не в розпізнаванні, а в тому, що прив'язка об'єкта живе всередині однієї сесії. Камера будує карту оточення, рушій чіпляє на неї віртуальні мітки — і щойно застосунок закрився, ця карта вмирає разом із процесом.
Під час наступного запуску пристрій бачить ту саму кімнату, але для нього це вже нова сцена: збереження AR-сцен не відбувається, бо зберігати нічого — прив'язка ніде не зафіксована.
Друга причина — відсутність серверної синхронізації. Навіть якщо застосунок кешує локальну карту, вона прив'язана до конкретного пристрою та його калібрування. Другий користувач, який зайшов у ту саму точку, будує власну карту, і мітки двох пристроїв не збігаються у просторі.
Об'єкти «їдуть», дублюються або зникають — це і є втрата даних між сесіями, яку замовник бачить як «застосунок забув усе, що ми розставили».
Третя причина — прив'язка до маркера замість прив'язки до геометрії. Поки в кадрі є впізнаваний образ, мітка тримається; варто його прибрати або змінити освітлення — прив'язка рветься.
Persistent AR вимагає, щоб об'єкт був прив'язаний до стійких особливостей простору, а не до тимчасового візуального якоря.
Корінь проблеми один: у сцени немає зовнішнього сховища стану. Поки карта, координати міток та їхні ідентифікатори не винесені за межі сесії й не зведені до спільної системи координат, будь-яке збереження AR-сцен залишається імітацією. Розбираємо, як це закривається на рівні архітектури.
Що дає збереження AR-сцен: ефект у цифрах
Збереження AR-сцен між сесіями — це насамперед інженерна дисципліна, а не візуальний ефект.
Коли застосунок запам'ятовує просторові прив'язки та стан об'єктів, користувачеві не потрібно заново розмічати приміщення й заново виставляти сцену: він відкриває застосунок і потрапляє в ту саму точку, де зупинився.
Саме тут проявляються вимірювані вигоди — час повторного калібрування, частка успішних повернень у сцену та клас відмов при втраті прив'язок.
Час повторного калібрування — найчутливіший показник. Без збереження сцени кожен вхід починається з нуля: пошук опорних точок, ручне розмічання, очікування, поки трекінг стабілізується.
З persistent AR цей етап скорочується до перевірки збереженої карти: застосунок звіряє поточне положення камери із записаними прив'язками і або миттєво відновлює сцену, або пропонує короткий дозбір. На практиці це різниця між «пів хвилини на вхід» і «пара секунд до робочого стану».
Частка успішних повернень у сцену залежить від того, наскільки стійко зберігаються прив'язки. Якщо карта прив'язана до однієї точки і користувач підходить з іншого боку, відновлення зривається.
Тому ми зберігаємо кілька опорних якорів і допускаємо частковий збіг: сцена збирається, навіть якщо розпізнано не всю геометрію. Це підвищує частку успішних повернень і прибирає найчастіший сценарій роздратування — «застосунок знову все забув».
Клас відмов при втраті прив'язок теж змінюється. Замість жорсткого падіння в порожню сцену застосунок переходить у режим м'якої деградації: зберігає останній відомий стан, показує підказку щодо відновлення і не втрачає користувацькі дані.
Ми проєктуємо цю поведінку заздалегідь — на рівні моделі зберігання сцени, а не як латку поверх. Такий підхід ми відпрацьовували в проєктах на ARKit і аналогічних платформах, де стабільність прив'язок безпосередньо впливає на утримання.
Стабільність прив'язок — це ще й питання версіонування. Сцена, збережена на одній версії застосунку, має коректно відкриватися після оновлення, інакше користувач втрачає накопичений контент. Ми фіксуємо формат зберігання і передбачаємо міграцію, щоб оновлення не обнуляло сцени.
У сумі ці заходи дають передбачуване повернення в сцену та зниження відмов — те, що замовник бачить як «застосунок працює надійно».
Способи зберігання прив'язок: порівняння підходів
Прив'язка AR-сцени — це координати та орієнтація якоря у фізичному просторі плюс метадані: ідентифікатор, час створення, прив'язка до користувача або пристрою.
Від того, де ці дані лежать, залежить, чи побачить гість свою сцену після перезапуску застосунку і чи знайде її колега з іншого пристрою. Нижче — три схеми, між якими реально обирають на старті проєкту.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Локальний кеш прив'язок | Один користувач, один пристрій, сцена потрібна офлайн | Сцена не переживає перевстановлення застосунку і не видна іншим; при зміні пристрою прив'язка втрачається |
| Хмарна синхронізація | Кілька користувачів, спільні сцени, зміна пристроїв | Потрібен стійкий канал; при обриві зв'язку сцена не підвантажується, потрібен дозвіл конфліктів при одночасному редагуванні |
| Гібридна схема | Продакшн з офлайн-сценаріями та спільними об'єктами | Складніша в підтримці: дві точки правди, потрібна явна політика злиття та версіонування записів |
Локальний кеш дає мінімальну затримку — прив'язка читається з диска за мілісекунди і працює без мережі, але це глухий кут для командних сценаріїв. Хмара знімає прив'язку від пристрою, зате додає мережеву залежність і питання, чиє редагування переможе при одночасній зміні якоря.
Гібрид закриває обидва випадки: свіжа прив'язка пишеться локально і йде в хмару, при старті підтягуються зміни, а розбіжності вирішуються за часом останнього редагування.
Обмеження зберігання тут не в обсязі — записів мало, — а в терміні життя: застарілі якорі накопичуються і дають хибні збіги, тому потрібна політика очищення за віком та активністю.
Як ми впроваджуємо persistent AR: етапи робіт
Впровадження persistent AR починається з аудиту того, що вже є в застосунку: як влаштована сцена, де зберігаються прив'язки об'єктів до реальних поверхонь, які дані втрачаються при закритті сесії.
На цьому етапі ми фіксуємо поточну архітектуру, точки відмови та вимоги до відновлення сцени — від цього залежить уся подальша схема.
Далі робота йде за етапами, кожен з яких закінчується перевірюваним результатом:
- Аудит AR-сцен — розбираємо поточну реалізацію, визначаємо, які об'єкти мають зберігатися між сесіями, і де відбувається втрата стану.
- Проєктування схеми прив'язок — описуємо, як об'єкти прив'язуються до реальних точок і поверхонь, щоб сцена коректно відновлювалася при повторному запуску.
- Налаштування синхронізації — вибудовуємо обмін даними між пристроєм і сховищем: що йде на сервер, що залишається локально, як вирішуються конфлікти при розсинхронізації.
- Реалізація відновлення сцени — сцена збирається заново зі збережених прив'язок, включно з положенням об'єктів, їхнім станом і порядком відображення.
- Перевірка стійкості — тестуємо сценарії з втратою зв'язку, зміною пристрою, повторним входом і тривалими паузами між сесіями.
- Передача документації — віддаємо опис схеми прив'язок, регламенти роботи зі сховищем та інструкції для подальшої підтримки.
Що перевіряємо на кожному кроці
Окремо проганяємо граничні випадки: що відбувається, якщо користувач повернувся до сцени через тиждень, змінив пристрій або втратив мережу в момент збереження.
Такі перевірки показують, де схема прив'язок тримає навантаження, а де рветься, — і дозволяють закрити ці місця до релізу, а не після звернень користувачів.
Що залишається у замовника
За підсумком команда отримує не лише працюючу функцію, а й зрозумілу схему даних, регламенти синхронізації та документацію, за якою підтримку можна вести без нас. Якщо потрібно — супроводжуємо після запуску та доопрацьовуємо сценарії в міру зростання навантаження.
Що замовник отримує на руки після впровадження
Впровадження persistent AR не закінчується демонстрацією: сцена, яка переживає перезапуск застосунку, — це набір артефактів, за якими ваша команда зможе її експлуатувати, розширювати та відновлювати без нас. Нижче — що саме передаємо на руки.
- Конфігурації прив'язок. Файли, де описано, до яких опорних точок і міток чіпляються об'єкти, як ведеться повторне розпізнавання при зміщенні камери і що відбувається при втраті трекінгу. Редагується без перезбирання застосунку.
- Схеми зберігання. Структура локального кешу та серверного сховища: які дані сцени лежать на пристрої, які синхронізуються, як розв'язуються конфлікти при одночасному редагуванні з двох пристроїв.
- Політики доступу. Ролі та права на створення, перегляд і зміну сцен, прив'язка до вашої системи облікових записів, правила шарингу між користувачами та зовнішніми гостями.
- Документація. Опис формату сцени, життєвого циклу об'єкта, точок розширення та обмежень платформи — з прикладами, за якими новий розробник вводиться в проєкт без усних пояснень.
- Регламенти відновлення. Покрокові сценарії на випадок пошкодження сцени, розсинхрону між пристроями або збою синхронізації: як відкотитися до останньої цілісної версії і що перевіряти після.
- Скрипти міграції та обслуговування. Оновлення формату сцени між версіями застосунку, чищення застарілих прив'язок, перенесення даних при зміні сховища.
- Метрики та моніторинг. Набір показників стабільності сцен і частки успішних відновлень сесії, щоб деградацію було видно до скарг користувачів.
Кожен пункт узгоджуємо з вашою командою на етапі передачі: розбираємо конфігурації на живому проєкті, проганяємо регламент відновлення на тестовій сцені. Опишіть задачу — повернемося з оцінкою та планом за обсягом цих артефактів.
Кейс: збереження AR-сцен у промисловому застосунку
Замовник — виробник промислового обладнання — прийшов із завданням: сервісні інженери на об'єктах розмічають AR-сценами точки обслуговування вузлів, але розмітка жила лише до закриття застосунку.
Після перезапуску сцена зникала, і інженер калібрував заново за реперними мітками — на це йшло до 15 хвилин на кожен вузол, а частина сцен не відновлювалася взагалі.
Ми переробили зберігання сцен: прив'язка перестала залежати від сесії та від положення камери в момент старту. Кожна сцена отримала стійкий ідентифікатор і прив'язку до фізичних опорних точок об'єкта, а стан зберігається на пристрої та синхронізується між інженерами.
При повторному вході застосунок розпізнає точку, підтягує збережену розмітку та накладає її на поточний вигляд — без ручної калібрування.
Що змінилося в цифрах
| Метрика | До | Після |
|---|---|---|
| Частка успішних повернень у сцену | ~40% | 96% |
| Час повторної калібрування | до 15 хв | 20-30 сек |
| Стійкість при перезапуску | сцена губилася | зберігається |
| Сцени, відновлені після збою | 0 | усі активні |
Окремо закрили стійкість: якщо застосунок падає або пристрій перезавантажується, сцена відновлюється з останнього узгодженого стану, а не з нуля. Інженери перестали витрачати зміну на повторну розмітку — на об'єкті з 30 вузлів економиться кілька годин роботи.
Проєкт вів наш інженер із мобільної розробки спільно з командою замовника; стек і інструменти підбирали під завдання — ARKit та ARCore як базові платформи, поверх — власний шар зберігання сцен.
Чим відрізняється persistent AR від сесійного AR?
Сесійний AR живе рівно стільки, скільки відкрита камера: користувач навів пристрій, побачив об'єкт, закрив екран — і вся сцена зникла.
Persistent AR зберігає прив'язку цифрового об'єкта до фізичного місця між запусками застосунку, тому користувач повертається і бачить те саме наповнення там само, де його залишив.
Різниця починається з якоря. У сесійному режимі якір існує в оперативній пам'яті й помирає разом із сесією — прив'язувати його нема до чого, крім поточного кадру.
У persistent AR якір потрібно зберегти: записати його координати у світовій системі відліку, а потім при новому запуску відновити позицію відносно розпізнаної карти оточення.
Звідси вимога до точності — якщо карта перебудується зі зміщенням, об'єкт «поїде» на десятки сантиметрів, і користувач це помітить одразу.
Далі розходяться архітектура застосунку. Сесійному AR достатньо камери та шару відмалювання: стан живе в пам'яті, синхронізувати нічого.
Persistent AR потребує сховища для якорів і карт, механізму повторної локалізації при вході в зону та правил розв'язання конфліктів, коли два користувачі прив'язують об'єкти до однієї точки.
З'являється серверна частина, а з нею — питання доступу, версіонування сцен і відкату, якщо оновлення карти зіпсувало прив'язки.
Користувацький досвід відрізняється не «ефектами», а сценаріями. Сесійний AR годиться для примірки, демонстрації товару, разової підказки — там цінність у моменті.
Persistent AR відкриває те, що живе в часі: мітки на об'єктах інфраструктури, навігація розміченим будинком, колективні сцени, де кожен наступний відвідувач бачить слід попередніх.
Вибір між підходами — це вибір між разовою взаємодією та накопиченням стану, і він визначає, чи знадобиться застосунку серверна синхронізація взагалі.
Технічні сумніви та обмеження
Persistent AR впирається в чотири інженерні обмеження: підтримку обладнання, обсяг збережуваних даних, захист прив'язок і перенесення вже створених сцен. Розберемо кожне — з тим, як це закривається на практиці.
Сумісність пристроїв
Збереження сцени вимагає, щоб пристрій умів будувати й утримувати карту оточення. На моделях без потрібного набору сенсорів або без підтримки потрібного рівня трекінгу сцена або не відновиться, або встане зі зміщенням.
Тому ми заздалегідь ділимо парк пристроїв на ті, де persistent AR працює повноцінно, і ті, де вмикаємо спрощений режим — з прив'язкою до мітки замість карти. Користувач не бачить різниці в сценарії, але не отримує зламану сцену.
Обсяг даних і безпека прив'язок
Карта оточення та якорі важать небагато, але за сотень сцен на об'єкт сховище починає зростати. Ми тримаємо на пристрої лише активні сцени, решту — на сервері, з довантаженням на вимогу; невикористовувані прив'язки архівуються за правилом зберігання.
Прив'язка — це координата у фізичному світі, і підмінити її означає показати користувачеві чужий об'єкт. Тому запис якоря підписується, а доступ до сцени перевіряється за роллю: гість бачить, редактор змінює, власник видаляє.
Міграція сцен
Сцени, зібрані на старому форматі розмітки, переносяться скриптом: якорі перераховуються в поточну систему координат, вкладення переприв'язуються за ідентифікаторами.
Якщо сцена посилалася на видалений об'єкт, міграція позначає її як таку, що потребує ручної перевірки, а не валить при відкритті.
Що буде, якщо користувач оновить застосунок і сцена не відкриється?
Старі версії формату читаються назад — ми тримаємо сумісність на читання щонайменше на дві гілки назад. Якщо сцена зібрана у форматі, який поточна версія не розуміє, застосунок не падає, а пропонує оновити сцену або відкрити її в режимі перегляду без редагування.
Чи можна відкотити прив'язку, якщо сцена встала зі зміщенням?
Так. Для кожної сцени зберігається попередній стан якоря, і відкат повертає її до робочої прив'язки. Якщо зміщення спричинене зміною самого приміщення, сцену переприв'язують заново — за міткою або за новою картою оточення.
Обговоримо ваше завдання зі збереження AR-сцен
Щоб повернутися з оцінкою та планом впровадження, а не із загальними словами, нам потрібно зрозуміти вашу поточну реалізацію: де зберігаються AR-сцени між сесіями, як прив'язані якорі до фізичного простору і що відбувається при повторному вході в застосунок. Опишіть завдання — інженер розбере його предметно і запропонує робочий варіант.
- Поточний стек: рушій доповненої реальності, платформа (iOS/Android/кроссплатформа), версія та режим трекінгу.
- Як зараз зберігається сцена: локальне сховище, хмара, прив'язка якорів до координат або до візуальних міток.
- Що вже працює і де ламається: втрата позиції при перезапуску, дрейф якорів, розсинхронізація між пристроями.
- Обмеження: офлайн-режим, вимоги до точності прив'язки, кількість одночасних користувачів в одній сцені.
- Цільові метрики: час відновлення сцени, допустиме зміщення об'єктів, частка успішних повторних сесій.
- Доступи та середовище: тестові збірки, пристрої, доступ до бекенду та сховища для перевірки гіпотез.
За цими вхідними даними ми повернемося з оцінкою робіт і планом впровадження: які шари потрібно доопрацювати, що перевикористаємо з поточного коду, а що переписуємо. Консультація інженера на цьому етапі — розбір вашої архітектури та ризиків, а не загальні рекомендації.
Опишіть завдання у вільній формі — надішліть поточну реалізацію, логи або опис збою. Ми повернемося з оцінкою та планом робіт.
