Чому анімації 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 підміняється файлом: розмітка й переходи залишаються на місці. Найдорожче заміна обходиться там, де ефект зав’язаний на розмітку — тоді правиться й сам екран.
Хто підтримує анімацію після здачі?
Віддаємо файли ефектів, схему прив’язки до екранів і правила запуску. Колір, швидкість і тривалість ваша команда змінює без нас; переробка сценарію переходу — завдання на години, а не на перезбірку застосунку.
Як ефекти поводяться на недорогих пристроях?
Важкі ефекти на слабкому пристрої дають просідання плавності й нагрівання. Заздалегідь готуємо спрощений варіант і вимикаємо фонові шари за низького заряду — інтерфейс залишається чутливим, ефект не зникає.
Що робити, якщо макет уже намальовано?
Оцінюємо його на реалізовність: частина ефектів переноситься один в один, частина потребує спрощення під реальні обмеження. Трудомісткість правок залежить від кількості унікальних переходів — чим більше екранів малюють макет заново, тим більше роботи.
Обговоримо завдання: покажіть поточний стан інтерфейсу
Щоб розмова була предметною, потрібен не весь проєкт цілком, а мінімальний набір даних про конкретні екрани та анімації. Ми відтворюємо поведінку на пристрої і тільки після цього даємо оцінку та план робіт — інакше терміни перетворюються на здогади.
- Перелік проблемних екранів. Де саме анімація смикається, провалюється перший кадр, підгальмовує прокручування або розвалюється на слабкому пристрої — назви екранів за макетом і в самому застосунку.
- Записи поведінки застосунку. Екранний запис із реального пристрою, із зазначенням моделі та версії системи. Якщо питання у векторній анімації, додайте вихідний файл, який відмальовується на цьому екрані.
- Посилання на збірку. Доступ до тестової збірки, тестовий акаунт і дані, за яких дефект відтворюється стабільно, — це знімає половину уточнень.
- Макети та вихідники анімацій. Проєкт у вихідному редакторі, розбивка за шарами та зазначення, що саме має рухатися, а що залишається статичним.
- Перелік вимог. Платформи, мінімальні версії системи, обмеження щодо ваги застосунку та витрат батареї, референси анімацій — і що в них подобається конкретно.
- Вимоги до термінів. До якої дати потрібен реліз, чи є прив’язка до зовнішньої події, чи готові приймати проміжні збірки з частковими змінами.
На виході ви отримуєте оцінку та план робіт: етапи, що робимо ми, що потрібно від вашої команди, і наступний крок із датою. Опишіть завдання — повернемося з пропозицією.