Как добиться стабильных 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 цикл:
| Свойство | Где рисуется | Dropped frames |
|---|---|---|
transform, opacity |
GPU Compositor | Нет |
backgroundColor |
GPU (CALayer) | Редко |
bounds, frame |
CPU → GPU | Часто |
cornerRadius + masksToBounds |
CPU (offscreen) | Часто |
shadowPath (статичный) |
GPU | Нет |
shadowRadius (динамич.) |
CPU | Очень часто |
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.
Подробнее о работе с Lottie
Для уменьшения нагрузки рекомендуем заменять сложные маски на простые формы или использовать векторную графику.Compose: рекомендации
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 стабильно. Мы гарантируем аналогичный результат при работе с вашим проектом.
Сравнение производительности: UIKit vs Compose
| Технология | Типичная просадка FPS | Main thread нагрузка | Рекомендация |
|---|---|---|---|
| UIKit с transform/opacity | 0–2% | Низкая | Анимировать только эти свойства |
| UIKit с bounds/корнером | 10–20% | Высокая | Заменить на GPU-слои |
| Compose с graphicsLayer | 0–5% | Низкая | Использовать graphicsLayer |
| Compose с mutableStateOf | 5–15% | Средняя | Использовать Animatable |
Процесс оптимизации
- Профилирование в Instruments / Android Profiler на реальных устройствах (минимум один медленный девайс из целевой аудитории).
- Идентификация offscreen rendering, expensive draw calls, CPU-анимаций.
- Поочерёдное устранение с замером после каждого изменения.
- Регрессионный тест на устройствах разного класса.
Что входит в работу
- Детальный аудит текущих анимаций с отчётом.
- Исправление проблемных мест (замена свойств, оптимизация слоёв).
- Повторный замер FPS на контрольных устройствах.
- Рекомендации по дальнейшему развитию.
Мы занимаемся мобильной разработкой более 7 лет и оптимизировали анимации в 20+ проектах. Наши специалисты сертифицированы Apple и Google. Apple Core Animation Programming Guide и Android Profiler — наши основные инструменты.
Свяжитесь с нами, чтобы заказать аудит или оптимизацию вашего приложения. Получите консультацию по конкретным проблемам — оценим проект за один день.