Оптимизация анимаций для достижения 60 FPS в мобильном приложении

Оптимизация анимаций для достижения 60 FPS в мобильном приложении

60 FPS — это 16.67 мс на кадр. Если хоть один кадр займёт 17+ мс, Instruments покажет dropped frame. На 120 Гц-дисплеях (ProMotion) порог ещё жёстче: 8.3 мс. Пользователи iPhone 13 Pro и Pixel 8 это физически чувствуют.

Где теряются кадры: диагностика первым делом

Прежде чем что-то оптимизировать — открываем Xcode Instruments с шаблоном Core Animation. Запускаем на реальном устройстве (симулятор не считается: у него другой GPU). Смотрим на два графика: FPS и CPU Usage. Красные столбцы на FPS-графике — dropped frames.

На Android — Android Profiler в режиме GPU/CPU + Systrace для детального трейса. В Developer Options включаем Profile GPU Rendering (отображает столбцы на экране): если оранжевая зона (Draw) и красная (Sync/Upload) регулярно превышают 16ms-линию — есть проблема.

Типичная находка: анимация тени (shadowRadius, shadowOffset на CALayer) пересчитывает Gaussian blur на CPU каждый кадр. На iPhone SE 2nd gen это может давать 8–10 ms только на тень.

Главный принцип: GPU-слои против CPU-рендера

Анимировать только transform и opacity — это не рекомендация, это закон производительности. Эти свойства обрабатываются Compositor thread напрямую, без involvement main thread и без вызова drawRect:.

Всё остальное запускает Layout → Display → Prepare → Commit цикл:

cornerRadius с masksToBounds = true — offscreen rendering. На каждый такой слой Core Animation делает дополнительный render pass. В Instruments: Debug → Color Offscreen-Rendered окрашивает их жёлтым. Исправление: задать layer.shadowPath статично или использовать маску из векторного изображения.

UIKit: конкретные приёмы

shouldRasterize — осторожно

layer.shouldRasterize = true кэширует слой как bitmap. Помогает если содержимое не меняется. Убивает, если меняется: кэш инвалидируется каждый кадр и перерисовывается дороже, чем без него. Проверяем через Instruments → Color Hits Green and Misses Red: красное = инвалидация, помощи нет.

drawRect vs CALayer

Переопределение drawRect: — ядерный вариант. Если вызов происходит во время анимации (например, меняется bounds), main thread занят рисованием. Альтернатива: выносить статичный контент в отдельный CALayer с contents = image.cgImage, анимировать только transform.

CADisplayLink для кастомных анимаций

Если пишем кастомную анимацию на CADisplayLink — привязываемся к preferredFramesPerSecond:

let displayLink = CADisplayLink(target: self, selector: #selector(tick))
displayLink.preferredFrameRateRange = CAFrameRateRange(
    minimum: 60,
    maximum: 120,
    preferred: 120
)
displayLink.add(to: .main, forMode: .common)

На ProMotion устройствах это позволяет анимации работать на 120 FPS. Без указания range система может зафиксировать 60 даже на 120 Гц дисплее.

Lottie: частые проблемы с производительностью

Lottie по умолчанию использует .automatic render mode. На сложных анимациях с масками и trim paths это часто означает CPU-рендер. Принудительно переключаем:

animationView.renderingEngine = .coreAnimation

Core Animation engine (.coreAnimation) рендерит через CALayers — без main thread participation. Ограничение: не поддерживает некоторые сложные эффекты (gradients через trim paths, некоторые blending modes). Проверяем в Lottie Diagnostics.

Compose: реkomендации

Modifier.graphicsLayer вместо прямого изменения layout-параметров:

// Плохо: вызывает relayout на каждый кадр
Box(modifier = Modifier.size(animatedSize))

// Хорошо: только GPU transform, layout стабилен
Box(modifier = Modifier
    .size(100.dp)
    .graphicsLayer { scaleX = animatedScale; scaleY = animatedScale }
)

graphicsLayer работает аналогично layer.transform в UIKit — вне layout pass.

Избегать remember { mutableStateOf() } внутри анимационного лямбда. Каждое обновление состояния через mutableStateOf вызывает recomposition. Используем Animatable напрямую, или animateFloatAsState который обновляет только graphicsLayer без recompose экрана.

Типичные кейсы оптимизации

В приложении одного клиента список с кастомными ячейками падал до 40 FPS при скролле. Причина: каждая ячейка имела layer.cornerRadius = 12 с masksToBounds = true и layer.shadowRadius = 8. Двойной offscreen render pass на каждую ячейку. Решение: corner radius через UIBezierPath маску (один GPU pass), тень через shadowPath с заранее рассчитанным CGPath. FPS вернулся на 60 стабильно.

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

Профилирование в Instruments / Android Profiler на реальных устройствах (минимум один медленный девайс из целевой аудитории). Идентификация offscreen rendering, expensive draw calls, CPU-анимаций. Поочерёдное устранение с замером после каждого изменения. Регрессионный тест на устройствах разного класса.

Ориентиры по срокам

Аудит и исправление анимаций в существующем приложении — 2–5 дней в зависимости от масштаба и числа проблемных мест.