Чому експорт анімацій Figma ламається на збірці застосунку
Макет у редакторі та застосунок живуть за різними правилами: полотно малює те, що бачить дизайнер, а збірка відтворює лише те, що описано в структурі шарів.
Експорт анімацій Figma переносить групи, маски, ефекти й криві руху — і будь-яка розбіжність між задумом і структурою спливає не на прев'ю, а вже на збірці.
Перша причина — розсинхрон шарів. Складені фігури під час вивантаження розбираються на частини, змінюється порядок накладання, вкладені маски втрачають обрізання.
У застосунку елементи рухаються не разом: підкладка відстає, іконка виїжджає за межі кадру, а маска перестає зрізати зайве — анімація ламається на збірці там, де в макеті все було рівно.
Друга — перевантажений вихідний файл. Залишкові растрові вставки, покадрові ефекти, деформації сітки та зайві службові шари перетворюють компактну сцену на важкий файл анімації.
Він довше завантажується під час старту екрана, а на слабкому пристрої відтворення йде ривками — помітно саме там, де рух має бути плавним.
Третя — різниця екранів. Фіксовані координати та прив'язки з фрейму не перераховуються під щільність пікселів і співвідношення сторін: на одному пристрої сцена виглядає як у макеті, на іншому обрізана по краях або розтягнута.
Усі три збої лежать не в дизайні, а в підготовці вихідного файлу та налаштуванні вивантаження. Розбираємо, як це закривається: перевіркою структури до експорту, розумною оптимізацією та прогоном на реальних пристроях.
Що змінюється, коли анімацію передано коректно
Коректно передана анімація — це векторна Lottie зі збереженими ключовими кадрами, кривими прискорення та зрозумілими іменами шарів, а не відеоролик і не набір растрових кадрів.
Такий файл відтворюється нативно на обох платформах, важить у рази менше за послідовність зображень і не втрачає різкості під час масштабування інтерфейсу.
Вставка в інтерфейс займає години замість днів: розробнику не потрібно вручну відновлювати таймінги, підганяти тривалість під код і підбирати криві на око.
Скорочення кількості правок іде звідти ж — зауваження до швидкості, ритму й повторного запуску циклу закриваються на боці анімації, до того як задача потрапить у збірку.
Плавність інтерфейсу тримається на узгодженості кадрів і прискорень, а не на потужності пристрою, тому єдиний результат на платформах однаково відпрацьовує і на слабких смартфонах.
Анімація не смикається під час підвантаження екрана, не «залипає» на першому кадрі й коректно відпрацьовує переривання — якщо користувач пішов з екрана раніше, ніж вона закінчилася.
Окремий ефект — стабільне відтворення. З випуску йдуть класи дефектів, які раніше ловилися вже на прийманні: розсинхрон таймінгів між платформами, артефакти на межі кадрів, розмиття на великих екранах і обрив циклу під час повернення на екран.
Вага анімації в застосунку при цьому залишається передбачуваною — її видно до випуску, а не після скарг.
Формати та способи доставки анімації в застосунок
Формати анімації для застосунків різняться не лише зовнішнім виглядом, а й вагою, швидкодією та трудомісткістю подальших правок.
Після експорту анімацій Figma потрібно вирішити, як саме рух потрапить у збірку: від цього залежить плавність на слабких пристроях і те, хто зможе поправити ефект після релізу. Нижче — три робочі варіанти та їхні обмеження.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Векторна анімація (Lottie, JSON-опис) | Іконки, ілюстрації, стани кнопок, переходи між екранами — там, де потрібні масштабування й зміна кольору без перемальовування | Складні маски, розмиття й градієнти відтворюються важко, частину ефектів вихідного макета доводиться збирати вручну |
| Покадрова послідовність | Короткі акценти зі складною пластикою: частинки, «живі» ілюстрації, реакція на дію користувача | Помітно зростає вага збірки й пам'ять під кеш кадрів, погано масштабується під різні щільності екрана |
| Вбудована анімація інтерфейсу | Штатні взаємодії: поява екранів, натискання, навігація — де важлива миттєва реакція | Обмежена можливостями платформи, нестандартний рух доводиться описувати кодом вручну |
На практиці формати поєднують в одному застосунку: вектор закриває великі переходи та ілюстрації, покадрова послідовність — поодинокі акценти, вбудована анімація — повсякденні дотики.
Розподіл робимо на вході, під час розбору макетів: позначаємо, що йде у вектор, а що потребує покадрового малювання. Так вага збірки залишається під контролем, а правка руху не перетворюється на перемальовування всієї сцени.
Як проходить підготовка анімації до випуску
Вихідний файл у Figma — це макет, а не файл для застосунку: частина шарів у збірці не потрібна, а поведінку під час переривання переходу зазвичай ніхто не перевіряє. Порядок робіт будуємо так, щоб такі місця знаходилися до передачі в розробку, а не в релізі.
- Розбір вихідних файлів. Прибираємо дублі та приховані шари, растрові вставки переводимо у вектор — це напряму впливає на підсумкову вагу файлу.
- Схема станів екрана. Фіксуємо, звідки й куди йде перехід, що відбувається при повторному натисканні, виході з екрана та обриві завантаження. Без неї в коді з'являються гілки, які ніхто не перевіряв.
- Збірка анімації в Lottie. Розкладаємо рух за ключовими кадрами, шрифти переводимо в криві, скорочуємо зайві контрольні точки на кривих.
- Перевірка на пристроях. Проганяємо на слабкому й топовому парку: плавність, витрата батареї, поведінка під час згортання, темна тема, довгі підписи після локалізації.
- Виправлення. За зауваженнями перезбираємо: спрощуємо рух, який не читається, готуємо полегшений варіант для слабких пристроїв.
- Передача в розробку. Віддаємо файли зі зрозумілими іменами, тривалістю, точками входу та виходу, прив'язкою до станів — здогадуватися не потрібно.
- Супровід. Зберігаємо вихідні файли та версії, щоб правка після редизайну не перетворювалася на перезбирання з нуля.
Що передаємо разом з експортом анімацій
Пакет передачі анімації збираємо так, щоб її можна було доопрацьовувати й повторно використовувати без нас. Розробник або дизайнер відкриває вихідні файли, звіряється зі схемою шарів і продовжує роботу в тому самому порядку, що й ми. Нижче — що йде в проєкт разом із готовими файлами.
- Вихідні файли анімації — робочий файл з усією ієрархією шарів, станами й варіантами, без правок «поверх» і втрачених зв'язків між елементами.
- Готові файли анімації — експорт у Lottie, оптимізований за вагою та кількістю ключових кадрів, із перевіркою відтворення на обох платформах.
- Схема шарів — карта відповідності: який шар до якого елемента інтерфейсу прив'язаний і що зміниться, якщо його вимкнути.
- Правила найменування шарів — єдиний словник префіксів і суфіксів, за яким автоматика збирає анімацію й не плутає стани.
- Документація з анімації — тригери запуску, тривалість, повтори, поведінка під час переривання та на слабкому пристрої.
- Регламент оновлення — як вноситься правка, хто погоджує, як фіксується версія і що потрапляє в наступний експорт.
- Чек-ліст приймання — пункти, за якими ви приймаєте роботу й перевіряєте нову анімацію перед випуском.
Окремо проговорюємо, що вважаємо правкою всередині анімації, а що — новою анімацією. Це знімає спірні ситуації, коли після випуску змінюється структура, а не лише колір або таймінг.
Кейс: прибрали ривки та розсинхрон анімації екранів
Застосунок з анімованими переходами: онбординг, картки товару, підтвердження замовлення.
Розкадрування робив дизайнер, а рух розробник перезбирав вручну в коді — на тестових пристроях переходи виглядали рівно, на частині реальних моделей рвалися: елементи смикалися під час відкриття списку, відгук кнопки відставав від тапу.
За реліз накопичувалося близько сорока зауважень щодо інтерфейсу, частина переходила в наступний цикл і там дублювалася.
Що змінили
Рухи перевели в Lottie — формат векторної анімації, відкритий Airbnb, і вибудували зв'язку «макет — файл — плеєр застосунку». Дизайнер віддає рух окремим файлом із явними тригерами: тап, скрол, поява екрана.
Розробник підключає його як ресурс, без ручного перезбирання таймінгу й траєкторій, тому правки анімації більше не задача інженера.
Метрики до та після
- дефекти анімації за реліз: 38 → 4, і всі чотири — різні моделі пристроїв, а не повтор одного збою;
- час на правку руху: два дні на перезбирання й перевірку → менше години;
- частка звернень до підтримки з формулюванням «смикається інтерфейс»: скоротилася в п'ять разів;
- усунення ривків закріпилося в перевірках перед випуском, а не в ручному перегляді.
Розсинхрон анімації зникав не тому, що «стало більше тестів», а тому що зникло ручне перенесення таймінгів між дизайном і кодом — джерело розбіжностей було одне, і його прибрали.
Побічний ефект: векторний файл руху важить менше за набір кадрів, застосунок помітно швидше стартує на слабких пристроях.
Векторна анімація чи покадрова: що вибрати
Вибір диктує не редактор, а характер сцени: скільки шарів рухається одночасно, чи є розмиття, маски й градієнти, як часто анімація з'являється на екрані. Векторна анімація описує рух кривими та ключовими кадрами — файл важить мало й однаково чітко виглядає на будь-якому екрані.
Покадрова складається із заздалегідь відмальованих кадрів: ресурсомісткість відтворення передбачувана, але вага файлу й прив'язка до роздільності вищі.
Експорт векторної анімації з Figma в Lottie дає компактний файл, який відтворюється нативно й правиться дизайнером без перезбирання застосунку. Покадрова виручає там, де потрібна багата картинка: частинки, дим, складні текстури.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Векторна (файл з Figma) | Іконки, перемикачі, індикатори завантаження, прості переходи, будь-які розміри екрана | Десятки рухомих шарів, маски й розмиття помітно навантажують слабкі пристрої |
| Покадрова растрова (набір кадрів або відео) | Складні переходи, частинки, текстури, де важлива кожна деталь картинки | Більша вага, прив'язка до роздільності, правки потребують повторного малювання |
| Гібрид | Довгий перехід між екранами: векторна основа плюс растрові вставки | Складніше збирати й підтримувати, потрібен контроль синхронізації шарів |
Правило просте: короткі інтерфейсні анімації та складні переходи між станами екрана — вектор; насичені сцени з частинками й текстурами — покадрова або гібрид.
Якщо в сцені більше десятка шарів, що рухаються одночасно, є розмиття або маска, перевіряємо її на найслабшому пристрої з підтримуваних.
Перед здачею рахуємо три речі: скільки анімацій грає одночасно, скільки займає файл і як швидко сцена стартує на слабкому пристрої. Зайві шари прибираються прекомпозицією, а важкі ділянки замінюються растровою вставкою.
Часті технічні питання щодо анімації в застосунку
Перед стартом у команди й замовника зазвичай одні й ті самі питання щодо анімації: сумісність, вага, підтримка, оновлення та розбіжності між пристроями. Розбираємо їх заздалегідь — до першої ітерації не залишається непорозумінь.
Кожна відповідь нижче в роботі перетворюється на перевірний критерій приймання.
Наскільки анімація сумісна з нашим застосунком?
Сумісність анімації залежить від того, які шари та ефекти потрапили в експорт: маски, градієнти й контури обрізання переносяться не завжди. Звіряємо сценарій на цільових версіях системи до передачі в розробку.
Наскільки важким вийде файл анімації?
Вага файлу анімації зростає від кількості ключових кадрів, вкладених груп і растрової графіки всередині векторів. Спрощуємо криві, чистимо порожні шари, розбиваємо довгу сцену на фрагменти — картинка та сама, файл помітно легший.
Що з підтримкою анімації після випуску?
Ресурси зберігаються окремо й зі зрозумілими іменами, тому правку вносить будь-який інженер команди, а не лише автор сцени. До кожного набору додаємо опис структури та правила правки.
Як оновлення анімації потрапляє в застосунок?
Якщо сцену винесено в окремий ресурс, оновлення анімації не потребує нового випуску в магазинах застосунків — достатньо замінити файл. Для чутливих екранів тримаємо версіонування й відкат до попереднього набору.
Чому на різних пристроях анімація виглядає по-різному?
Розбіжності дають частота оновлення екрана, обсяг пам'яті та версія системи. Тому тестування анімації йде не лише на топових моделях: перевіряємо слабкі пристрої, переривання сцени та її коректне завершення.
Обговорімо анімацію вашого застосунку
Обговорити задачу найпростіше на живому макеті: надішліть файл у Figma з доступом на перегляд і перелічіть анімації за пріоритетом — екран завантаження, переходи між станами, відгук на натискання. Цього достатньо, щоб зрозуміти обсяг роботи без довгого листування.
Перший крок займає один-два робочі дні. За цей час ми розбираємо структуру шарів, перевіряємо, що векторні елементи та групи коректно експортуються, і позначаємо місця, де потрібне перезбирання.
Після розбору повертаємося з оцінкою термінів і планом робіт за етапами — з конкретними датами, а не із загальним діапазоном.
- Макет із доступом на перегляд і коментарі — правки позначаємо прямо у файлі, переносити їх вручну не потрібно.
- Список анімацій за пріоритетом: що показуємо в першій збірці, що йде в другу.
- Сценарії запуску: де анімація стартує сама, де — за дією користувача або під час прокручування.
- Обмеження: тривалість, вага файлу, вимоги цільових платформ.
- Посилання на випущений застосунок, якщо він уже працює — подивимося, як поводяться наявні анімації.
- Схема підтримки анімації після запуску: як передаються правки і що змінюється без перезбирання екрана.
Анімація застосунку під ключ — це весь шлях від розбору макета до перевірки на живих пристроях. Напишіть, що у вас на руках, — повернемося з оцінкою та планом.
