Lottie анімація: чому інтерфейс гальмує і як це виправляється
Lottie анімація виглядає нешкідливо: дизайнер віддає JSON-файл, розробник підключає його до екрана — і ось уже кнопка м'яко пульсує, а онбординг оживає.
Проблема проявляється пізніше, коли таких файлів на одному екрані п'ять, кожен зі своєю часовою шкалою, а застосунок раптом починає губити кадри на середніх пристроях.
Анімація інтерфейсу застосунку перестає бути прикрасою і стає вузьким місцем: користувач бачить ривки під час скролу, а в логах зростає споживання пам'яті.
Причина в тому, як Lottie-плеєр працює з вмістом файлу. Кожен шар — це окремий об'єкт зі своїми трансформаціями, масками та ефектами; складні маски й розмиття змушують перемальовувати область заново на кожному кадрі.
Якщо векторна сцена містить сотні шляхів, а рендеринг відбувається в реальному часі, навантаження лягає на головний потік — і плавність екранів тримається лише на потужному залізі. На слабких пристроях це виливається в просідання частоти оновлення та помітні затримки відгуку.
Друга прихована стаття витрат — вага й кількість ассетів. Один важкий JSON на екрані ще терпимий, але коли анімації підвантажуються заздалегідь і залишаються в пам'яті, застосунок непомітно з'їдає ресурс, який потрібен спискам і зображенням.
Оптимізація анімацій починається не з коду, а з аудиту: скільки сцен реально потрібно, які шари можна спростити, де достатньо статичного стану.
Продуктивність мобільного застосунку тут упирається в три речі — складність сцени, момент її запуску та спосіб рендерингу.
Прибрати зайві маски, розбити довгу анімацію на короткі фрагменти, запускати її лише за видимості екрана й кешувати результат — це не косметика, а робота з вузьким місцем, яке безпосередньо впливає на утримання. Розбираємо, як це закривається на практиці.
Що дає вивірена Lottie анімація: ефект у цифрах
Lottie анімація — це векторний формат, який програється нативно на пристрої, а не як відеопотік. Ключова різниця з GIF та послідовністю PNG: замість сотень растрових кадрів у збірку потрапляє один компактний JSON-файл із кривими та таймінгами.
Саме тому коректно зібрана анімація дає вимірюваний ефект: час відмалювання кадру падає, споживання пам'яті на екрані знижується, а частка відмов на слабких пристроях іде вниз.
Що саме вимірюємо
- Час відмалювання кадру. Векторні шари перераховуються на GPU, важкі растрові підстановки не блокують головний потік — інтерфейс залишається чутливим навіть при скролі.
- Споживання пам'яті. Один JSON замість набору кадрів скорочує вагу екрана в рази: анімація не тримає в пам'яті десятки растрових шарів одночасно.
- Частка відмов на слабких пристроях. Без відеопотоку та зайвих декодерів анімація не «з'їдає» кадри на бюджетних моделях — сценарій відпрацьовує передбачувано.
- Оптимізація відмалювання. Маски, градієнти та вкладені композиції перезбираються в плоску структуру, щоб не плодити зайві шари при рендері.
Порівняння форматів анімації
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Lottie (вектор) | Іконки, онбординг, мікроанімації, стани кнопок | Складні фотореалістичні сцени потребують растрових вставок |
| GIF | Прості короткі цикли, де важлива сумісність | Обмежена палітра, велика вага, немає плавності |
| Відео (MP4/WebM) | Довгі заставки, складні ефекти | Важка вага, окремий декодер, складніше масштабувати під екрани |
| Растрова послідовність | Рідкісні кадрові ефекти | Різко зростає вага збірки та споживання пам'яті |
Вибір формату — це компроміс між вагою, плавністю та складністю сцени. Для інтерфейсних анімацій вектор майже завжди виграє: він масштабується під будь-яку щільність екрана без втрати якості та не тягне за собою відеоплеєр.
Lottie від Airbnb задає стандарт обміну векторною анімацією між дизайном і розробкою — файл збирається один раз і однаково програється на обох платформах.
Ми закладаємо у збірку перевірку ваги, числа шарів і профіль відмалювання, щоб ефект від анімацій був реальним, а не декларативним.
Як ми впроваджуємо анімації: етапи інженерної роботи
Впровадження анімацій починається не з відмальовування, а з аудиту інтерфейсу: інженери проходять по екранах, заміряють час відгуку, знаходять місця, де інтерфейс «мовчить» — перехід між станами, завантаження даних, підтвердження дії.
На цьому етапі фіксуємо, які сценарії справді виграють від руху, а які залишаються статичними: анімація заради анімації з'їдає бюджет кадрів і заважає роботі.
Далі — проєктування та складання. Кожен перехід отримує таймінг, криву прискорення та точку виходу, щоб рух збігався з логікою екрана, а не жив окремо від неї.
Готові сцени збираються в Lottie-анімацію та перевіряються на реальних пристроях: вага файлу, плавність на слабкому залізі, поведінка при перериванні жестом.
- Аудит інтерфейсу. Проходимо по екранах, заміряємо відгук, складаємо карту місць, де потрібна анімація, і відсікаємо зайве.
- Узгодження сценаріїв. Фіксуємо, що саме анімуємо, як довго і що відбувається при повторному натисканні або виході з екрана.
- Прототип руху. Збираємо чорнову Lottie-анімацію на ключових переходах, показуємо на пристрої до фінального відмальовування.
- Продакшн-складання. Відмальовуємо сцени, оптимізуємо контури та шари, прибираємо все, що не впливає на картинку, але тягне вагу.
- Перевірка на пристроях. Проганяємо на слабких і сильних моделях, дивимося плавність і споживання пам'яті при тривалому використанні.
- Інтеграція в застосунок. Підключаємо анімації до екранів, стежимо, щоб вони не блокували інтерфейс і коректно зупинялися.
- Передача анімацій і документації. Віддаємо вихідники, готові файли, правила таймінгів та інструкцію, як вносити правки без нас.
Такий інженерний процес дає передбачуваний результат: анімації не роздувають складання, не гальмують на слабких пристроях і залишаються керованими після здачі. Опишіть задачу — повернемося з оцінкою та планом за етапами.
Чим відрізняється Lottie від покадрової та нативної анімації?
Lottie анімація — це векторна анімація, яка описується не набором картинок, а математичною моделлю: координати, криві, ключові кадри та тайминги. Файл зберігає інструкції «що і як рухається», а відмальовку на пристрої виконує рантайм-бібліотека.
Звідси головна відмінність від покадрової анімації: замість десятків растрових кадрів на кожен перехід у застосунок потрапляє один компактний файл, який масштабується під будь-який екран без втрати різкості.
Покадрова анімація — це послідовність готових зображень, що програються як слайди. Вона дає повний контроль над картинкою: можна намалювати складні текстури, шум, світло, ефекти, які вектор просто не відтворить.
Але плата — вага та пам'ять: довга сцена перетворюється на сотні кадрів, кожен займає місце у збірці та в оперативній пам'яті під час програвання. На слабких пристроях це помітно за просіданнями під час прокручування та за витратою батареї.
Нативна анімація збирається засобами самої платформи — шарами, трансформаціями, переходами між станами екрана. Вона ідеальна для інтерфейсних рухів: поява кнопки, зміна вкладки, відгук на натискання. Тут мінімальна вага та максимальна чутливість, бо все робить система.
Обмеження — виразність: складну ілюстративну сцену з десятками незалежних об'єктів нативною анімацією збирати довго та дорого в підтримці.
Вибір формату — це компроміс між виразністю, вагою та складністю правок. Lottie виграє там, де потрібна детальна векторна сцена, єдиний файл для двох платформ і швидка правка без перезбирання застосунку: дизайнер змінює файл, і оновлення прилітає без релізу.
Покадрова бере гору на коротких зациклених роликах з фотореалістичною графікою, де вектор безсилий. Нативна — на всьому, що стосується поведінки інтерфейсу, а не ілюстрації.
За пам'яттю та складністю Lottie програє, коли сцена перевантажена: сотні шарів, важкі маски, розмиття та градієнти змушують рантайм перераховувати геометрію на кожному кадрі, і на бюджетних пристроях це дає просідання.
Тут допомагає спрощення сцени, розбивка на кілька файлів і передзавантаження. Ми на старті оцінюємо кожну анімацію за цими параметрами і пропонуємо формат під конкретний екран, а не за замовчуванням.
Кейс: як ми прибрали смикання екранів у застосунку доставки
Екран оформлення замовлення в застосунку доставки смикався під час скролу: кадр збирався довше, ніж пристрій встигав його показати, і на слабких моделях анімація розсипалася на ривки.
Проблема була не у верстці, а в тому, що важкі векторні шари перезбиралися на кожному кадрі замість того, щоб програватися як готова послідовність.
Заміри до правок: відмальовування кадру виходило за бюджет у 16 мс, пікове споживання пам'яті на екрані трималося близько 180 МБ, а частка відмов під час відкриття кошика на пристроях початкового рівня сягала 7%.
Що саме змінили
Ми винесли анімацію кошика та статусів доставки в Lottie анімацію — заздалегідь прораховану векторну послідовність, яку програє нативний рендерер без перезбирання шарів на кожному кадрі.
Важкі растрові спрайти та ланцюжки вкладених шарів замінили на один компактний файл, а сам програвач ініціалізується один раз під час входу на екран і перевикористовується між переходами.
Окремо обмежили кількість одночасно активних анімацій: поки одна програється, решта ставляться на паузу, щоб не конкурувати за потік відмальовування.
Метрики до і після
| Метрика | До | Після |
|---|---|---|
| Час відмальовування кадру | виходило за бюджет 16 мс | стабільно в межах бюджету |
| Пікова пам'ять на екрані | ~180 МБ | ~95 МБ |
| Відмови на слабких пристроях | до 7% | нижче 1% |
| Розмір анімаційного ресурсу | кілька наборів спрайтів | один векторний файл |
Скрол перестав смикатися, а екран кошика відкривається передбачувано навіть на бюджетних моделях. Ми працюємо на Lottie — форматі, який однаково програється на обох платформах без окремого збирання під кожну, тому правки анімації не потребують перезбирання нативних модулів.
Результат впровадження
Плавність інтерфейсу перестала залежати від класу пристрою: те, що раніше «сипалося» на слабких моделях, тепер працює однаково рівно.
Оптимізація застосунку дала побічний ефект — екран став швидше відкриватися й менше навантажувати батарею, бо рендерер не перераховує шари на кожному кадрі. Далі цей самий підхід ми перенесли на екрани відстеження замовлення та онбордингу.
Сумніви щодо сумісності, відкату та доступів — розбираємо
Lottie анімація — це не окремий артефакт «у вакуумі», а файл, який має коректно програватися на конкретних версіях iOS і Android, у конкретній бібліотеці рантайму та в конкретному стані екрана.
Тому головне технічне питання не «чи гарно виглядає», а «що буде, коли анімація зустрінеться з вашим поточним стеком». Нижче — розбір типових сумнівів, які виникають до старту.
Що якщо у нас інша версія рантайму? Ми збираємо анімацію під ту гілку бібліотеки, яка вже стоїть у проєкті, а не під останню. Якщо версія стара — або адаптуємо векторні шари під підтримуваний набір властивостей, або пропонуємо точкове оновлення рантайму з перевіркою на регресії. Сумісність анімацій перевіряється на реальних пристроях з вашої матриці, а не лише в редакторі.
Що якщо після релізу потрібно відкотити? Кожна анімація версіонується окремим файлом, тому відкат змін — це заміна одного артефакту на попередній, без перезбирання логіки екрана. Ми фіксуємо, яка версія пішла в який реліз, щоб повернення займало хвилини, а не години пошуків.
Як ви отримаєте доступ до проєкту і що залишиться у вас?
Ми працюємо у вашому репозиторії або передаємо вихідники окремим архівом — доступи до проєкту оформлюються на ваші акаунти, а не на наші. Після здачі у вас залишаються редаговані вихідники анімацій, а не лише стиснені файли, тому правки можна вносити без нас.
Що якщо ми захочемо змінювати анімації самі? Передача документації включає структуру шарів, назви груп і правила експорту — дизайнер або розробник з базовим досвідом внесе правку, не ламаючи рантайм.
Технічні сумніви щодо міграції на інший рушій теж закриваємо заздалегідь: описуємо, які властивості не переносяться один в один.
Що замовник отримує на руки:
- вихідні файли анімацій у редагованому форматі;
- експортовані файли під iOS і Android з перевіркою на пристроях;
- карту версій: який файл у якому релізі;
- інструкцію з експорту та заміни анімації;
- список підтримуваних властивостей і обмежень рантайму;
- чеклист перевірки перед релізом.
Опишіть вашу поточну версію рантайму та матрицю пристроїв — повернемося з оцінкою та планом робіт з анімацій.
