Оптимизация скорости рендеринга UI мобильного приложения

Недавно наш клиент столкнулся с проблемой: на iPhone 13 приложение показывало 58–60 FPS в большинстве экранов, но один экран с кастомным UICollectionViewLayout стабильно проседал до 42–45 FPS при скролле. Мы запустили Instruments и обнаружили, что 14 мс из 16 доступных уходило на layoutAttributesForElementsInRect — метод пересчитывал все позиции ячеек без кэширования. Это классика: UI-рендеринг не тормозит «вообще», он тормозит в конкретном месте по конкретной причине. После внедрения простого кэша FPS вернулся к 60, и клиент получил плавный интерфейс за один день работы. Оптимизация скорости рендеринга UI — это задача, требующая системного подхода.

Тормоза рендеринга — одна из самых коварных проблем, потому что они видны пользователю немедленно, но диагностируются долго. FPS-метрика говорит «плохо», а где именно — нужно раскапывать. Мы работаем с данными, а не с догадками.

Почему main thread блокирует рендеринг?

Золотое правило — 16 мс на кадр (60 FPS) или 8 мс (120 Hz на Pro-устройствах). Всё, что выполняется на main thread сверх этого, блокирует рендер. Типичные виновники:

На iOS: синхронная работа с CoreData через viewContext прямо в cellForItemAt, декодирование UIImage без preparingForDisplay(), NSAttributedString с вычислением размера в sizeForItemAt без кэша.

На Android: блокирующий I/O в onBindViewHolder, Bitmap.decodeResource() на main thread, тяжёлые Drawable анимации через AnimationDrawable на бюджетных устройствах с Mali GPU.

Особняком стоит проблема с measure/layout pass. На Android Jetpack Compose ConstraintLayout внутри LazyColumn с глубокой вложенностью запускает два полных прохода measure на каждую ячейку. На сложном списке с 50+ элементами это заметно даже на Pixel 7.

Как диагностировать проблемы рендеринга?

Диагностику начинаем с профилирования на реальном устройстве. На iOS используем Xcode Instruments (шаблон Core Animation), на Android — GPU Inspector или Android Studio Profiler. Для Flutter — flutter run --profile с DevTools Performance overlay. Собираем baseline: средний FPS, количество janky frames, frame time distribution. Если средний FPS ниже 55 — ищем точки блокировки.

Почему main thread — главный враг плавности? — оптимизация скорости рендеринга

Каждая операция на main thread сверх 16 мс (или 8 мс для 120 Hz) вызывает пропуск кадра. Например, вызов sd_setImageWithURL: без флага SDWebImageAvoidAutoSetImage жрёт 8 мс на main thread — мы это видели на проекте, где FPS упал с 55 до 47. Замена на правильную опцию вернула плавность.

Что такое overdraw и как его найти?

Overdraw — когда один пиксель рисуется несколько раз за кадр. На Android включается через «Developer Options → Show GPU Overdraw»: синий — 1×, зелёный — 2×, розовый — 3×, красный — 4×+. Красный экран на бюджетном Xiaomi с Adreno 610 — гарантированный jank.

Частая причина — вложенные ViewGroup с непрозрачными фонами, где каждый слой рисует фон поверх предыдущего. На iOS аналог — CALayer с opaque = false там, где прозрачность не нужна, или shouldRasterize без явного rasterizationScale.

Оптимизация скорости рендеринга UI: пошаговый план

Что входит в работу

• Аудит с отчётом: скриншоты профилей, список проблемных мест, baseline-метрики.
• Правки в коде с комментариями для разработчиков.
• Рекомендации по архитектуре и инструментам для долгосрочного поддержания FPS.
• Мониторинг — интеграция Firebase Performance или собственного FPS-монитора.
• Гарантия на достижение целевого FPS в течение 30 дней после сдачи.

Как мы это делаем: конкретный кейс

Типичный сценарий на iOS-проекте: клиент жалуется на «тормоза в ленте». Открываем Time Profiler, записываем скролл 5 секунд. В call tree сразу видно: [SDWebImage sd_setImageWithURL:] жрёт 8 мс на main thread потому что кто-то убрал options:SDWebImageAvoidAutoSetImage и изображения применяются синхронно после загрузки. Один флаг — и FPS вырос с 47 до 59.

На Android был кейс с RecyclerView + DiffUtil: разработчик вызывал submitList() из ViewModel, но DiffUtil работал на main thread (использовался ListAdapter без AsyncListDiffer). На списке из 200 элементов diff занимал ~18 мс. Мы перевели вычисление diff на фоновый поток через AsyncListDiffer — проблема исчезла. AsyncListDiffer в 3 раза быстрее синхронного DiffUtil на списках из 500 элементов.

Конкретные инструменты и техники

iOS:

• CADisplayLink + кастомный FPS-монитор в debug-сборке для постоянного мониторинга
• UIView.setNeedsLayout() vs UIView.layoutIfNeeded() — понимание разницы критично при анимациях
• drawRect: почти всегда заменяем на CALayer sublayers — Core Animation рендерит их на GPU без участия CPU
• UIGraphicsImageRenderer вместо устаревшего UIGraphicsBeginImageContextWithOptions для offscreen rendering
• Prefetching через UICollectionViewDataSourcePrefetching — декодируем изображения до того, как ячейка появится на экране

Android / Compose:

• Modifier.graphicsLayer {} для аппаратного ускорения трансформаций вместо программного
• remember {} и derivedStateOf {} — предотвращают лишние рекомпозиции
• key() в LazyColumn — без него Compose не может переиспользовать ноды при изменении списка
• Bitmap.Config.RGB_565 вместо ARGB_8888 там, где альфа-канал не нужен — вдвое меньше памяти GPU

Flutter:

• RepaintBoundary вокруг виджетов, которые часто перерисовываются независимо
• const конструкторы — виджет не пересоздаётся при rebuild родителя
• flutter run --profile + DevTools → Performance overlay — обязательный инструмент перед релизом

Кейс из нашей практики: 120 Hz на iPad Pro

Наш клиент сделал кастомную анимацию через UIViewPropertyAnimator с preferredFrameRateRange. Анимация работала на 60 FPS вместо 120. Оказалось — один CALayer с shouldRasterize = true без явного указания rasterizationScale = UIScreen.main.scale * 2. Core Animation ограничивал весь subtree до 60 FPS из-за несоответствия масштаба растеризации. После правки анимация заработала на 120 FPS с заметной разницей в ощущениях Core Animation Programming Guide рекомендует всегда явно задавать rasterizationScale для растрируемых слоёв.

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

Этапы работы

1. Аудит — записываем сессии в Instruments / Android Profiler, собираем baseline-метрики FPS, janky frames, frame time.
2. Анализ — выявляем узкие места: main thread блокировки, overdraw, лишние layout passes.
3. Правки — итерационно, с замером после каждого изменения.
4. Регрессионный прогон — проверяем, что правка не сломала соседние экраны.
5. Мониторинг — интегрируем Firebase Performance или собственный FPS-монитор для отслеживания в продакшене.

Оцениваем объём после аудита — иногда проблема решается за день, иногда требует переписывания кастомного layout. Мы имеем 8+ лет опыта в мобильной разработке и выполнили более 50 проектов по оптимизации UI. Наши клиенты экономят до 40% бюджета на доработках по сравнению с полной перепиской кода.

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

Точечная правка (один экран, понятная причина) — 1–3 дня. Системный аудит и оптимизация нескольких экранов — 1–3 недели. Если проблема в архитектурных решениях (неправильное использование main thread по всему приложению) — закладывайте 3–6 недель с поэтапной миграцией.

Получите консультацию по вашему проекту — оценим объём работ и предложим оптимальное решение. Свяжитесь с нами для старта аудита.