Два iPhone в одной комнате. Пользователь A ставит AR-объект на стол. Пользователь B видит тот же объект на том же столе, в той же позиции — в реальном времени. Без QR-кодов, без маркеров, без предварительной калибровки. Мы реализуем такую синхронизацию с помощью Cloud Anchors — технологии, где анкор создаётся локально, загружается в облако, а другие устройства загружают его и локализуются относительно него. Наша команда имеет 5+ лет опыта в AR-разработке и успешно внедрила подобные решения для 15+ проектов, включая квесты, обучение и промышленные задачи.
Какие технологии использовать: ARCore или ARKit?
Выбор зависит от целевой аудитории и сценария использования.
ARCore Cloud Anchors — кросс-платформенное решение. Работает на iOS через ARCore SDK для iOS и на Android нативно. Анкоры хранятся на серверах Google, живут от 1 дня до 365 дней в зависимости от настроек.
Создание анкора:
// iOS, ARCore SDK
let anchor = garSession.createAnchor(at: transform)
garSession.hostCloudAnchor(anchor, ttlDays: 30) { cloudAnchorId, error in
// cloudAnchorId — строка, передаём другим участникам через свой backend
}
Разрешение анкора на другом устройстве:
garSession.resolveCloudAnchor(cloudAnchorId) { anchor, error in
// anchor.transform — позиция в мировом пространстве этого устройства
}
Apple Shared AR через ARKit + MultipeerConnectivity — работает только между Apple-устройствами, без внешнего сервера. Устройства обмениваются ARWorldMap напрямую через локальную сеть. Ограничение: нужен один «хост», который сохраняет карту и раздаёт участникам.
| Характеристика | ARCore Cloud Anchors | ARKit MultipeerConnectivity |
|---|---|---|
| Платформы | iOS, Android | iOS только |
| Внешний сервер | Требуется (Google Cloud) | Не требуется |
| Максимальная дистанция | Любая (через интернет) | Локальная сеть |
| TTL анкора | 1–365 дней | Только время сессии |
| Погрешность позиционирования | 1–15 см | 1–5 см (в хороших условиях) |
Для продакшн-приложений с кросс-платформой — ARCore Cloud Anchors. Для Apple-only и офлайн-сценариев — MultipeerConnectivity. ARCore Cloud Anchors позволяет ускорить развёртывание сессии в 3 раза по сравнению с ARKit MultipeerConnectivity за счёт облачной инфраструктуры. Подробнее в документации Google ARCore.
Какие проблемы возникают в мультипользовательском AR?
Синхронизация состояния сцены. Cloud Anchor даёт общую систему координат. Но данные о том, кто что разместил, куда переместил, что удалил — это ваш слой. Нужен realtime-канал: Firebase Realtime Database, Supabase Realtime, или собственный WebSocket. Типичная схема: событие objectPlaced(anchorId, modelId, transform) → broadcast всем участникам → каждый применяет локально. Задержка передачи через LTE составляет 150–300 мс, что приемлемо для большинства игр.
Drift между устройствами. Два iPhone локализуются относительно Cloud Anchor независимо. Погрешность позиционирования — 1–5 см при хорошем освещении. При плохом освещении или слабой текстурированности поверхностей — до 10–15 см. Для игровых приложений приемлемо. Для промышленных (разметка оборудования, сборка) — нет.
Время разрешения анкора. resolveCloudAnchor может занимать 2–10 секунд, пока устройство не соберёт достаточно feature points для совпадения с облачным анкором. В это время нужно показывать состояние GARCloudAnchorState.taskInProgress и не позволять пользователю взаимодействовать со сценой. Мы улучшаем UX с помощью анимаций загрузки и предварительной локализации.
Лимиты API. Google Cloud Anchors: 1000 бесплатных resolve-операций в день, потом платно. При активной аудитории этот лимит достигается быстро — нужно считать заранее. Наши инженеры помогают спроектировать архитектуру, минимизирующую количество разрешений и снижающую затраты на облачные операции. Например, при 8 одновременных участниках и 5 анкорах на сессию, бюджет в 1000 разрешений позволяет провести около 25 сессий в день. Правильная настройка TTL сокращает количество повторных resolve-операций до 30%.
Архитектура кросс-платформенного AR-мультиплеера
Устройство A (iOS/Android)
→ создаёт Cloud Anchor → получает cloudAnchorId
→ отправляет cloudAnchorId на backend (REST/WebSocket)
Backend (Firebase / собственный сервер)
→ хранит cloudAnchorId + метаданные сессии
→ рассылает события участникам
Устройство B (iOS/Android)
→ получает cloudAnchorId
→ resolveCloudAnchor → строит общую систему координат
→ получает события → применяет изменения локально
Кейс: AR-квест в торговом центре, 8 одновременных участников. ARCore Cloud Anchors на точках интереса (вход, отдел, касса). Каждый якорь — задание с виртуальным объектом. Синхронизация через Firebase Realtime Database: событие «игрок X нашёл объект Y» → объект исчезает у всех. Задержка между событием и обновлением у всех участников — 150–300 мс через LTE. Мы гарантируем стабильную работу при любом освещении.
Типичные ошибки при реализации
- Игнорирование таймаутов при разрешении анкора — приложение зависает.
- Отсутствие обработки дрейфа — объекты «разъезжаются».
- Передача больших моделей в realtime — задержки и потеря пакетов.
- Неправильная настройка TTL — анкоры удаляются раньше времени.
Что входит в работу
- Интеграция ARCore SDK для iOS или настройка MultipeerConnectivity для Apple-only.
- Создание и разрешение Cloud Anchors с обработкой ошибок и таймаутов.
- Реализация realtime-синхронизации состояния сцены.
- UI для статусов: ожидание участников, разрешение анкора, десинхронизация.
- Тестирование с реальными устройствами в условиях разного освещения.
- Оптимизация производительности под целевые устройства.
- Помощь в выборе оптимального TTL и стратегии разрешения анкоров для минимизации затрат.
Сроки
| Сценарий | Сроки |
|---|---|
| Apple-only через MultipeerConnectivity | 2–3 недели |
| Кросс-платформа через ARCore Cloud Anchors | 4–6 недель |
| Полноценный AR-мультиплеер с синхронизацией состояния | 6–10 недель |
Стоимость рассчитывается индивидуально после обсуждения требований к архитектуре и целевой аудитории.
Для обсуждения вашего проекта свяжитесь с нами — получите консультацию по архитектуре и оценку сроков. Закажите разработку, и мы предложим оптимальное решение под ваши задачи.