Создание Lottie-анимаций для экранов мобильного приложения

Lottie анимация: почему интерфейс тормозит и как это чинится

Lottie анимация выглядит безобидно: дизайнер отдаёт JSON-файл, разработчик подключает его к экрану — и вот уже кнопка мягко пульсирует, а онбординг оживает. Проблема проявляется позже, когда таких файлов на одном экране пять, каждый со своей временной шкалой, а приложение внезапно начинает ронять кадры на средних устройствах. Анимация интерфейса приложения перестаёт быть украшением и становится узким местом: пользователь видит рывки при скролле, а в логах растёт потребление памяти.

Причина в том, как Lottie-плеер работает с содержимым файла. Каждый слой — это отдельный объект со своими трансформациями, масками и эффектами; сложные маски и размытия заставляют перерисовывать область заново на каждом кадре. Если векторная сцена содержит сотни путей, а рендеринг идёт в реальном времени, нагрузка ложится на главный поток — и плавность экранов держится только на мощном железе. На слабых устройствах это выливается в просадки частоты обновления и заметные задержки отклика.

Вторая скрытая статья расходов — вес и количество ассетов. Один тяжёлый JSON на экране ещё терпим, но когда анимации подгружаются заранее и остаются в памяти, приложение незаметно съедает ресурс, который нужен спискам и изображениям. Оптимизация анимаций начинается не с кода, а с аудита: сколько сцен реально нужно, какие слои можно упростить, где достаточно статичного состояния.

Производительность мобильного приложения здесь упирается в три вещи — сложность сцены, момент её запуска и способ рендеринга. Убрать лишние маски, разбить длинную анимацию на короткие фрагменты, запускать её только при видимости экрана и кэшировать результат — это не косметика, а работа с узким местом, которое напрямую влияет на удержание. Разбираем, как это закрывается на практике.

Что даёт выверенная Lottie анимация: эффект в цифрах

Lottie анимация — это векторный формат, который проигрывается нативно на устройстве, а не как видеопоток. Ключевая разница с GIF и последовательностью PNG: вместо сотен растровых кадров в сборку попадает один компактный JSON-файл с кривыми и таймингами. Именно поэтому корректно собранная анимация даёт измеримый эффект: время отрисовки кадра падает, потребление памяти на экране снижается, а доля отказов на слабых устройствах уходит вниз.

Что именно измеряем

• Время отрисовки кадра. Векторные слои пересчитываются на GPU, тяжёлые растровые подстановки не блокируют главный поток — интерфейс остаётся отзывчивым даже при скролле.
• Потребление памяти. Один JSON вместо набора кадров сокращает вес экрана в разы: анимация не держит в памяти десятки растровых слоёв одновременно.
• Доля отказов на слабых устройствах. Без видеопотока и лишних декодеров анимация не «съедает» кадры на бюджетных моделях — сценарий отрабатывает предсказуемо.
• Оптимизация отрисовки. Маски, градиенты и вложенные композиции пересобираются в плоскую структуру, чтобы не плодить лишние слои при рендере.

Сравнение форматов анимации

Выбор формата — это компромисс между весом, плавностью и сложностью сцены. Для интерфейсных анимаций вектор почти всегда выигрывает: он масштабируется под любую плотность экрана без потери качества и не тянет за собой видеоплеер.

Lottie от Airbnb задаёт стандарт обмена векторной анимацией между дизайном и разработкой — файл собирается один раз и одинаково проигрывается на обеих платформах. Мы закладываем в сборку проверку веса, числа слоёв и профиль отрисовки, чтобы эффект от анимаций был реальным, а не декларативным.

Как мы внедряем анимации: этапы инженерной работы

Внедрение анимаций начинается не с отрисовки, а с аудита интерфейса: инженеры проходят по экранам, замеряют время отклика, находят места, где интерфейс «молчит» — переход между состояниями, загрузка данных, подтверждение действия. На этом этапе фиксируем, какие сценарии действительно выигрывают от движения, а какие остаются статичными: анимация ради анимации съедает бюджет кадров и мешает работе.

Дальше — проектирование и сборка. Каждый переход получает тайминг, кривую ускорения и точку выхода, чтобы движение совпадало с логикой экрана, а не жило отдельно от неё. Готовые сцены собираются в Lottie-анимацию и проверяются на реальных устройствах: вес файла, плавность на слабом железе, поведение при прерывании жестом.

1. Аудит интерфейса. Проходим по экранам, замеряем отклик, составляем карту мест, где нужна анимация, и отсекаем лишнее.
2. Согласование сценариев. Фиксируем, что именно анимируем, как долго и что происходит при повторном нажатии или уходе с экрана.
3. Прототип движения. Собираем черновую Lottie-анимацию на ключевых переходах, показываем на устройстве до финальной отрисовки.
4. Продакшн-сборка. Отрисовываем сцены, оптимизируем контуры и слои, убираем всё, что не влияет на картинку, но тянет вес.
5. Проверка на устройствах. Прогоняем на слабых и сильных моделях, смотрим плавность и потребление памяти при долгом использовании.
6. Интеграция в приложение. Подключаем анимации к экранам, следим, чтобы они не блокировали интерфейс и корректно останавливались.
7. Передача анимаций и документации. Отдаём исходники, готовые файлы, правила таймингов и инструкцию, как вносить правки без нас.

Такой инженерный процесс даёт предсказуемый результат: анимации не раздувают сборку, не тормозят на слабых устройствах и остаются управляемыми после сдачи. Опишите задачу — вернёмся с оценкой и планом по этапам.

Чем отличается Lottie от покадровой и нативной анимации?

Lottie анимация — это векторная анимация, которая описывается не набором картинок, а математической моделью: координаты, кривые, ключевые кадры и тайминги. Файл хранит инструкции «что и как движется», а отрисовку на устройстве выполняет рантайм-библиотека. Отсюда главное отличие от покадровой анимации: вместо десятков растровых кадров на каждый переход в приложение попадает один компактный файл, который масштабируется под любой экран без потери резкости.

Покадровая анимация — это последовательность готовых изображений, проигрываемых как слайды. Она даёт полный контроль над картинкой: можно нарисовать сложные текстуры, шум, свет, эффекты, которые вектор просто не воспроизведёт. Но плата — вес и память: длинная сцена превращается в сотни кадров, каждый занимает место в сборке и в оперативной памяти при проигрывании. На слабых устройствах это заметно по просадкам при прокрутке и по расходу батареи.

Нативная анимация собирается средствами самой платформы — слоями, трансформациями, переходами между состояниями экрана. Она идеальна для интерфейсных движений: появление кнопки, смена вкладки, отклик на нажатие. Здесь минимальный вес и максимальная отзывчивость, потому что всё делает система. Ограничение — выразительность: сложную иллюстративную сцену с десятками независимых объектов нативной анимацией собирать долго и дорого в поддержке.

Выбор формата — это компромисс между выразительностью, весом и сложностью правок. Lottie выигрывает там, где нужна детальная векторная сцена, единый файл для двух платформ и быстрая правка без пересборки приложения: дизайнер меняет файл, и обновление прилетает без релиза. Покадровая берёт верх на коротких зацикленных роликах с фотореалистичной графикой, где вектор бессилен. Нативная — на всём, что относится к поведению интерфейса, а не к иллюстрации.

По памяти и сложности Lottie проигрывает, когда сцена перегружена: сотни слоёв, тяжёлые маски, размытия и градиенты заставляют рантайм пересчитывать геометрию на каждом кадре, и на бюджетных устройствах это даёт просадки. Здесь помогает упрощение сцены, разбивка на несколько файлов и предзагрузка. Мы на старте оцениваем каждую анимацию по этим параметрам и предлагаем формат под конкретный экран, а не по умолчанию.

Кейс: как мы убрали дёрганье экранов в приложении доставки

Экран оформления заказа в приложении доставки дёргался при скролле: кадр собирался дольше, чем устройство успевало его показать, и на слабых моделях анимация рассыпалась на рывки. Проблема была не в вёрстке, а в том, что тяжёлые векторные слои пересобирались на каждом кадре вместо того, чтобы проигрываться как готовая последовательность. Замеры до правок: отрисовка кадра выходила за бюджет в 16 мс, пиковое потребление памяти на экране держалось около 180 МБ, а доля отказов при открытии корзины на устройствах начального уровня доходила до 7%.

Что именно поменяли

Мы вынесли анимацию корзины и статусов доставки в Lottie анимацию — заранее просчитанную векторную последовательность, которую проигрывает нативный рендерер без пересборки слоёв на каждом кадре. Тяжёлые растровые спрайты и цепочки вложенных слоёв заменили на один компактный файл, а сам проигрыватель инициализируется один раз при входе на экран и переиспользуется между переходами. Отдельно ограничили число одновременно активных анимаций: пока одна проигрывается, остальные ставятся на паузу, чтобы не конкурировать за поток отрисовки.

Метрики до и после

Скролл перестал дёргаться, а экран корзины открывается предсказуемо даже на бюджетных моделях. Мы работаем на Lottie — формате, который одинаково проигрывается на обеих платформах без отдельной сборки под каждую, поэтому правки анимации не требуют пересборки нативных модулей.

Результат внедрения

Плавность интерфейса перестала зависеть от класса устройства: то, что раньше «сыпалось» на слабых моделях, теперь работает одинаково ровно. Оптимизация приложения дала побочный эффект — экран стал быстрее открываться и меньше нагружать батарею, потому что рендерер не пересчитывает слои на каждом кадре. Дальше этот же подход мы перенесли на экраны отслеживания заказа и онбординга.

Сомнения по совместимости, откату и доступам — разбираем

Lottie анимация — это не отдельный артефакт «в вакууме», а файл, который должен корректно проигрываться на конкретных версиях iOS и Android, в конкретной библиотеке рантайма и в конкретном состоянии экрана. Поэтому главный технический вопрос не «красиво ли выглядит», а «что будет, когда анимация встретится с вашим текущим стеком». Ниже — разбор типовых сомнений, которые возникают до старта.

Что если у нас другая версия рантайма? Мы собираем анимацию под ту ветку библиотеки, которая уже стоит в проекте, а не под последнюю. Если версия старая — либо адаптируем векторные слои под поддерживаемый набор свойств, либо предлагаем точечное обновление рантайма с проверкой на регрессии. Совместимость анимаций проверяется на реальных устройствах из вашей матрицы, а не только в редакторе.

Что если после релиза нужно откатить? Каждая анимация версионируется отдельным файлом, поэтому откат изменений — это замена одного артефакта на предыдущий, без пересборки логики экрана. Мы фиксируем, какая версия ушла в какой релиз, чтобы возврат занимал минуты, а не часы поисков.

Что если мы захотим менять анимации сами? Передача документации включает структуру слоёв, названия групп и правила экспорта — дизайнер или разработчик с базовым опытом внесёт правку, не ломая рантайм. Технические сомнения по миграции на другой движок тоже закрываем заранее: описываем, какие свойства не переносятся один в один.

Что заказчик получает на руки:

• исходные файлы анимаций в редактируемом формате;
• экспортированные файлы под iOS и Android с проверкой на устройствах;
• карту версий: какой файл в каком релизе;
• инструкцию по экспорту и замене анимации;
• список поддерживаемых свойств и ограничений рантайма;
• чеклист проверки перед релизом.

Опишите вашу текущую версию рантайма и матрицу устройств — вернёмся с оценкой и планом работ по анимациям.