Оптимизация AR-контента для различных мобильных устройств
AR-приложение работает на A17 Pro без нареканий, а на Snapdragon 720G греется и падает до 20 FPS уже через две минуты. Это не баг устройства — это следствие того, что ARKit и ARCore имеют разные возможности, а 3D-контент, созданный без ограничений целевого железа, никогда не будет работать одинаково на всём парке устройств.
Ограничения платформ
ARCore минимально требует OpenGL ES 3.0 или Vulkan. Depth API (получение карты глубины с сенсора) доступен только на устройствах из списка ARCore Depth API supported devices — это примерно 30% активных Android-устройств. Instant Placement, Scene Semantics — ещё меньший процент.
ARKit на iOS однороднее, но и здесь есть деление: LiDAR доступен с iPhone 12 Pro. Scene Reconstruction (меш реального мира) требует LiDAR. Без него — только плоскостная детекция.
Ошибка, которую делают часто: приложение разрабатывается на Pro-устройстве с LiDAR, а потом выясняется, что 70% целевой аудитории — пользователи без LiDAR, и весь опыт нужно переделывать.
Оптимизация 3D-моделей для AR
Полигональный бюджет для AR на мобильных — жёстче, чем для игр, потому что AR-рендеринг добавляется поверх camera feed, который сам требует GPU-ресурсов.
Практические ориентиры:
- Объект на переднем плане, детальный: до 10 000 полигонов
- Объект среднего плана, вспомогательный: 1 000–3 000
- Мелкие декоративные элементы: 100–500
LOD (Level of Detail) в AR — обязателен. SceneKit и RealityKit на iOS поддерживают LOD через LODComponent. В Unity с AR Foundation — стандартный LOD Group. Переключение на упрощённую модель при удалении объекта от камеры снижает нагрузку без видимых потерь.
Текстуры: ASTC для iOS и Android. Для AR-объектов нормальных размеров 512×512 достаточно — пользователь смотрит на реальный мир, детали текстуры не так заметны. 2048×2048 для AR-объекта размером с чашку — избыточно.
Адаптивное качество по возможностям устройства
Стратегия Device Tiers: определяем класс устройства при запуске и настраиваем качество контента.
// iOS: определяем tier по GPU family
let device = MTLCreateSystemDefaultDevice()
if device?.supportsFamily(.apple7) == true {
// A15+: максимальное качество, LiDAR-функции
loadHighQualityAssets()
} else if device?.supportsFamily(.apple6) == true {
// A14: среднее качество
loadMediumQualityAssets()
} else {
// A12-A13: базовое, без тяжёлых эффектов
loadBaseQualityAssets()
}
На Android: Build.VERSION.SDK_INT + ActivityManager.getMemoryClass() + проверка поддержки ARCore Depth API через Session.isDepthModeSupported().
Шейдеры и постэффекты
Кастомные PBR-шейдеры в AR тяжелее стандартных, потому что AR-объекты должны визуально вписываться в сцену: ambient occlusion, тени на реальные поверхности, рефлексии от окружения.
На low-end устройствах отключаем:
- Real-time тени (заменяем на fake shadow — спрайт под объектом)
- Bloom и другие постэффекты
- Environment reflections (заменяем на статичный cubemap)
В RealityKit эти параметры управляются через RenderOptions и Environment. В Unity AR Foundation — через Universal Render Pipeline с адаптивными Renderer Features.
Тестирование
Ошибка тестировать AR только на симуляторе или флагмане. Минимальный набор:
- Флагман текущего года (iPhone 15, Pixel 8)
- Mid-range 2–3 летней давности (iPhone 12, Samsung Galaxy A54)
- Low-end без LiDAR/Depth API (iPhone SE 3rd gen, Xiaomi Redmi Note 11)
На низкопроизводительных устройствах важно проверить тепловой троттлинг: 5 минут активного AR → измеряем FPS через fps метрику или CADisplayLink callback. Если через 3 минуты FPS снижается — перегрев, нужно снижать качество динамически при ProcessInfo.thermalState >= .serious.
Сроки оптимизации зависят от объёма AR-контента и платформ: от трёх дней для одного объекта с базовой адаптацией до двух-трёх недель для полноценного multi-tier опыта на iOS + Android.