Представьте: дизайнер интерьера расставил виртуальные предметы в пустой комнате, закрыл iPad, а на следующий день открывает — и вся сцена точно на своих местах. Без повторной расстановки. Это Persistent AR — функция сохранения AR-сцен между сессиями, которую мы реализуем под ключ. В коммерческих AR-приложениях срыв релокализации — главная причина негативных отзывов. Мы научились гарантировать восстановление сцены в 95% случаев. На протяжении более 5 лет мы разрабатываем AR-решения для iOS и Android, выполнив более 15 коммерческих проектов, где критична стабильность релокализации. Свяжитесь с нами, чтобы обсудить ваш проект.
Как работает Persistent AR?
ARKit использует ARWorldMap — снимок визуальных ориентиров (feature points), который позволяет восстановить позицию камеры относительно сохранённого окружения. Сериализация, локальное или облачное хранение, загрузка и запуск новой сессии с initialWorldMap — каждый шаг требует внимания к деталям. Пример сериализации на Swift:
arView.session.getCurrentWorldMap { worldMap, error in
guard let worldMap = worldMap else { return }
let data = try? NSKeyedArchiver.archivedData(withRootObject: worldMap, requiringSecureCoding: true)
// сохраняем data на диск или в облако
}
Загрузка в новой сессии:
let worldMap = try? NSKeyedUnarchiver.unarchivedObject(ofClass: ARWorldMap.self, from: data)
let config = ARWorldTrackingConfiguration()
config.initialWorldMap = worldMap
session.run(config, options: [.resetTracking, .removeExistingAnchors])
После запуска ARKit пытается сопоставить текущую сцену с сохранёнными точками. Статус отслеживается через session(_:cameraDidChangeTrackingState:): переход от .limited(.relocalizing) к .normal означает успех. Подробнее в документации ARKit.
Почему релокализация может не сработать?
Изменение освещения. Днём и ночью — разные наборы feature points; контрастность может упасть на 30–50%. Мы решаем это сохранением нескольких карт при разном освещении с выбором ближайшей по метрике совпадения. Visual-Inertial Odometry имеет фундаментальные ограничения, поэтому встроенными средствами ARKit этого не обойти.
Дрейф якорей. При восстановлении позиция ARAnchor может сместиться на 2–5 см. Для объектов, где точность критична (например, виртуальная мебель), после релокализации мы подтягиваем якоря к ближайшей поверхности через raycast.
Недостаточное качество карты. У ARWorldMap есть свойство mappingStatus: .notAvailable, .limited, .extending. Сохранять карту при .limited — обречь пользователя на провал. Мы блокируем кнопку «Сохранить» до достижения .extending и выводим подсказку: «Медленно обойдите комнату».
Как улучшить качество карты?
Вот три рабочих подхода, проверенных в production:
- Сбор данных при движении. Заставляем пользователя пройти по комнате не менее 30 секунд — это увеличивает количество feature points на 70% по сравнению со статической съёмкой.
- Фильтрация по mapping status. Не сохраняем карту, пока статус не .extending. Иначе релокализация будет нестабильной.
- Сжатие без потерь. Используем LZFSE (iOS 16+) или LZMA для архивации. Результаты:
| Метод | Размер (20 МБ исходник) | Время сжатия |
|---|---|---|
| Без сжатия | 20 МБ | 0 с |
| LZFSE | 4 МБ | 0.3 с |
| LZMA | 1.5 МБ | 2.1 с |
Сжатие LZFSE даёт выигрыш в 5 раз по размеру при минимальной задержке — оптимально для облачной синхронизации.
Хранение пользовательских данных с картой
Анкоры сохраняются в ARWorldMap.anchors, но метаданные объектов (модель, цвет, цена) нужно хранить отдельно и связывать по ARAnchor.identifier. Пример:
let metadata: [String: Any] = [
anchor.identifier.uuidString: ["type": "sofa", "modelName": "ikea_kallax"]
]
При восстановлении матчим по UUID. Это стандартная практика, но её часто пропускают, пытаясь запихнуть данные в ARAnchor.name — строка из 256 символов без типизации. Для синхронизации между устройствами используем CloudKit или Firebase, сериализуя карты с LZFSE.
Кейс из нашей практики
Приложение для interior design с 3000 активных пользователей. Главная боль: пользователи сохраняли карту сразу после запуска (.limited mapping status) — и жаловались на «плавающие» объекты. Мы добавили UI-индикатор качества карты (зелёный/жёлтый/красный) с блокировкой сохранения до зелёного. Жалобы снизились на 80%, а время релокализации сократилось на 40% за счёт исключения неудачных карт.
Что входит в работу
- Анализ требований: сценарии использования, целевые устройства и версии iOS
- Проектирование схемы сохранения: локально или облако, поддержка мультиустройств
- Реализация сериализации/десериализации ARWorldMap с учётом сжатия
- Интеграция облачной синхронизации (CloudKit, Firebase)
- Тестирование на 10+ моделях iPhone/iPad с разными версиями iOS
- Документация: архитектура, ограничения, инструкция для тестировщиков
- Поддержка 1 месяц после сдачи
Сроки
| Функциональность | Сроки |
|---|---|
| Базовое сохранение/восстановление сцены | 1–2 недели |
| Облачная синхронизация карт + мульти-устройство | 3–4 недели |
| Интеллектуальная релокализация + управление качеством | 2–3 недели |
Стоимость рассчитывается индивидуально после анализа требований. Получите консультацию по вашему проекту — мы поможем реализовать Persistent AR на iOS или Android.