Avantages de l'animation CSS3 :
Les performances seront légèrement meilleures et le navigateur effectuera quelques optimisations pour l'animation CSS3 (comme la création d'un nouveau calque pour exécuter l'animation)
Le code est relativement simple
Mais ses défauts sont également évidents :
Dans le contrôle d'animation Non assez flexible
Mauvaise compatibilité
Certaines fonctions d'animation ne peuvent pas être implémentées (comme l'animation de défilement, le défilement de parallaxe, etc.)
L'animation JavaScript compense simplement ces deux défauts. Elle possède de fortes capacités de contrôle et peut contrôler et transformer des images uniques. En même temps, si elle est bien écrite, elle est entièrement compatible avec IE6 et possède des fonctions puissantes. Mais considérez que la matrice de transformation de l'animation CSS est un calcul de niveau C, qui doit être plus rapide que les calculs de niveau JavaScript. De plus, la dépendance vis-à-vis des bibliothèques est également un casse-tête.
Pour certaines animations contrôlées complexes, il est plus fiable d'utiliser javascript. Lors de la mise en œuvre de petits effets interactifs, pensez à davantage de CSS.
Sur la base de l'expérience réelle du projet, dans le même contexte, il y a peu de différence dans l'efficacité de l'animation entre les deux solutions. Ce qui affecte davantage l'efficacité est :
. Que cela provoque une mise en page
Repeindre la zone
Qu'elle ait des attributs coûteux (ombre CSS, etc.)
S'il faut activer l'accélération matérielle
La modification dynamique de la marge et de la hauteur des éléments de flux réguliers entraînera un processus de disposition sur une grande surface, qui est tout aussi lent que l'utilisation JS ou CSS3.
La modification dynamique du translation3D de l'élément active naturellement l'accélération 3D. Il n'y a pas de grande différence de fréquence d'images entre l'utilisation de setTimeout/setInterval/requestAnimationFrame et CSS3.
La principale différence aujourd'hui est
1. La couverture des fonctions, JS est plus grande que CSS3
Les @keyframes qui définissent le processus d'animation. ne prend pas en charge la définition récursive. S'il existe plusieurs processus d'animation similaires et que plusieurs paramètres doivent être ajustés pour les générer, il y aura beaucoup de redondance (comme la solution d'animation de jQuery Mobile), tandis que JS peut naturellement implémenter plusieurs fonctions avec un ensemble. de fonctions. Différents processus d'animation
Sur l'échelle de temps, la granularité de l'animation de @keyframes est grossière, tandis que le contrôle de la granularité de l'animation de JS peut être très fin
CSS3 Il y a très peu de fonctions temporelles prises en charge dans l'animation et ce n'est pas assez flexible
Avec l'interface existante, l'animation CSS3 ne peut pas prendre en charge plus de deux transitions d'état
2. La difficulté de mise en œuvre/reconstruction varie. CSS3 est plus simple que JS, et la direction de réglage des performances est fixe
3 pour les navigateurs de version basse avec des performances de fréquence d'images médiocres. , CSS3 peut être un déclassement naturel, tandis que JS nécessite l'écriture de code supplémentaire
4. CSS3 a des problèmes de compatibilité, mais JS n'a la plupart du temps pas de problèmes de compatibilité
Ce qui suit vous expliquera étape par étape pourquoi les bibliothèques d'animation DOM basées sur Javascript (telles que Velocity.js et GSAP) peuvent être plus efficaces que les bibliothèques d'animation basées sur jQuery et CSS.
jQuery
Commençons par les bases : Javascript et jQuery ne peuvent pas être confondus. Les animations Javascript sont rapides, tandis que les animations jQuery sont lentes. Pourquoi? Car bien que jQuery soit extrêmement puissant, son objectif de conception n'est pas d'être un moteur d'animation efficace :
jQuery ne peut pas éviter le layout thrashing (certains aiment le traduire par "layout thrashing", ce qui provoquera (relais/redistribution redondant), car son code n'est pas seulement utilisé pour l'animation, il est également utilisé dans de nombreux autres scénarios.
jQuery consomme beaucoup de mémoire et déclenche souvent le garbage collection. Il est facile pour l’animation de rester bloquée lorsque le garbage collection est déclenché.
jQuery utilise setInterval au lieu de reqeustAnimationFrame(RAF), car RAF cessera de se déclencher lorsque la fenêtre perdra le focus, ce qui provoquera des bugs jQuery. (Actuellement, jQuery utilise déjà RAF)
Notez que le thrashing de la mise en page entraînera le gel de l'animation au début, et le déclenchement du garbage collection entraînera le gel de l'animation pendant le processus en cours. N'utilisez pas RAF. Cela entraînerait une faible fréquence d'images de l'animation.
Exemple d'implémentation
Afin d'éviter les problèmes de mise en page, nous devons accéder et mettre à jour le DOM par lots.
var currentTop, currentLeft; /* 有 layout thrashing. */ currentTop = element.style.top; /* 访问 */ element.style.top = currentTop + 1; /* 更新 */ currentLeft = element.style.left; /* 访问 */ element.style.left = currentLeft + 1; /* 更新 */ /* 没有 layout thrashing. */ currentTop = element.style.top; /* 访问 */ currentLeft = element.style.left; /* 访问 */ element.style.top = currentTop + 1; /* 更新 */ element.style.left = currentLeft + 1; /* 更新 */
Les opérations d'accès après une opération de mise à jour obligeront le navigateur à recalculer le style de l'élément de page (car le style mis à jour doit être appliqué pour obtenir la valeur correcte). Cela n'entraîne pas beaucoup de perte de performances en fonctionnement normal, mais cela entraînera une surcharge de performances importante lorsqu'il est placé dans des animations avec un intervalle de seulement 16 ms. Changer légèrement l’ordre des opérations peut grandement améliorer les performances de l’animation.
De même, utiliser RAF ne nécessite pas de refactoriser beaucoup votre code. Comparons la différence entre l'utilisation de RAF et l'utilisation de setInterval :
var startingTop = 0; /* setInterval: Runs every 16ms to achieve 60fps (1000ms/60 ~= 16ms). */ setInterval(function() { /* Since this ticks 60 times a second, we divide the top property's increment of 1 unit per 1 second by 60. */ element.style.top = (startingTop += 1/60); }, 16); /* requestAnimationFrame: Attempts to run at 60fps based on whether the browser is in an optimal state. */ function tick () { element.style.top = (startingTop += 1/60); } window.requestAnimationFrame(tick);
Il vous suffit de modifier légèrement le code pour utiliser RAF, et vos performances d'animation seront grandement améliorées.
CSS Transition
CSS transition 的动画逻辑是由浏览器来执行,所以它的性能能够比 jQuery 动画好。它的优势体现在:
通过优化 DOM 操作,避免内存消耗来减少卡顿
使用与 RAF 类似的机制
强制使用硬件加速 (通过 GPU 来提高动画性能)
然而实际上Javascript也可以使用这些优化。GSAP 已经做这些优化很久了。Velocity.js 是一个新兴的动画引擎,它不仅仅做了这些优化,甚至走的更远些。我们稍后会谈到这些。
面对事实,让 Javascript 动画得以媲美 CSS 动画的性能只是我们伟大计划的第一步。第二步才是重头戏,要让 Javascript 动画比 CSS 动画还要快!
让我们来看看 CSS 动画库的缺陷吧:
Transition 强制使用了 GPU 的硬件加速。导致浏览器一直处于高负荷运转的状态,这反而会让动画变的卡顿。这在移动浏览器上更为严重。(特别要说明的是,当数据在浏览器的主线程和合成线程之间频繁传输的时候特别消耗性能,故容易导致卡顿。某些 CSS 属性,不会受到影响。Adobe 的博客谈到过这个问题。
IE 10以下的浏览器不支持 transition。而目前 IE8 和 IE9 还是很流行的。
transition 不能完全被 Javascript 控制(只能通过 Javascript 来触发 transition),因为浏览器不知道如何同时让 Javascript 控制动画又同时优化动画的性能。
反过来说: 基于 Javascript 可以决定什么时候启用硬件加速,它可以支持全版本的 IE,并且它完全可以进行批量动画的优化。
Javascript 动画
所以 Javascript 可以比 CSS transition 性能更好。但是它到底有多块呢?它快到足够可以构建一个3D 动画的demo,通常需要用到 WebGL 才能完成。并且它快到足够搭建一个多媒体小动画,通常需要 Flash 或者 After Effects 才能完成。并且它还快到可以构建一个虚拟世界,通常需要 canvas 才能完成。
为了更直接的来比较主流动画库的性能,包括 Transit(使用了 CSS transition),让我们打开Velocity的官方文档。
之前那个问题还在:Javascript 是如何达到高性能的呢?下面是一个列表,列举了基于 Javascript 的动画库能做的事情:
同步DOM -> 在整个动画链中微调堆栈以达到最小的layout thrashing。
缓存链式操作中的属性值,这样可以最小化DOM的查询操作(这就是高性能 DOM 动画的阿喀琉斯之踵)
在同一个跨同层元素的调用中缓存单位转化比率(例如px转换成%、em等等单位)
忽略那些变动小到根本看不出来的DOM更新
让我们重新温习下之前学到的关于layout thrashing的知识点。Velocity.js 运用了这些最佳实践,缓存了动画结束时的属性值,在紧接的下一次动画开始时使用。这样可以避免重新查询动画的起始属性值。
$element /* Slide the element down into view. */ .velocity({ opacity: 1, top: "50%" }) /* After a delay of 1000ms, slide the element out of view. */ .velocity({ opacity: 0, top: "-50%" }, { delay: 1000 });
在上面的样例中,第二次调用 Velocity 时已经知道了 opacity 的起始值为 1,top 的值为 50%。
浏览器也可以使用与此类似的优化,但是要做这些事情太过激进,使用场景也会受到限制,开发者就有可能会写出有bug的动画代码。jQuery就是因为这个原因没有使用RAF(如上所说),浏览器永远不会强行实施可能打破规范或者可能偏离期望行为的优化。
最后,让我们来比较下两个Javascript框架(velocity.js 和 GSAP)。
GASP 是一个快速且功能丰富的动画平台。Velocity则更为轻量级,它大大地改善了UI动画性能和工作流程。
GSAP 需要付费才能用于商业产品。Velocity 是完全免费的,它使用了自由度极高的 MIT 协议。
性能方面,两者几乎相当,很难区分胜负。
Velocity.js
之前提到了 GSAP 有着丰富的功能,但这不代表 Velocity 的功能简单。相反的,Velocity 在 zip 压缩之后只有 7kb,它不仅仅实现了 jQuery animate 方法的所有功能,还包含了 颜色、transforms、loop、easings、class 动画和滚动动画等功能。
简单的说就是 Velocity 包含了 jQuery、 jQuery UI 和 CSS transition 的功能。
更进一步从易用性的角度来讲,Velocity 使用了 jQuery 的$.queue() 方法,因此可以无缝过渡到 jQuery 的$.animate()、$.fade()和$.delay()方法。并且 Velocity 的语法和$.animate()一摸一样,所以我们根本不需要修改页面的现有代码。
让我们快速过一下 Velocity.js 的例子:
$element .delay(1000) /* Use Velocity to animate the element's top property over a duration of 2000ms. */ .velocity({ top: "50%" }, 2000) /* Use a standard jQuery method to fade the element out once Velocity is done animating top. */ .fadeOut(1000);
如下是一个高级用法:滚动网页到当前元素并且旋转元素。这样的动画只需要简单的几行代码:
$element /* Scroll the browser to the top of this element over a duration of 1000ms. */ .velocity("scroll", 1000) /* Then rotate the element around its Y axis by 360 degrees. */ .velocity({ rotateY: "360deg" }, 1000);
Velocity 的目标是成为 DOM 动画领域性能最好易用性最高的库。这篇文章主要关注了性能方面。易用性方面可以前往 VelocityJS.org 了解。
请记住一个高性能的 UI 绝不仅仅是选择一个正确的动画库。页面上的其他代码也需要优化。