Анимации из Figma в Lottie для мобильных приложений

Почему экспорт анимаций Figma ломается на сборке приложения

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

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

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

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

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

Что меняется, когда анимация передана корректно

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

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

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

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

Форматы и способы доставки анимации в приложение

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

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

Как проходит подготовка анимации к выпуску

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

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

Что передаём вместе с экспортом анимаций

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

• Исходники анимации — рабочий файл со всей иерархией слоёв, состояниями и вариантами, без правок «поверх» и потерянных связей между элементами.
• Готовые файлы анимации — экспорт в Lottie, оптимизированный по весу и числу ключевых кадров, с проверкой воспроизведения на обеих платформах.
• Схема слоёв — карта соответствия: какой слой к какому элементу интерфейса привязан и что изменится, если его отключить.
• Правила именования слоёв — единый словарь префиксов и суффиксов, по которому автоматика собирает анимацию и не путает состояния.
• Документация по анимации — триггеры запуска, длительность, повторы, поведение при прерывании и на слабом устройстве.
• Регламент обновления — как вносится правка, кто согласует, как фиксируется версия и что попадает в следующий экспорт.
• Чек-лист приёмки — пункты, по которым вы принимаете работу и проверяете новую анимацию перед выпуском.

Отдельно проговариваем, что считаем правкой внутри анимации, а что — новой анимацией. Это снимает спорные ситуации, когда после выпуска меняется структура, а не только цвет или тайминг.

Кейс: убрали рывки и рассинхрон анимации экранов

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

Что изменили

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

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

• дефекты анимации за релиз: 38 → 4, и все четыре — разные модели устройств, а не повтор одного сбоя;
• время на правку движения: два дня на пересборку и проверку → менее часа;
• доля обращений в поддержку с формулировкой «дёргается интерфейс»: сократилась в пять раз;
• устранение рывков закрепилось в проверках перед выпуском, а не в ручном просмотре.

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

Векторная анимация или покадровая: что выбрать

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

Экспорт векторной анимации из Figma в Lottie даёт компактный файл, который проигрывается нативно и правится дизайнером без пересборки приложения. Покадровая выручает там, где нужна богатая картинка: частицы, дым, сложные текстуры.

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

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

Частые технические вопросы по анимации в приложении

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

Каждый ответ ниже в работе превращается в проверяемый критерий приёмки.

Насколько тяжёлым получится файл анимации?

Вес файла анимации растёт от числа ключевых кадров, вложенных групп и растровой графики внутри векторов. Упрощаем кривые, чистим пустые слои, разбиваем длинную сцену на фрагменты — картинка та же, файл заметно легче.

Что с поддержкой анимации после выпуска?

Ресурсы хранятся отдельно и с понятными именами, поэтому правку вносит любой инженер команды, а не только автор сцены. К каждому набору прикладываем описание структуры и правила правки.

Как обновление анимации попадает в приложение?

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

Почему на разных устройствах анимация выглядит по-разному?

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

Обсудим анимацию вашего приложения

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

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

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

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