css与js动画对比：谁更快？

js动画怎么可能已经比css实现的变换效果还快了？并且，adobe和谷歌怎么可能开发出可以和原生应用性能比肩的富媒体移动网站？

这篇文章点对点的对比分析了为什么基于javascript的dom动画库，如Velocity.js和GSAP，拥有比基于jQuery和css的动画更好的表现？

jQuery

让我们从基本的地方开始：javascript被错误的混在了一起。javascript动画是快的，jQuery让它变慢了。为啥？因为—尽管jQuery非常高效—但jQuery的设计目标从来都不是成为一个动画引擎：
1.jQuery不能避免布局废弃(layout thrashing)，因为它的代码服务于很多目标而不仅是动画。
2.jQuery的内存消耗经常触发垃圾回收，这会立刻冻结动画。
3.jQuery使用setinterval而不是requestAnimationFrame
(RAF)，为了保护初学者。
注意到布局废弃(layout thrashing)导致了动画开始时的卡顿，垃圾回收导致动画过程中的卡顿，不使用RAF通常导致低帧速率。

实例(Implementation
Examples)

通过简单的批处理DOM请求和DOM更新，可以避免布局废弃(layout
thrashing)：

var currentTop,
currentLeft;

/* With layout thrashing. */
currentTop = element.style.top; /* QUERY */
element.style.top = currentTop + 1; /* UPDATE */

currentLeft = element.style.left; /* QUERY */
element.style.left = currentLeft + 1; /* UPDATE */

/* Without layout thrashing. */
currentTop = element.style.top; /* QUERY */
currentLeft = element.style.left; /* QUERY */

element.style.top = currentTop + 1; /* UPDATE */
element.style.left = currentLeft + 1; /* UPDATE */

更新后的请求会强制浏览器重新计算页面的样式数据(为了把更新的影响考虑进去)。这给本来就只有16毫秒极小间隔的动画增加了显著的瓶颈。
同样的，实现RAF不需要对你已有的代码进行大规模的修改。让我们来比较一下RAF和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);

通过RAF你只需要简单的改变一下你的代码就能最大限度的提升动画性能。

CSS Transitions

CSS Transitions 胜过jQuery的地方在于它将动画逻辑直接扔给浏览器自己去完成。这样做的好处是：1）优化DOM交互和内存消耗以避免卡顿，2）内部实现RAF的原理
以及3）强制硬件加速(调用GPU提升动画性能).
然而，事实上这种优化可以直接通过javascript来实现。GSAP已经这样做了很多年，Velocity.js，一个新的动画引擎，不仅实现了同样的技术而且还向前迈进了好几步——我们将稍微探讨一下。
开始认识到javascript动画能够匹敌css动画只是我们恢复工程的第一步，第二步是认识到javascript动画可以比CSS动画库更快。
让我们先来分析一下CSS动画库的弱点：
1.Transitios强制硬件加速增加了GPU的负担，引起设备卡顿和高压环境。这个影响在移动设备上更加严重。(具体来说，卡顿是浏览器的主线程和compositor线程进行数据交换达到性能瓶颈的结果。一些CSS属性，像transform和opacity对这个性能瓶颈比较敏感。)Adobe将这个事儿在此做了详尽说明。
2.Transitions不能工作在10以下 的IE浏览器上，这会导致桌面站点上的可访问性问题，毕竟IE8，IE9依然广泛存在。
3.由于Transitions不能由javascript在本地控制(仅能被JavaScript触发)，浏览器不知道该怎么同时优化transition以及控制它的JavaScript代码。
相反的：基于JavaScript的动画库可以自己决定什么时候使用硬件加速，他们能正常的工作在各种版本的IE上，同时它们可以完美的适应成批的动画优化。
我的建议是当你专门为移动设备做开发并且你的动画只是简单的状态改变时可以用原生的CSS
 Transitions。在这种情况下，transitions是一种个性能和本地 的解决方案，它允许你将所有动画逻辑保持在样式表里并且可以避免你的页面因引入JavaScript动画库而变得臃肿。但是如果你在设计一个复杂的UI排版，或者在开发一个有态式UI的app，
请使用JavaScript动画框架来保证你的动画性能高效并保证你的工作流程可控。一个管理CSS Transition非常优秀的库是Transit.

JavaScript 动画

是的，所以在性能方面JavaScript更优秀。但确切的JavaScript能够快多少？好吧——开始——快到可以建立一个通常仅可以用WebGL实现的极致的3D
animation demo，快到可以建立一个通常仅能用Flash来做的multimedia teaser。快到可以做一个通常只能用canvas实现的虚拟世界。

想直接比较高性能动画库，包括Transit(用CSS Transitions构建)，前往Velocity的文档VelocityJS.org.

问题依然存在：JavaScript具体如何实现高性能的？下面是一个短的基于JavaScript动画能够做的优化清单：

1.同步DOM——tween
stack整个动画链以最大化的减少布局废弃。

2.通过请求链获取属性值以最少化DOM请求(这是最损害动画性能的一点)。

3.通过兄妹元素获取同一个请求中的独立转换比例 (e.g.
px to %, em, etc.)。

4.当样式更新不可见时跳过样式更新。

原文链接：http://davidwalsh.name/css-js-animation