当我们要在页面上实现一些动画效果的时候，通常会考虑两种方式：
1、通过css3的animation+keyframes，或者transition
2、通过setTimeout或者setInterval。
毫无疑问，首选的方案是第一种。而当需要考虑兼容性，或者需要精确的控制动画的时候，无可避免地会使用setTimeout/setInterval来实现动画。这种实现方式是低效的，而且在当前时间点，可以考虑更高效的实现方式。
什么是流畅
页面的每一帧都是系统通过CPU或者GPU绘制出来的，其绘制的最高帧率受限于显示器的刷新频率。鉴于大多数的显示器刷新频率都是60Hz，页面的最大绘制帧率就是60fps（frame per second）。
因此一个动画最理想的情况就是60fps。这就意味着我们需要在把每一帧的绘制时间限制在16.7毫秒（1000/60），压力山大。
setTimeout/setInterval的问题
首先，计时并不精确。setTimeout和setInterval的计时依赖浏览器内置时钟，而内置时钟的精确度又依赖于时钟的更新频率，在IE8及以下版本的浏览器中，这个更新频率是15.6ms。也就意味着，如果把timer的间隔设成16.7ms，我们需要经历两个时钟更新周期才会触发timer，延时了14.5ms(15.6 * 2 – 16.7)。
其次，由于单线程与异步队列，当动画两帧之间有一个复杂任务时，第二帧的绘制会一直等待这个任务完毕才会开始，必然会带来卡顿现象。
假使计时是精确的（以14ms为例），任务队列也不存在阻塞状态，是不是就没问题了？我们看下图，红色帧丢失。
requestAnimationFrame
requestAnimationFrame
这里并不讨论requestAnimationFrame的定义，具体可以看：
https://developer.mozilla.org/zh-CN/docs/Web/API/Window/requestAnimationFrame
从上面的描述中，我们可以总结出影响一个动画的两个关键因素：
1、开始绘制一帧的时机。
2、绘制一帧需要的时间。
requestAnimationFrame这个原生API可以自动帮我们设置动画的帧率，我们只需要告诉它，我们需要绘制新的一帧，请在绘制下一帧的时候调用我的回调函数。这保证了上面的关键因素的第一点。对于第二点requestAnimationFrame是没有办法的，但是它可以在绘制时间比较长的时候，把动画帧率从60fps变为30fps以保证动画不卡顿。
requestAnimationFrame还处于草案阶段，浏览器的兼容性也有限：
Polyfill
requestAnimationFrame
不同的浏览器对于requestAnimationFrame定义存在差异，而且对于不支持该特性的浏览器，我们需要降级到setTimeout的方案。好在requestAnimationFrame和setTimeout的定义一致，比较方便做兼容。
兼容方法已经有成熟的实现。
关于Layer
requestAnimationFrame
我们以Apple的主页为例：
最上面的图片轮转动画里，每一页都设置了transform:translateZ(0px)。为什么可以使用2D渲染就能实现的效果却要用3D？这就跟浏览器的渲染机制有关。
首先，使用3D的话，浏览器会调用GPU而不是CPU来进行页面渲染，效率更高。
其次，浏览器渲染一个页面的过程中，会把页面元素分成若干的层（Layer），然后按层提交给GPU做贴图渲染。当我们要改变某一个DOM的样式时，比如width或者height，会触发该DOM所在层的重绘。一次操作还好，但是如果是频繁改变的动画，效率就会非常低。
Apple这里使用translate3d，就是为了单独为动画页建立Layer，进而提高重绘的效率。
总结
精度低的动画尽量使用css3来实现。
如果需要js来实现动画，可以使用requestAnimationFrame。有兼容需求可以引入polyfill。
尽量把动画DOM放在独立的Layer中。
本文作者：高原（点融黑帮），现任点融成都团队高级前端开发，四川大学计算机硕士。三年创业，一年外企经验，专注于研究前端的各种框架与新技术。业余喜欢打篮球，司职中锋。