AR-застосунок працює на A17 Pro без нарікань, а на Snapdragon 720G гріється й падає до 20 FPS уже через дві хвилини. Це не баг пристрою — це наслідок того, що ARKit і ARCore мають різні можливості, а 3D-контент, створений без обмежень цільового заліза, ніколи не працюватиме однаково на всьому парку пристроїв. Ми щодня стикаємося з такими задачами й розробили підхід, який гарантує стабільну роботу AR навіть на пристроях з обмеженими ресурсами. Понад 7 років досвіду в AR-розробці та 30+ успішних проєктів дозволяють скоротити витрати на доробки до 40% за рахунок правильної класифікації пристроїв на старті.
Як ми визначаємо цільові пристрої?
Продуктивність AR безпосередньо залежить від класу пристрою. Ми ділимо всі смартфони на три tier і для кожного підбираємо оптимальні налаштування.
| Tier | Приклади пристроїв | Полігональний бюджет | Текстури | Постефекти |
|---|---|---|---|---|
| High | iPhone 15 Pro, Pixel 8 | до 10 000 | 1024×1024 | Тіні, bloom, рефлексії |
| Mid | iPhone 12, Galaxy A54 | до 5 000 | 512×512 | Fake shadow, cubemap |
| Low | iPhone SE 3, Redmi Note 11 | до 2 000 | 256×256 | Вимкнені |
На iOS tier визначається через MTLCreateSystemDefaultDevice().supportsFamily(_:), на Android — через Build.VERSION.SDK_INT, ActivityManager.getMemoryClass() і Session.isDepthModeSupported(). Такий підхід гарантує, що кожен користувач отримає прийнятний досвід без перегріву та лагів. Device Tiers скорочує час тестування в 3 рази порівняно з ручним налаштуванням під кожен пристрій.
Як проходить оптимізація AR-контенту під ключ?
- Аудит поточних 3D-моделей і шейдерів: перевірка полігонального бюджету, формату текстур, використання PBR.
- Налаштування LOD та адаптивних текстур: автоматичне перемикання на спрощені моделі при віддаленні від камери, оптимізація текстур під ASTC.
- Реалізація Device Tiers з динамічним перемиканням: кодова логіка для визначення класу пристрою та завантаження відповідного контенту.
- Тестування на 5+ реальних пристроях різного класу: перевірка FPS, теплового троттлінгу, стабільності сесії.
- Документація та навчання команди: опис архітектури, інструкції з додавання нових моделей.
- Підтримка після впровадження: допомога в інтеграції та доробки під нові пристрої.
Обмеження платформ: ARCore vs ARKit
ARCore мінімально вимагає OpenGL ES 3.0 або Vulkan. Depth API (отримання карти глибини з сенсора) доступний лише на пристроях зі списку Wikipedia: ARCore — це приблизно 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. Перемикання на спрощену модель при віддаленні об'єкта від камери знижує навантаження без видимих втрат. Порівняння: динамічний LOD зменшує навантаження на GPU в 2–3 рази порівняно з єдиним високополігональним асетом.
Текстури: 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.
Як оптимізувати шейдери для різних пристроїв?
Шейдери — основний споживач GPU. Використовуйте Shader Graph з варіантними гілками під різні GPU family. Наприклад, для low-end вимикайте мати, складні нормальні карти та прозорість.
Чому важливо тестувати на mid-range?
Mid-range пристрої становлять >50% ринку. Тестування лише на флагмані дає хибне відчуття стабільності. На mid-range перевіряємо тепловий троттлінг: 5 хвилин активного AR → вимірюємо FPS через fps метрику або CADisplayLink callback. Якщо через 3 хвилини FPS знижується — перегрів, потрібно знижувати якість динамічно при ProcessInfo.thermalState >= .serious.
Мінімальний набір для тестування:
- Флагман поточного року (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)
Зв'яжіться з нами для аудиту вашого AR-проєкту — ми запропонуємо оптимальний план робіт і терміни. Замовте аудит AR-проєкту вже сьогодні. Отримайте консультацію: опишіть завдання, і ми оцінимо обсяг оптимізації вже в перший день.