Оптимизация производительности AR-приложения под ключ

AR-приложение на ARKit греет iPhone 12 до 45°C за 8 минут сессии и разряжает батарею на 1% в минуту. Frame rate — 45–50 FPS вместо 60. Это не «немного тормозит» — это приложение, которым нельзя пользоваться. За 5 лет мы оптимизировали более 50 AR-проектов — от мебельных каталогов до промышленных визуализаций — и знаем, как выжать максимум из железа.

Оптимизация AR — особая дисциплина: нельзя пожертвовать качеством трекинга ради FPS, нельзя убрать освещение и потерять реализм, нужно работать одновременно с CPU (ARKit/ARCore обработка), GPU (рендеринг) и Neural Engine (если есть ML-модели). Мы гарантируем результат: стабильные 60 FPS и экономию батареи до 30%.

Почему AR-приложение греется и теряет FPS?

ARKit/ARCore работают непрерывно: захват кадра с камеры → feature detection → плоскостная оценка → обновление мировой модели → рендеринг. Каждый этап — вычислительная нагрузка. На iPhone ARKit использует Neural Engine для плоскостного трекинга, что сильно разгружает CPU/GPU. На Android ARCore — тяжелее для GPU на устройствах без NPU.

Типичные узкие места:

• Загрузка тяжёлых 3D-моделей в ARSCNView без оптимизации: SCNNode с 500K полигонов без LOD, текстуры 4096×4096 без mipmapping. GPU рендерит одинаково детально объект на переднем плане и в 10 метрах от камеры.
• Включённые фичи трекинга, которые не используются. ARWorldTrackingConfiguration с isAutoFocusEnabled = true и environmentTexturing = .automatic без реальной необходимости — постоянная нагрузка на систему.
• Физика в SCNScene с SCNPhysicsBody на каждом объекте при десятках AR-объектов — физический движок SceneKit не оптимизирован для мобильных AR-сцен с большим количеством тел.

Как мы оптимизируем ARKit: конфигурация сессии и рендеринг

Конфигурация сессии

let configuration = ARWorldTrackingConfiguration()

// Включаем только то что реально нужно
configuration.planeDetection = [.horizontal] // не .vertical если не нужно
configuration.isAutoFocusEnabled = false     // фиксированный фокус — меньше нагрузки
configuration.environmentTexturing = .none  // отключаем если нет PBR-материалов

// Для простых сцен — lighter tracking
let simpleConfig = AROrientationTrackingConfiguration() // только ориентация, без world tracking

Для приложений где нужен только face tracking — ARFaceTrackingConfiguration вместо ARWorldTrackingConfiguration. Разница в нагрузке на CPU — ощутима.

Рендеринг через Metal вместо SceneKit

ARSCNView удобен, но для сложных сцен MTKView + кастомный Metal-рендерер даёт полный контроль над draw calls. SceneKit добавляет overhead на управление нодами и физику. С ARSession + MTKView:

func session(_ session: ARSession, didUpdate frame: ARFrame) {
    let commandBuffer = commandQueue.makeCommandBuffer()!
    // Рендерим captured image (камера)
    renderCapturedImage(frame.capturedImage, commandBuffer: commandBuffer)
    // Рендерим AR-контент
    renderVirtualContent(frame, commandBuffer: commandBuffer)
    commandBuffer.present(drawable)
    commandBuffer.commit()
}

Это даёт 20–30% прирост FPS на сценах с 10+ AR-объектами по сравнению с ARSCNView.

Culling и LOD

SCNNode.isHidden = true для объектов вне поля зрения — SceneKit не рендерит скрытые ноды, но выполняет physics и update. Правильно — убирать объекты из сцены: node.removeFromParentNode().

// Frustum culling вручную
func shouldRenderNode(_ node: SCNNode, camera: ARCamera) -> Bool {
    let screenPoint = camera.projectPoint(node.worldPosition,
                                          orientation: .portrait,
                                          viewportSize: viewportSize)
    return screenPoint.x > -0.1 && screenPoint.x < 1.1 &&
           screenPoint.y > -0.1 && screenPoint.y < 1.1
}

Что делать с ARCore: сессия и рендеринг

Session config

val config = Config(session)
config.planeFindingMode = Config.PlaneFindingMode.HORIZONTAL_ONLY
config.lightEstimationMode = Config.LightEstimationMode.DISABLED // +15% battery
config.depthMode = Config.DepthMode.DISABLED // если глубина не нужна
session.configure(config)

LightEstimationMode.ENVIRONMENTAL_HDR — самый дорогой режим, даёт реалистичные отражения. На устройствах без Depth API (большинство mid-range) использовать только если это ключевая фича.

Rendering через Filament

ARCore-приложения с Filament (Google's PBR renderer) рендерят PBR-материалы через Vulkan на поддерживаемых устройствах — заметно быстрее чем через OpenGL ES. Готовый пример — arcore-android-sdk samples с Filament-интеграцией.

Как добиться стабильных 60 FPS в AR?

Ключевые шаги:

• Отключить неиспользуемые функции трекинга (environmentTexturing, autoFocus, depth mode).
• Перейти на низкоуровневый рендеринг (Metal или Vulkan).
• Применить LOD и culling к 3D-моделям.
• Сжать текстуры (ASTC, ETC2).

Сравнение подходов ARKit vs 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 стабильно, температура нормализовалась. Клиент сэкономил около $5 000 на доработках, избежав полного переписывания приложения.

Как проходит оптимизация: пошаговый процесс

1. Аудит производительности — профилирование на реальных устройствах (iPhone 12, Pixel 6 и т.д.), замер FPS, температуры, расхода батареи. Фиксация baseline.
2. Анализ и планирование — выявление узких мест, составление плана доработок с приоритетами.
3. Доработка — оптимизация конфигурации сессии, рендеринга, 3D-моделей.
4. Тестирование — повторное профилирование, сравнение с baseline, корректировка.
5. Деплой и поддержка — внедрение изменений, консультации.

Что входит в работу по оптимизации AR-приложения

• Аудит производительности на целевых устройствах.
• Оптимизация конфигурации сессии (отключение ненужных фич, настройка параметров).
• Оптимизация рендеринга (переход на Metal/Filament, LOD, culling, сжатие текстур).
• Документация с отчётом и рекомендациями.
• Поддержка после внедрения.

Сроки и как начать

• Аудит производительности — 2–3 дня.
• Оптимизация рендеринга и конфигурации сессии — 1–2 недели.
• Если нужна оптимизация 3D-моделей — дополнительно, зависит от количества ассетов.

Стоимость оптимизации рассчитывается индивидуально, экономия бюджета может достигать 30%. Получите консультацию по оптимизации вашего AR-приложения — свяжитесь с нами для бесплатной оценки проекта. Закажите аудит производительности AR-приложения уже сегодня.

Согласно документации Apple: ARKit Best Practices

Оптимизация мобильных приложений: cold start, память, батарея, FPS, профилирование

Приложение с временем холодного старта 4+ секунды теряет пользователей ещё до первого экрана. Android Vitals в Google Play Console прямо влияют на ранжирование в поиске: приложения с плохими метриками получают меньший organic reach. Apple аналогично мониторит crash rate и время запуска через MetricKit. Оптимизация — это не «сделать быстрее», а понять где именно теряется время и что с этим делать.

Cold Start: где убивается время до первого кадра

Cold start — запуск приложения, когда процесс не существует в памяти. На Android это время от нажатия на иконку до Activity.onWindowFocusChanged(hasFocus = true). На iOS — от tap до viewDidAppear первого экрана.

Android: main thread перегружен при инициализации

Application.onCreate() — главный враг быстрого старта на Android. Разработчики инициализируют здесь всё подряд: Firebase, Analytics, базу данных, HTTP-клиент, DI-контейнер. Каждый SDK добавляет 20–200 мс на main thread.

Инструмент для диагностики: Android Studio Profiler → App Startup. Показывает граф инициализации с временем каждого компонента. Альтернатива — Tracing.beginSection("MyInitTag") в коде + systrace.

Решение: App Startup Library (Jetpack) с явным графом зависимостей инициализаторов. Компоненты, нужные только в конкретных сценариях, инициализируются лениво — by lazy {} или initializer с флагом lazyInit. Firebase Analytics, например, не нужен до первого пользовательского действия — его инициализацию можно отложить.

ContentProvider-ы, автоматически добавляемые SDK через AndroidManifest merge, тоже запускаются при старте. tools:node="remove" в манифесте позволяет отключить конкретный провайдер и инициализировать SDK вручную в нужный момент.

Ещё одна грабля: Room.databaseBuilder().build() на main thread. Это синхронная операция создания/открытия файла БД — на медленных устройствах занимает 50–300 мс. Переносим в coroutine с Dispatchers.IO, в ViewModel через viewModelScope.launch.

iOS: Dyld linking и +load

На iOS cold start делится на pre-main (до вызова main()) и post-main. Pre-main — время загрузки dylib, rebase/binding, Objective-C runtime initialization и выполнения +load методов.

Xcode Instruments → App Launch template показывает время pre-main и post-main раздельно. DYLD_PRINT_STATISTICS=1 в схеме запуска выводит детальное время загрузки в консоль.

Что убивает pre-main:

• Много динамических библиотек (каждая dylib — накладные расходы на линковку). CocoaPods добавляет отдельную dylib на каждый pod. Решение: Swift Package Manager со статической линковкой (type: .static) или use_frameworks! :linkage => :static в CocoaPods.
• +load методы в Objective-C — выполняются синхронно при загрузке класса, до main(). Сторонние SDK могут злоупотреблять этим. +initialize — ленивый аналог, вызывается при первом обращении к классу.

Post-main — application(_:didFinishLaunchingWithOptions:). Та же история что на Android: синхронная инициализация всего. lazy var для сервисов, которые не нужны немедленно. SwiftUI @StateObject инициализирует объект только когда View появляется — это уже встроенная ленивость.

Целевые метрики (App Store рекомендации): cold start < 400 мс для простых приложений, < 2 секунды для сложных. Warm start (процесс в памяти, но Activity/Scene пересоздаётся) — < 1 секунда.

Память: утечки, OOM, excessive pressure

Утечка памяти в iOS — retention cycle: объект A держит ссылку на B, B держит на A, ни один не освобождается. Классика: Timer с self в замыкании без [weak self]. Timer удерживает замыкание, замыкание удерживает self (ViewController), ViewController не освобождается при закрытии. Instruments → Leaks или Memory Graph Debugger в Xcode — находит живые объекты, которых не должно быть.

На Android garbage collector управляет памятью, но утечки всё равно случаются. Activity или Fragment, удерживаемые через статическую ссылку, singleton, или Handler/Runnable после onDestroy — классика. LeakCanary — обязательный инструмент в debug-сборке. Добавляется одной зависимостью debugImplementation "com.squareup.leakcanary:leakcanary-android" и автоматически детектирует утечки с полным стектрейсом.

OutOfMemoryError чаще всего происходит из-за загрузки изображений. Bitmap в памяти занимает ширина × высота × 4 байта. Изображение 4000×3000 px — 48 МБ в памяти, независимо от размера файла на диске. Glide / Coil правильно обрабатывают это: загружают с даунсемплингом под размер View, кешируют в LRU-кеш. Загружать в ImageView без Glide/Coil через BitmapFactory.decodeFile — путь к OOM на устройствах с 2 ГБ RAM.

На Flutter Dart VM имеет свой GC, но нативные ресурсы (изображения, текстуры) не управляются Dart GC. Image.network кеширует изображения в памяти без автоматического освобождения при выходе из дерева виджетов — при длинных списках с картинками используем cached_network_image с правильным memCacheWidth/memCacheHeight.

FPS и UI Performance

60 FPS — 16.67 мс на кадр. 120 FPS (ProMotion) — 8.33 мс. Всё что занимает больше на main thread — джанк.

Типичные причины просадок FPS:

На iOS: синхронная декодировка изображений в cellForRowAt. Когда ячейка таблицы появляется, UIImage(contentsOfFile:) декодирует JPEG/PNG на main thread — видно как заторможенный скролл на длинных списках. Решение: UIImage.preparingForDisplay() (iOS 15+) или ImageIO с kCGImageSourceCreateThumbnailWithTransform в background queue, результат через DispatchQueue.main.async.

На Android: RecyclerView.Adapter.onBindViewHolder с синхронными операциями. Базы данных, файловая система, синхронные сетевые запросы на main thread — StrictMode.ThreadPolicy с detectAll().penaltyLog() в debug-сборке покажет все нарушения.

На Flutter: build() метод вызывается часто, он должен быть дешёвым. setState() на верхнем виджете пересобирует всё дерево. const конструкторы, RepaintBoundary, разбиение на мелкие виджеты с локальным стейтом — основные инструменты. Flutter DevTools → Performance показывает janky frames (красные) с причинами.

Профилирование Compose: Recomposition Highlighter и трассировка через Trace.beginSection в @Composable. remember для дорогих вычислений, derivedStateOf для computed values, LazyColumn вместо Column + forEach для длинных списков.

Батарея: Wake locks, WorkManager, сетевые запросы

Приложение в топе по расходу батареи — пользователь видит это в настройках и удаляет. Android Battery Historian (из ADB bug report) показывает детальный timeline: wake locks, wakeups, network activity, sensor usage.

Основные потребители энергии:

• Постоянный GPS (разбираем в maps-geo)
• Polling сети каждые N секунд вместо push
• Holding wake lock дольше необходимого
• Excessive AlarmManager wakeups

WorkManager с Constraints — правильный способ планировать фоновые задачи: setRequiredNetworkType, setRequiresBatteryNotLow, setRequiresCharging. ОС батчирует задачи и выполняет в удобное время.

На iOS BGTaskScheduler с BGProcessingTaskRequest (для тяжёлых задач при зарядке) и BGAppRefreshTaskRequest (для лёгких обновлений) — система решает когда выполнять, разработчик только регистрирует и реализует логику.

Батчинг сетевых запросов: вместо 10 отдельных запросов в течение минуты — один батч запрос. Меньше радио-активностей (LTE radio потребляет много при инициализации соединения), меньше wakeups.

Инструменты профилирования

MetricKit на iOS — особенно ценен: реальные данные с устройств пользователей, а не симулятора. MXMetricManager получает агрегированные метрики раз в сутки: MXAppLaunchMetric, MXHangDiagnostic, MXCPUExceptionDiagnostic. Диагностики по hang и CPU-exceptions содержат стектрейс с реального устройства — золото для диагностики production-проблем.

Процесс оптимизации

Начинаем с измерения, не с предположений. Инструменты выше дают цифры: конкретное время cold start, конкретный объём памяти, конкретные кадры с просадкой. Потом — приоритизация по impact: что больше всего влияет на пользовательский опыт именно в этом приложении.

Аудит производительности существующего приложения: 3–5 рабочих дней. Реализация оптимизаций — от недели до двух месяцев в зависимости от запущенности проблем и архитектуры кода.