Аудит продуктивності AR-застосунку: рендеринг і thermal
AR-застосунок на ARKit гріє iPhone до 45°C за 8 хвилин та розряджає батарею на 1% щохвилини. Frame rate — 45–50 FPS замість стабільних 60. Це не «трохи гальмує» — це продукт, яким неможливо користуватися. Оптимізація продуктивності AR-застосунку потребує системного підходу — не просто профілювання, а усунення першопричин теплового дроселювання та GPU overload. Ми спеціалізуємося на цьому: за 5 років роботи і 50+ проектів з ARKit та ARCore ми знаємо, де саме втрачається продуктивність і як це виправити. Наш аудит займає 2–3 дні й показує конкретні вузькі місця — без загальних рекомендацій.
Оптимізація AR — особлива дисципліна: не можна пожертвувати точністю трекінгу задля FPS, не можна вимкнути освітлення і втратити реалізм. Потрібно одночасно працювати з CPU (ARKit/ARCore-обробка), GPU (рендеринг) та Neural Engine (ML-моделі, де є). Правильний баланс між ними дає стабільні 60 FPS та температуру нижче 40°C навіть після 20 хвилин сесії.
Що входить в оптимізацію AR-продуктивності
- Профілювання сесії в Instruments та Android GPU Inspector — виявлення CPU, GPU та thermal-дроселювання.
- Аудит конфігурації ARKit/ARCore — відключення невикористовуваних фіч трекінгу та освітлення.
- Оптимізація 3D-активів: LOD, decimation, конвертація текстур у ASTC/ETC2.
- Перехід з SceneKit/ARSCNView на Metal (ARKit) або Filament (ARCore) там, де потрібен повний контроль рендерингу.
- Налаштування frustum culling та distance-based LOD для AR-сцен із кількома об'єктами.
- Тестування на фізичних пристроях API 26–34 (Android) та iOS 14–17.
- Гарантований вимірюваний результат або продовжуємо роботу безоплатно.
Де виникають проблеми: типові вузькі місця
| Проблема | Причина | Вплив |
|---|---|---|
| FPS 24–40 при 2+ об'єктах | 3D-моделі 800K–1.2M полігонів без LOD | GPU overload |
| Нагрів до 45–50°C | Thermal-дроселювання CPU+GPU | Примусове зниження FPS |
| Батарея -1%/хв | LightEstimationMode.ENVIRONMENTAL_HDR | Фонова обробка HDR |
| Лаг при розміщенні | Завантаження текстур 4096×4096 у main thread | Пропуск кадрів |
Вузькі місця AR-застосунку рідко бувають одним — зазвичай 3–5 проблем одночасно. Профілювання виявляє всі відразу, і ми усуваємо їх у порядку пріоритету.
Як правильно налаштувати ARKit-сесію?
Перший крок — відключити функції, які не використовуються. ARWorldTrackingConfiguration з isAutoFocusEnabled = true та environmentTexturing = .automatic без реальної необхідності дають постійне навантаження на систему. Для більшості AR-застосунків достатньо planeDetection = [.horizontal] та isAutoFocusEnabled = false.
ARSCNView зручний, але для складних сцен MTKView + кастомний Metal-рендерер дає повний контроль над draw calls. Metal pipeline — faster than ARSCNView на сценах з 10+ AR-об'єктами: приріст FPS складає 20–30% за рахунок прямого управління draw calls та виключення SceneKit overhead.
SCNNode.isHidden = true для об'єктів поза полем зору — SceneKit не рендерить приховані ноди, але виконує physics та update. Правильніше — видаляти об'єкти зі сцени через node.removeFromParentNode().
Оптимізація ARCore (Android): конфігурація та Filament
LightEstimationMode.ENVIRONMENTAL_HDR — найдорожчий режим. На пристроях без Depth API (більшість mid-range до API 30) використовувати тільки якщо це ключова фіча. Відключення дає +15% ресурс батареї та знижує температуру на 3–5°C.
ARCore-застосунки з Filament рендерять PBR-матеріали через Vulkan на підтримуваних пристроях — помітно швидше, ніж через OpenGL ES. На пристроях з Vulkan (API 24+) різниця у frame time складає 8–12 мс.
planeFindingMode = Config.PlaneFindingMode.HORIZONTAL_ONLY замість HORIZONTAL_AND_VERTICAL дає 10–15% зниження навантаження на CPU для задач, де вертикальні поверхні не потрібні. Архітектурна особливість ARCore полягає у відокремленні підсистем комп'ютерного зору від координатного відстеження, що дозволяє незалежно масштабувати обчислювальне навантаження кожного компонента відповідно до поточних теплових обмежень апаратного забезпечення.
З нашої практики: AR-меблевий каталог
Наш клієнт — застосунок для перегляду меблів у AR. Дивани та столи — 3D-моделі від дизайнерів, по 800K–1.2M полігонів кожна. На iPhone 13 — 24 FPS при розміщенні 2 об'єктів. Проблема очевидна.
Що ми зробили: експорт моделей через Blender з decimation до 50K полігонів для AR-версії (втрата деталізації невидима з дистанції 1–2 метри на екрані телефону). Конвертація текстур з PNG 4096×4096 у ASTC 2048×2048. Додавання LOD: висока деталізація для об'єктів ближче 1.5 метра, середня — далі.
Результат: стабільні 58–60 FPS, температура нормалізувалась до 38°C, тривалість сесії без дроселювання зросла з 4 до 18 хвилин.
Наш процес оптимізації AR: покроково
- Профілювання сесії в Instruments (iOS) або Android GPU Inspector — виявляємо bottle neck: CPU, GPU, або thermal.
- Аналіз конфігурації ARKit/ARCore — відключаємо все невикористовуване.
- Аудит 3D-активів — decimation, LOD, ASTC/ETC2 текстури.
- Рефакторинг рендерингу — Metal або Filament замість SceneKit/ARSCNView де потрібно.
- Впровадження frustum culling та distance-based LOD.
- Тестування на пристроях різних класів: low-end (Snapdragon 660, A12) та flagship (S24, iPhone 15).
- Вимірювання результату в Instruments — порівнюємо frame time та thermal state до і після.
Які результати ви отримаєте після оптимізації?
Після нашої роботи застосунок показує результати краще ніж до оптимізації: стабільні 58–60 FPS замість 30–45, температура нижче 40°C навіть після 20 хвилин активної AR-сесії. Відсоток примусових пауз через thermal throttling падає з 40–60% до нуля на переважній більшості пристроїв. Наші клієнти відзначають зростання тривалості сесій на 30–50% після усунення thermal-проблем.
Моніторинг продуктивності AR у production
Після завершення оптимізації критично важливо налагодити безперервний моніторинг продуктивності у production середовищі, оскільки подальше додавання 3D-активів або оновлення бібліотек можуть повернути проблеми дроселювання. На iOS платформі ARSession надає frame.rawFeaturePoints для оцінки інтенсивності навантаженості підсистеми трекінгу, а MetricKit (iOS 13+) автоматично агрегує статистику середнього значення frame rate та градаційні стани теплового режиму процесора протягом усієї тривалості сесії.
На Android: Frame.getTimestamp() різниця між послідовними кадрами — якщо перевищує 33 мс, кадр пропущено і система перебуває у режимі примусового дроселювання продуктивності. Рекомендуємо встановити автоматичні сповіщення: якщо середній час рендерингу кадру перевищує 30 мс протягом більш ніж 10% загальної кількості кадрів у середині сесії — необхідне повторне профілювання та комплексна діагностика продуктивності. Зазвичай це сигналізує про появу нових 3D-активів без попередньої оптимізації або несанкціоновану зміну конфігурації AR-сесії.
Вартість оптимізації AR-продуктивності
| Обсяг роботи | Вартість | Строки |
|---|---|---|
| Аудит продуктивності (звіт + рекомендації) | від 300 USD | 2–3 дні |
| Оптимізація однієї платформи (iOS або Android) | від 700 USD | 5–10 днів |
| Обидві платформи під ключ | від 1200 USD | 10–15 днів |
| Оптимізація 3D-активів (окремо) | від 200 USD | 1–3 дні |
Apple Developer Documentation: "Use the Instruments app to identify performance bottlenecks in your AR experience." (developer.apple.com/documentation/arkit/)
Наші результати стабільніші, ніж у команд без досвіду AR-оптимізації, бо ми враховуємо thermal management, а не лише GPU metrics. Зв'яжіться з нами для безкоштовної оцінки застосунку — надішліть ІРА або APK, і ми скажемо де проблеми за 1 день.