Разработка AR-приложений: дополненная реальность под задачу бизнеса

Разработка AR-приложений: где проект ломается на старте

Разработка AR-приложений редко ломается на демо и почти всегда — на реальном объекте. В демонстрации ровный стол, хороший свет и медленное движение камеры, поэтому всё держится. В поле сцена ведёт себя иначе: потеря трекинга сцены случается на однотонной стене, при резком повороте устройства или в помещении с бликами и зеркальными поверхностями. Камера перестаёт опознавать окружение, система координат пересобирается заново — и объект, который только что стоял на столе, уезжает от поверхности на сантиметры, а иногда и на метры.

Второй класс сбоев — дрейф 3D-объектов. Привязка к якорю без регулярной сверки с распознанной геометрией накапливает ошибку: объект медленно «плывёт» вдоль плоскости, меняет масштаб и наклон. На коротком сеансе это незаметно, на длинном — расхождение становится очевидным, и никакая аккуратная 3D-модель это не компенсирует. Причина почти всегда в архитектуре сцены, а не в контенте: якорь выставлен один раз и больше не перепроверяется.

Третий — перегрев устройства. Камера, отрисовка и распознавание работают одновременно и непрерывно, тепловой бюджет среднего аппарата заканчивается быстрее, чем кажется. Система сначала снижает частоту кадров, картинка начинает отставать от движения руки, а затем приложение закрывается. На флагманских устройствах проблема замаскирована, поэтому её легко пропустить на этапе тестов и получить на парке обычных телефонов.

Все три сбоя лежат в одной плоскости — в том, как устроен цикл сессии, выбор якорей и бюджет нагрузки на кадр. Дальше разбираем, как это закрывается на уровне архитектуры и профиля устройств, а не косметическими правками.

Что меняется после внедрения: пять измеримых эффектов

Первый эффект — удержание виртуального объекта в кадре. Раньше модель сползала с точки привязки при повороте камеры: якорь терялся, и объект приходилось ставить заново. Сейчас положение пересчитывается по геометрии сцены, объект остаётся на месте, пока пользователь обходит его кругом, а накопленная за сессию погрешность измеряется сантиметрами и не растёт со временем.

Второй — стабильность трекинга в реальных условиях: слабое освещение, однотонные поверхности, резкие повороты устройства. Запас по этим сценариям закладывается на прототипе, поэтому в отчёте видна не усреднённая цифра, а доля сессий, где трекинг не потерялся ни разу и объект не «съехал».

Третий и четвёртый — время холодного запуска AR-режима и отклик на действие пользователя. Первый переход в камеру укладывается в пару секунд, потому что модели и текстуры догружаются фоном и не блокируют сцену. Отклик на касание — доли секунды: для примерки или наведения на объект задержка читается как «сломалось», а не как «медленно».

Пятый — доля устройств, где функция работает предсказуемо: это парк, прошедший проверку на живой сборке, а не список из документации. Здесь же закрывается целый класс отказов — рассинхрон положения камеры и виртуальной сцены, из-за которого приложение показывает объект мимо цели или уходит в тёмный экран.

Варианты реализации: нативный модуль, движок или веб

Три подхода отличаются не качеством картинки, а тем, куда встраивается дополненная реальность и какую цену вы платите на сопровождении. Нативный AR-модуль опирается на платформенные наборы — ARKit и ARCore: доступ к трекингу плоскостей, оценке освещения и камере полный, но логика дублируется под каждую платформу.

Веб-сцена в браузере снимает барьер установки: пользователь переходит по ссылке и сразу видит модель в кадре. Плата за это — ограниченный доступ к датчикам, просадка на тяжёлых сценах и зависимость от версии браузера. Ниже — что под какой сценарий.

Гибридную схему берут, когда веб-сцена закрывает быстрый вход, а нативный модуль берёт на себя тяжёлые сцены внутри приложения. Такой вариант дороже в поддержке, поэтому границу между ветками мы фиксируем до старта разработки — иначе расхождение поведения всплывает уже у пользователей.

Этапы работы: от постановки задачи до передачи

Этапы внедрения AR строим так, чтобы технические риски снимались раньше, чем в проект уйдёт основная часть работы: дороже всего ошибка в схеме сцены, обнаруженная на финальной сборке. Поэтому первые шаги — про сценарий и геометрию, а не про код.

1. Разбор сценария. Фиксируем, куда смотрит камера, что пользователь делает руками и какое действие считаем успехом. На выходе — измеримый критерий приёмки, а не «должно выглядеть эффектно».
2. Схема сцены. Раскладываем якоря, опорные плоскости, зоны взаимодействия и масштаб объектов относительно роста человека. Схема сцены становится общим документом для дизайна, разработки и приёмки.
3. Прототип AR-функции. Собираем минимальную версию на одной модели устройства: проверяем, что сценарий воспроизводится в реальном помещении, а не только на тестовой разметке.
4. Трекинг и окклюзия. Настраиваем распознавание поверхностей, перекрытие виртуальных объектов реальными и поведение сцены при потере трекинга — это определяет, «держится» ли картинка при движении и слабом свете.
5. Проверка на парке устройств. Прогоняем сборку на разных поколениях камер и разной производительности (ARKit и ARCore ведут себя на одном и том же помещении по-разному). Фиксируем, где проседает устойчивость.
6. Приёмка. Проходим чек-лист по сценариям и устройствам, сверяем с критериями из первого шага, оформляем протокол с известными ограничениями.
7. Передача. Отдаём исходники, схему сцены, политику обновлений и инструкцию по добавлению новых моделей — команда заказчика может развивать AR-блок без нас.

Что передаём на руки: сборка, схемы, регламенты

Передача — это не архив с исходниками, а набор артефактов, по которым ваша команда или наши инженеры поддержки воспроизводят сборку, правят сцену и обновляют контент без разбора чужого кода. Ниже — что входит в комплект по AR-модулю.

• Рабочая сборка — собранные варианты приложения под целевые платформы, конфигурация окружения и скрипты, которыми сборка повторяется с нуля на чистой машине.
• Схема сцены — иерархия узлов, привязка якорей и точек размещения, логика распознавания плоскостей и поведение объектов при потере трекинга.
• Правила доступа к контенту — роли и права: кто публикует и снимает модели, где лежат исходники, как устроены версионирование и откат публикации.
• Документация по AR-модулю — точки расширения, контракты между слоями, зависимости платформенных компонентов и порядок их обновления.
• Регламент обновления моделей — требования к форматам и оптимизации, проверки перед публикацией, порядок замены контента без пересборки приложения.
• Инструкция для поддержки — типовые отказы, на что смотреть в журналах, как откатить приложение и вернуть предыдущую версию сцены.
• Матрица доступов — где хранятся ключи подписи и аккаунты публикации, кто владелец, как они передаются при смене подрядчика.

Комплект обновляется при каждом изменении модуля: если правка не отражена в схеме сцены или регламенте, передача считается неполной.

Кейс: примерочная в приложении — что было до и после

В приложении сети одежды Модный дом примерка была отдельным экраном, до которого доходил один покупатель из семи. Сцена с вещами открывалась 4–5 секунд, модель «плавала» относительно тела, а при повороте камеры обрывалась; в торговом зале при слабом свете трекинг терялся почти сразу. По логам: 62% сессий примерки заканчивались ошибкой, средняя длительность — 8 секунд, добавлений в корзину из примерочной почти не было.

Что перестроили в сцене и трекинге

Вещи пересобрали под мобильный вывод: упрощённая геометрия и заранее подготовленные текстуры вместо тяжёлых исходных моделей — вес сцены упал в разы, первый кадр появляется заметно раньше. В трекинге добавили предсказание положения тела и сглаживание — вещь держится на месте при быстрых движениях и поворотах, а не «отклеивается». Вместо одной универсальной модели держим несколько посадок и подбираем их по замерам покупателя, поэтому примерка перестала быть «на глазок».

Порог освещённости выставили по замерам в реальных залах: вместо сообщения об ошибке приложение подсказывает, куда встать. Это убрало самый частый сценарий отказа — покупатель не бросал примерку, а доводил её до конца.

Метрики до и после

Доля успешных сессий примерки — с 38% до 94%. Время до первого кадра — с 4–5 секунд до 1,5. Средняя длительность примерки выросла с 8 секунд до полутора минут, доля добавлений в корзину после примерки — втрое, а возвраты с причиной «не подошло по посадке» снизились примерно на четверть.

Чем AR-примерка отличается от 3D-превью на сайте

3D-превью живёт внутри экрана: модель вращается на нейтральном фоне, а масштаб пользователь достраивает сам — встанет ли предмет рядом с диваном, подойдёт ли по высоте к полке. AR-примерка это допущение снимает: камера показывает помещение, приложение распознаёт плоскость и ставит объект туда в реальных пропорциях.

Технически разница — в привязке к поверхности. Приложение определяет плоскость, отслеживает положение устройства в пространстве, подстраивает масштаб и учитывает освещение, поэтому объект не плавает и не проваливается, а тень ложится под ножки. Это и отвечает на вопрос «а влезет ли», на который вращаемая модель ответить не может.

Сценарий использования определяет выбор, а не сама технология. Обувь, часы, аксессуары, техника в упаковке — форме и цвету достаточно вращаемой модели: грузится быстро, открывается на любом устройстве. Мебель, крупногабаритная техника, декор и всё, что примеряется «на себе», требуют привязки к поверхности: там решает габарит.

Поведение пользователя отличается. Превью увеличивает глубину просмотра и число сравнений, AR-примерка — долю дошедших до заказа и снижает возвраты «не подошло по размеру». Плата — лишние шаги: разрешение на камеру, наведение на поверхность, ожидание распознавания, и часть аудитории на них отсеивается.

Поэтому мы не ставим выбор «или». В типовом сценарии превью закрывает вход в каталог, а AR-примерка — этап решения по позициям, где важен габарит; разделение задаётся по категориям, и уже от него считается остальная архитектура приложения.

Технические сомнения: устройства, свет, точность

Ограничения сцены задаёт не код, а связка камеры, инерциальных датчиков и платформенных библиотек. Ниже — четыре вопроса, которые чаще всего всплывают на приёмке, и то, как мы закрываем каждый.

Что происходит при слабом освещении?

Камера не находит характерные точки: сцена «плывёт», объекты дрожат и смещаются. Мы выводим индикатор качества трекинга, просим добавить света и переводим объект в режим привязки к плоскости вместо покадрового совмещения. Ниже порога освещённости показываем понятное сообщение, а не артефакты.

Насколько точны измерения в сцене?

Погрешность зависит от дистанции и текстуры поверхности: вблизи по размеченной плоскости это единицы сантиметров, на дальних и однотонных участках растёт. Там, где точность критична, мы ограничиваем рабочую зону и вводим эталонную метку известного размера — так ошибка не накапливается по мере обхода.

Работает ли сцена без сети?

Распознавание и трекинг считаются на устройстве, поэтому в офлайне сцена запускается и держится. Сеть нужна для контента и аналитики: материалы упаковываем в локальный кэш, события копим и отправляем пачкой при появлении связи. Тяжёлый контент догружается фоном в зоне Wi-Fi, чтобы в поле пользователь не ждал загрузку.

Обсудим задачу и вернёмся с оценкой и планом работ

Чтобы оценка AR-проекта была предметной, а не «на глаз», нам нужны вводные по задаче: что распознаём, в каких условиях это должно работать и на каких устройствах. Дополненная реальность чувствительна к сценарию — трекинг по маркеру, по плоскости и по координатам даёт разную трудоёмкость и разные требования к контенту, который придётся готовить.

Что прислать для старта:

• описание сценария: что пользователь видит в камере и что происходит после распознавания;
• список устройств и минимальные версии мобильных систем, которые нужно поддержать;
• материалы — модели, фото, видео, чертежи; если их нет, так и напишите, источники контента обсудим отдельно;
• 2-3 приложения-референса и пояснение, что именно в них нравится с точки зрения поведения;
• ограничения: дата события или запуска, требования по доступам к данным, существующая инфраструктура;
• есть ли готовое приложение, в которое AR встраивается, или сборка идёт с нуля.

Отдельно уточним то, что обычно всплывает уже в работе: как ведёт себя сцена при слабом освещении, нужна ли работа без сети, что происходит при потере трекинга и как приложение вернёт пользователя в сцену.

В ответ вернёмся с планом работ: состав команды с ролями, этапы и их длительность, что делаем на каждом этапе и в какой момент вы принимаете результат. Отдельным пунктом — риски сценария и запас на них. Опишите задачу в свободной форме — дальше разберёмся по ходу диалога.