谈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

你可能感兴趣的:(web前端)