Почему анимации Lottie проседают на части устройств
Анимации Lottie — это векторный JSON, который приложение разбирает и растеризует на самом устройстве в момент показа. На флагманах это незаметно, а на слабых устройствах разбор файла, маски, градиенты и слои с прозрачностью ложатся на главный поток отрисовки. Интерфейс начинает дёргаться ровно там, где пользователь ждёт мгновенной реакции.
Сверху добавляется порядок загрузки: подгрузка векторных эффектов идёт синхронно с первым показом экрана, и анимация «догоняет» уже отрисованный интерфейс. Переход между экранами раскрывается с задержкой, часть устройств просто пропускает кадры, а Hero-переходы и пружинные анимации поверх умножают нагрузку на тот же поток.
Отдельная причина — кэш готовых кадров: на устройствах с малым объёмом памяти он вытесняется, и один и тот же эффект пересобирается заново при каждом возврате на экран. Внешне это выглядит как «дёргается только иногда», поэтому проблему долго списывают на сеть.
Цена проявляется в ключевых сценариях — онбординг, добавление товара, подтверждение оплаты. Рваный переход читается как «приложение тормозит», и пользователь уходит, хотя логика отработала корректно. Такие просадки плохо ловятся на тестовом парке: на стенде гладко, на живых устройствах — стабильно.
Ниже разбираем, как это закрывается: где анимацию готовят заранее, где меняют формат, а где уводят отрисовку с главного потока — чтобы плавность интерфейса перестала зависеть от модели устройства.
Единая система движения интерфейса: что она даёт приложению
Система движения интерфейса — это не набор эффектов под каждый экран, а библиотека повторно используемых переходов: тайминги, кривые ускорения, поведение при прерывании жестом описаны один раз и переиспользуются везде. Новый экран собирается из готовых блоков, а не отрисовывается заново, поэтому срок его выпуска сокращается с дней до часов.
Скорость выпуска экранов растёт и за счёт снятого согласования: дизайнер и разработчик больше не обсуждают длительность и характер каждой анимации, а берут подходящий переход и подставляют контент. Векторная отрисовка Lottie даёт одинаковую картинку на обеих платформах — один и тот же эффект не приходится описывать и поддерживать дважды.
Отдельный результат — устранённый класс дефектов: «дёргается при быстром жесте», «прыгает после поворота экрана», «залипает на слабом устройстве». Переходы, прерываемые в любой момент и считающие положение от текущего состояния, убирают рывки, а доля устройств с ровной отрисовкой измеряется отдельно на слабом сегменте — по ней и видно, что регресс не вернулся.
Повторно используемые эффекты сокращают и число повторных правок: правка тайминга или кривой в одном месте применяется ко всем экранам сразу, а не вносится вручную на каждом. Постепенно набор переходов превращается в формализованный язык движения, по которому новые экраны собирают без участия автора библиотеки.
Анимации Lottie и Rive: какой формат под какую задачу
Формат движения выбирают по тому, кто управляет состоянием анимации — заранее отрисованный таймлайн или код приложения. Lottie хранит векторную сцену как набор слоёв и ключевых кадров: плеер воспроизводит её от начала до конца с фиксированной длительностью. Rive описывает граф состояний, где переход задаёт не время, а входной параметр — нажатие, прогресс, значение переключателя.
Физические переходы пружинами и жестовые сценарии файлом не хранятся вовсе: их считает само приложение, привязывая движение к скорости пальца и инерции. Отсюда и разница в задачах — вектор отвечает за декор и сюжет, физика за отклик интерфейса.
| Формат | Когда подходит | Ограничения |
|---|---|---|
| Векторный (Lottie) | Иконки, онбординг, иллюстрации, эффекты успеха и ошибки — линейный сценарий с известной длительностью | Слабо реагирует на ввод в реальном времени: смена состояния — это подмена файла или сегмента, а не непрерывная реакция |
| Интерактивный (Rive) | Интерактивные элементы: переключатели, персонажи, блоки с ветвлением по состоянию | Дороже в производстве — нужен дизайнер, собирающий граф состояний, а не рисующий таймлайн |
| Физические переходы | Навигация между экранами, появление модальных окон, отклик на нажатие | Параметры подбирает инженер, а не дизайнер; без сглаживания дёргаются на слабых устройствах |
| Жестовые сценарии | Свайпы, перетаскивание карточек, обновление списка, отмена действия | Тяжело синхронизировать и откатывать: движение должно следовать за пальцем, а не за таймлайном |
На практике форматы не конкурируют в одном экране: векторный слой закрывает декор, физика — навигацию, интерактивный формат — элементы, которыми управляет пользователь. Общее ограничение одно — чем больше слоёв анимируется одновременно, тем заметнее просадка на слабом устройстве.
Этапы внедрения: от аудита текущих эффектов до передачи
Анимация ломается не в макете, а во внедрении: эффект рисуется в основном цикле отрисовки, тянет за собой лишние слои и на слабом устройстве превращается в рывок. Поэтому движение интерфейса ведём этапами — каждый опирается на артефакт предыдущего, и на выходе остаётся управляемая система, а не набор разрозненных эффектов.
- Аудит движения интерфейса. Проходим по экранам и фиксируем каждый переход, появление списка, отклик на нажатие: чем отрисовано, где дублируется, какие экраны открываются дольше остальных.
- Схема эффектов. Сводим в таблицу экран, событие-триггер, длительность, кривую и способ отрисовки — векторная анимация Lottie, покадровая или нативная пружина. Схема становится словарём: одинаковые по смыслу действия выглядят одинаково во всём приложении.
- Оптимизация отрисовки. Статичные части выносим в кэш, тяжёлые сцены разбиваем на независимые дорожки, декоративные слои убираем из основного цикла. Эффект перестаёт влиять на плавность прокрутки.
- Проверка на устройствах. Прогоняем на слабых моделях, в тёмной теме, при энергосбережении и системном «уменьшить движение»: анимация должна не пропадать, а заменяться коротким безопасным вариантом.
- Замеры и регресс. Сравниваем время открытия экранов и число пропущенных кадров до и после; набор проверок остаётся у команды, чтобы новые эффекты тестировали по нему же.
- Передача проекта. Отдаём схему, исходники, токены длительностей и кривых, конфигурацию сборки ресурсов и инструкцию «как добавить эффект, не сломав остальные». После разбора с командой заказчика поддержку можно вести своими силами.
Комплект после сдачи: исходники, схемы, регламенты
После сдачи у заказчика остаётся не только собранное приложение, но и комплект, по которому его можно развивать без нас: ниже — что именно входит в передачу и как это проверяется на приёмке.
- Исходники эффектов. Рабочие проекты векторных анимаций Lottie, а не только выгруженные из них файлы: именованные слои, тайминги, кривые движения и пометки, где эффект завязан на данные из приложения.
- Библиотека переходов. Повторно используемые переходы между экранами и состояниями — появление, возврат, модальные окна, реакция на свайп — собранные так, что новый экран подключает готовый переход, а не рисует свой.
- Схема связей экранов. Карта, где видно, какой переход ведёт из какого экрана в какой, чем отличаются состояния и что происходит при прерывании жестом.
- Правила внесения правок. Что можно менять в файле анимации без пересборки, где порог, после которого эффект собирается заново, и кто проверяет результат после правки.
- Порядок приёмки. Перечень проверок: поведение на слабых устройствах, реакция на прерывание, системный режим снижения движения, отсутствие рывков при подгрузке данных.
- Регламент производительности. Бюджет на длительность и число одновременных эффектов плюс список мест, где анимация отключается принудительно.
Всё это лежит в хранилище кода рядом с приложением, версионируется вместе с ним и обновляется при каждом релизе. Опишите задачу — вернёмся с оценкой и планом передачи.
Кейс: переписали движение интерфейса и убрали просадки
Проект — приложение сервиса доставки: 40+ экранов, движение интерфейса собрано из растровых раскадровок, у каждой свой тайминг и своя кривая. На слабых устройствах переход между разделами проседал, при скролле длинного списка кадры выпадали, а правка одной анимации тянула за собой повторную выгрузку графики.
Сначала замерили, что именно тормозит: сняли профиль отрисовки на бюджетных моделях и разложили движение по слоям. Затем сцены перевели на векторные форматы — Lottie для интерфейсных состояний и Rive для интерактивных, — а все переходы свели к общему набору кривых ускорения.
| Показатель | До | После |
|---|---|---|
| Сценариев движения | 41 растровый набор | 12 векторных сцен |
| Сборка нового экрана | 3 дня на графику | 4 часа |
| Устройства с ровной отрисовкой | 62% | 97% |
| Вес графики в сборке | 14 МБ | 3,2 МБ |
Что изменили в переходах
Переходы переписали на пружинные кривые и связали парные экраны в непрерывное движение, чтобы оно читалось как один объект, а не как склейка. Анимацию вынесли отдельным слоем поверх разметки, тяжёлые сцены подгружаем заранее по появлению экрана и держим в кэше — подготовка следующей сцены больше не блокирует отрисовку.
Просадки на бюджетных устройствах ушли, новые экраны собираются из готовых сцен, а не с нуля под каждый раздел. Дизайнеры правят сценарий движения сами, без разработчиков, поэтому следующая итерация интерфейса заняла две недели вместо двух месяцев.
Что делать, если готовое приложение уже проседает на части устройств
Да, встроить систему движения в выпущенное приложение реально без переписывания: анимация живёт в отдельном слое интерфейса, поэтому её замена не задевает логику, работу с сетью и хранение данных. Речь идёт о точечной переработке — меняем конкретные экраны, а не приложение целиком.
Начинаем с частых сценариев, которые пользователь проходит на каждом запуске: знакомство с приложением, переходы между разделами, состояния загрузки и ошибок, обновление списка, отклик на нажатие. До правок снимаем замеры на реальных устройствах и находим, где именно теряется плавность: часто достаточно перевести тяжёлые последовательности кадров на векторные анимации Lottie, и просадки уходят без изменения структуры экрана.
Отдельный пункт — обратная совместимость. Старые версии системы и слабые устройства получают упрощённый вариант движения или статичный первый кадр, а новая система подключается только там, где отработает предсказуемо; пользователь не видит разницы, кроме того, что интерфейс перестаёт дёргаться.
Внедряем поэтапно: один релиз — один сценарий, за удалённым переключателем и с мгновенным откатом без выпуска новой сборки. Так просадка на отдельной модели не превращается в откат всего релиза, а эффект от каждой замены виден сразу.
Если готовое приложение проседает лишь на части устройств, полная переработка не нужна — хватает плана из нескольких шагов с понятным порядком и проверкой на каждом.
Технические сомнения по интеграции эффектов и переходов
Сомнения по эффектам обычно не про «красиво или нет», а про срок жизни решения: что будет при замене формата, кто правит анимацию после сдачи, как она ведёт себя на слабом устройстве. Разбираем четыре частых вопроса.
Можно ли заменить один формат эффектов на другой?
Да, если анимация вынесена отдельным слоем, а не вшита в логику экрана. Векторный формат вроде Lottie подменяется файлом: разметка и переходы остаются на месте. Дороже всего замена обходится там, где эффект завязан на разметку — тогда правится и сам экран.
Кто поддерживает анимацию после сдачи?
Отдаём файлы эффектов, схему привязки к экранам и правила запуска. Цвет, скорость и длительность ваша команда меняет без нас; переработка сценария перехода — задача на часы, а не на пересборку приложения.
Как эффекты ведут себя на недорогих устройствах?
Тяжёлые эффекты на слабом устройстве дают просадку плавности и нагрев. Заранее готовим упрощённый вариант и отключаем фоновые слои при низком заряде — интерфейс остаётся отзывчивым, эффект не пропадает.
Что делать, если макет уже нарисован?
Оцениваем его на реализуемость: часть эффектов переносится один в один, часть требует упрощения под реальные ограничения. Трудоёмкость правок зависит от числа уникальных переходов — чем больше экранов рисуют макет заново, тем больше работы.
Обсудим задачу: покажите текущее состояние интерфейса
Чтобы разговор был предметным, нужен не весь проект целиком, а минимальный набор данных о конкретных экранах и анимациях. Мы воспроизводим поведение на устройстве и только после этого даём оценку и план работ — иначе сроки превращаются в догадки.
- Перечень проблемных экранов. Где именно анимация дёргается, проваливается первый кадр, подтормаживает скролл или разваливается на слабом устройстве — названия экранов по макету и в самом приложении.
- Записи поведения приложения. Экранная запись с реального устройства, с указанием модели и версии системы. Если вопрос в векторной анимации, приложите исходный файл, который отрисовывается на этом экране.
- Ссылки на сборку. Доступ к тестовой сборке, тестовый аккаунт и данные, при которых дефект воспроизводится стабильно, — это снимает половину уточнений.
- Макеты и исходники анимаций. Проект в исходном редакторе, разбивка по слоям и указание, что именно должно двигаться, а что остаётся статичным.
- Перечень требований. Платформы, минимальные версии системы, ограничения по весу приложения и расходу батареи, референсы анимаций — и что в них нравится конкретно.
- Требования к срокам. К какой дате нужен релиз, есть ли привязка к внешнему событию, готовы ли принимать промежуточные сборки с частичными изменениями.
На выходе вы получаете оценку и план работ: этапы, что делаем мы, что нужно от вашей команды, и следующий шаг с датой. Опишите задачу — вернёмся с предложением.