谈requestAnimationFrame 理解

郑重申明，以下只是本人的理解。没有实践论证，引用者小心！我不希望有人被我坑！

传统的js动画是通过setTimeout循环调用实现。

setTimeout调用一次将引起页面的改变，即页面将重绘。

问题一，如果setTimeout调用频率过高会发生什么情况呢？

杯具的16ms，在早期。js的callback执行，是依赖CPU的中断来进行控制的，如果两个中断之间时间太短会导致，CPU性能消耗很高，同时影响能耗，于是微软和英特公司为了解决这个问题，就约定每个中断之间的间隔是15.6ms（64 fps）所以就是我们常见的约等于16ms的间隔。
不过随着web的要求不断增加，大家对这个要求希望是放宽的态度，于是在高端浏览器，这个性能被提升了4倍左右，所以在chrome，ie10等浏览器，setTimeout的间隔缩短到了 4ms （250 fps）。（换句话说，setTimeout是一个可以不停切换函数调用的函数，在计算机中，函数的切换cpu会产生中断，如果切换很快，势必会引起 cpu中断频率加快，开发浏览器的小伙伴们怕cpu吃不消，所以做了切换时间频率最小限制。什么是中断，可以查书自己。中断分为软中断，和硬中断。。。）

意味着你把setTimeout的时间设置为趋近于0，那么它的实际间隔时间还是会为最低的4ms ，或者16ms。

问题二，那么是不是网页重绘，屏幕就一定会重刷呢？

不一定，我们显示器是有一个刷新频率的，60HZ，85HZ等。如果您的setTimeout的频率过快，那么就浪费了，

因为就算你网页重绘了，依然看不到，显示器还没有重新刷屏呢！

我们通过 requestAnimationFrame 告诉浏览器我们有业务方法需要像动画一样被不停调用，至于何时调用，浏览器做为一个客户端应用，我觉得应该能访问到系统的屏幕刷新频率，那么在系统重刷屏的时候，即浏览器知道，或者说有记录，那么浏览器就去调用requestAnimationFrame注册的业务方法。
我们在业务方法里面写动画业务。这样，我们的网页重绘就不浪费了。

兼容性：

ie 10.0，11.0

ff 22.0 (moz) 23.0 以上

chrome 28.0 以上

Safari 6.0 （webkit） 7.0 以上

Opera 16.0 以上

ios Safari 6.0-6.1 （webkit） 7.0 以上

android 不支持

ie mobile 10.0

以下是一个比较兼容的js版本

window.requestAnimFrame = (function(){
return  window.requestAnimationFrame       ||
window.webkitRequestAnimationFrame ||
window.mozRequestAnimationFrame    ||
function( callback ){
window.setTimeout(callback, 1000 / 60);
};
})();

或者

window.requestAnimFrame = (function(w, r) {
w['r'+r] = w['r'+r] || w['webkitR'+r] || w['mozR'+r] || w['msR'+r] || w['oR'+r] || function(c){ w.setTimeout(c, 1000 / 60); };
return w['r'+r];
})(window, 'equestAnimationFrame');

另外：CSS3 transition或animation 绘制原理差不多，但是，css3在改变滚动条等就力不从心了。

参考文章： http://www.zhangxinxu.com/wordpress/?p=3695 http://html5online.com.cn/articles/2012081102.html http://www.cnblogs.com/aaronjs/archive/2012/07/05/2577177.html