Оптимізація 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.