Колись більшість розробників використовувало jQuery для анімації елементів в браузері. Знебарвити то, розтягнути це - прості речі. Але коли інтерактивні проекти стали більш агресивними, а мобільні пристрої увірвалися на сцену, продуктивність стала грати найважливішу роль.
Flash поступово зійшов з дистанції, і талановиті аніматори змусили HTML5 робити речі, які він ніколи не робив раніше. Їм потрібні були більш ефективні інструменти для складних ефектів і першокласної продуктивності.
jQuery просто не був призначений для цього. Браузери подорослішали і почали пропонувати рішення.
Найбільш широко відомим рішенням стали CSS анімації. CSS анімація як улюбленець IT-індустрії, на протязі декількох років нескінченно обговорювалася на конференціях, де такі фрази, як «апаратне прискорення» і «дружність мобільних пристроїв» пестили слух аудиторії.
Будучи тим, хто зачарований (на межі одержимості, фактично) анімацією і продуктивністю, я з нетерпінням кинувся в обійми CSS. І не встиг я далеко просунутися, як виявилося безліч серйозних проблем, про які ніхто не розповідав. Я був у шоці.
Відсутність незалежного контролю масштабу / повороту / позиції
Анімація масштабу, повороту і позиції елемента є надзвичайно поширеною. В CSS всі ці параметри запхати в властивість transform, що унеможливлює створення окремої анімації для кожного параметра одного елемента.
Наприклад, що якщо ви хочете зробити анімацію повороту і масштабу незалежно один від одного, з різними розрахунком часу виконання і функціями пом'якшення?
На мою думку, це явно слабка сторона CSS, але якщо ви створюєте простіші анімації, які задіюють перетворення цілком в будь-який момент часу, тоді цей момент не складе для вас проблему.
продуктивність
Найбільш часто приводиться аргумент за використання CSS для анімації - це «апаратне прискорення». Звучить апетитно, правда?
Давайте розіб'ємо його на дві частини:
Залучення графічного процесора
Графічний процесор (GPU) сильно оптимізований для таких завдань, як переміщення пікселів, застосування прозорості та матриць перетворення, тому сучасні браузери намагаються перекласти такі завдання з центрального процесора (CPU) на GPU.
Секрет полягає в тому, щоб виділити анімовані елементи в власні GPU шари, тому що як тільки шар створений (за умови, що його вихідні пікселі не змінюються), для GPU не складає ніяких труднощів переміщати ці пікселі і комбінувати їх разом.
Замість обчислення кожного окремого пікселя 60 раз в секунду, GPU може зберегти групи пікселів (як шари) і просто сказати: «Зміщуємо цю групу на 10 пікселів і на 5 пікселів вниз» (або щось в цьому роді).
Також відзначимо, що в повному обсязі властивості CSS отримують GPU прискорення в CSS анімаціях. Фактично, більшість з них цього прискорення якраз не отримують. Перетворення (масштаб, поворот, зсув і нахил) і прозорість є основними операціями, які користуються вигодами GPU прискорення.
Перерозподіл обчислень на інший потік
Інша частина «апаратного прискорення» пов'язана з можливістю використання різних потоків CPU для обчислень, що відносяться до анімації. Знову ж таки, це звучить здорово в теорії, але не проходить без витрат, і розробники часто переоцінюють одержувані переваги.
Перш за все, тільки ті властивості, які не впливають на потік документа, дійсно можуть бути передані іншому потоку.
Тому знову, перетворення і прозорість - основні одержувачі вигоди. При відгалуженні потоків з'являються накладні витрати, пов'язані з управлінням цим процесом.
Оскільки рендеринг графіки і макет документа з'їдають більшу частину обчислювальних ресурсів (набагато більшу) в більшості анімацій (не рахуючи проміжних значень властивостей анімації), користь від використання окремого потоку для інтерполяції мінімальна.
Наприклад, якщо 98% роботи протягом певної анімації це рендеринг графіки і макет документа, а 2% - з'ясування нових значень позиції / повороту / прозорості / ще чогось, навіть обчислюючи їх в 10 разів швидше, в цілому ви побачите приблизно всього 1 % приросту швидкості.
порівняння продуктивності
Стрес-тест, наведений нижче, створює певну кількість елементів зображень (точок) і приводить їх в рух з центру в випадкове місце близько кордонів з використанням довільних затримок, створюючи тим самим ефект польоту крізь зірки.
Задайте велика кількість точок і подивіться порівняння jQuery. GSAP і Zepto.
Оскільки Zepto використовує CSS трансформації для всіх анімацій, його продуктивність повинна бути найкращою, так?
Результати підтверджують те, що широко відзначається в Інтернеті - CSS анімації значно швидше, ніж jQuery.
top, left, width, height
Windows Surface RT, iPhone 5s (iOS7), iPad 3 (iOS 6), iPad 3 (iOS7), Samsung Galaxy Tab 2, Chrome, Firefox, Safari, Opera, Kindle Fire HD, IE11
Windows Surface RT, iPhone 5s (iOS7), iPad 3 (iOS7), Samsung Galaxy Tab 2, Firefox, Opera, IE11
iPad 3 (iOS6), Safari, Chrome
Наскільки швидше? Первісна версія тесту мала лічильник кількості кадрів в секунду для отримання кількісних результатів, але незабаром виявилося, що немає ніякого по-справжньому точного способу виміряти цей показник у всіх браузерах, особливо з CSS анімаціями, і деякі браузери видавали вводять в оману дані, тому я видалив цю функцію.
Хоча ви легко можете оцінити відносну продуктивність, збільшуючи кількість точок, перемикаючись між двигунами і спостерігаючи, як відбувається виконання анімації (плавність руху, рівномірність проміжків часу, розподіл точок і т.п.). Зрештою, головна мета полягає в тому, щоб отримати презентабельні анімації.
Але хочеться вірити, що це зміниться. Як би там не було, в більшості реальних проектів ви ніколи б не помітили різницю в продуктивності.
Я закликаю вас провести власне тестування, щоб подивитися яка технологія забезпечить плавну анімацію в конкретному проекті (ах).
Не купуйтеся на міф, що CSS анімації завжди швидше, і не вважайте, що тест на швидкість, наведений вище, відображає те, що ви побачите в вашому додатку. Тестируйте, тестируйте і ще раз тестируйте.
Елементи управління виконанням і події
Деякі браузери дозволяють зупинити або перезапустити анімацію з ключовими кадрами CSS, але на цьому - все.
Ви не можете звернутися до конкретного місця в анімації, також як не можете плавно змінити напрямок ходу на ділянці анімації, або змінити шкалу часу, або додати зворотні виклики в певних місцях, або прив'язати їх до багатого набору подій відтворення.
Сучасна анімація дуже сильно пов'язана з інтерактивністю, тому неймовірно корисно мати можливість виконувати анімацію від змінюваних початкових значень до змінюваних кінцевих (наприклад, залежать від того, в якому місці користувач клацне мишею) або змінити щось «на льоту», але декларативні анімації на основі CSS не дозволяють зробити це.
Робочий процес
Для простих переходів між двома станами (наприклад, перевороти або розкриття меню, і т.п.) відмінно підходять CSS трансформації.
Однак, для послідовності подій вам, як правило, потрібно використовувати анімації CSS з ключовими кадрами, в яких обов'язково потрібно визначати селектори у вигляді відсотків, наприклад:
Але коли ви створюєте анімацію, хіба ви не орієнтуєтеся за допомогою тимчасових інтервалів, а не відсотків? Наприклад, «збільшити прозорість протягом 1 секунди, потім зрушувати вправо протягом 0,75 секунди, і потім на решті секунді зробити стрибок вниз».
Що станеться, якщо ви витратите кілька годин на обчислення складної послідовності у відсотках, а клієнт потім скаже: «Зробіть цю частину в середині на 3 секунди довше»? ОФФ, вам доведеться перераховувати ВСЕ відсотки!
Зазвичай побудова анімацій включає в себе велику кількість експериментів, особливо з часом і функціями пом'якшення.
Це актуально там, де метод seek () виявився б досить корисним. Уявіть собі створення 60-секундної анімації шматочок за шматочком, а потім відточування заключних 5 секунд: вам довелося б просиджувати перші 55 секунд кожен раз, коли ви хочете подивитися результат ваших коригувань в останніх частинах.
Фу! За допомогою методу seek () ви могли б у процесі роботи просто послатися на певне місце анімації, щоб потрапити в ту частину, над якою працюєте, а потім видалити його, коли закінчите. Це значна економія часу.
Широке поширення отримує створення анімації для об'єктів на основі canvas і інших об'єктів сторонніх бібліотек, але, на жаль, CSS анімації призначені тільки для DOM елементів.
Це означає, що якщо ви вклали багато часу і енергії в CSS анімації, їх не можна буде перенести в інші типи проектів.
Ви повинні будете змінити набір інструментів для анімації.
Існує ще кілька зручних інструментів, що відносяться до робочого процесу, які відсутні в CSS анімаціях:
обмежені ефекти
Ви не зможете зробити нічого з нижченаведеного списку за допомогою CSS анімації:
- Анімація уздовж кривої (наприклад, кривої Безьє);
- Використання цікавих функцій пом'якшення, таких як пружне, пружинисте або грубе пом'якшення. Існує опція cubic-bezier (). але вона допускає тільки дві ключові точки, що сильно обмежує можливості;
- Рухи по фізичним законам. Наприклад, плавне переміщення на основі інерції і легке повернення назад, реалізоване в цьому Draggable demo;
- Анімація позиції прокрутки;
- Спрямований поворот (наприклад, «повернути рівно на 270 градусів в найкоротшому напрямку, за годинниковою або проти годинникової стрілки»);
- Анімація атрибутів.
сумісність
Анімації на основі CSS не працюють в IE9 і більш ранніх версіях браузера. Більшість з нас ненавидять забезпечувати підтримку застарілих браузерів (особливо IE), але реальність така, що у деяких з нас є клієнти, які вимагають зробити це.
Застосування префіксів необхідно для багатьох браузерів, але ви можете використовувати засоби попередньої обробки, щоб уникнути необхідності писати їх вручну.
висновок
Чи погані CSS анімації? Безумовно ні. Фактично, вони відмінно підходять для простих переходів між станами (наприклад, перевертання), коли не потрібно сумісність із застарілими браузерами.
Тривимірні перетворення зазвичай мають хорошу продуктивність (iOS7 є примітним винятком) і CSS анімації можуть бути дуже привабливі для розробників, що віддають перевагу поміщати всю логіку анімацій і презентацій в шар CSS.
Я можу зрозуміти, чому CSS анімації були такими привабливими в порівнянні з jQuery.animate (). Хто в здоровому глузді не вхопився б за можливість отримати 10-кратний приріст продуктивності?
Плюс, я хотів пролити трохи світла на деякі сторони CSS анімацій, що викликають розчарування (про які ніхто не говорить), так що тепер ви можете прийняти більш обгрунтоване рішення про те, як створювати анімації.
Чи вирішить специфікація Web Animations існуючі проблеми?
Консорціум W3C працює над новою специфікацією під назвою «Web Animations» (веб-анімації), метою якої є вирішення багатьох недоліків в CSS анімаціях і трансформаціях, забезпечення кращого контролю виконання і додаткових функцій.
Звичайно, здається, що це крок вперед у багатьох відношеннях, але все ще є ряд недоліків (деякі з яких, ймовірно, неможливо подолати через необхідність підтримки старих версій існуючих CSS специфікацій, тому, наприклад, незалежне управління компонентами перетворення малоймовірно).
Хоча цю вже зовсім інша історія. Нам необхідно почекати і подивитися, як все складеться. Є, без сумніву, розумні хлопці, які працюють над цією специфікацією.