|
|
window.requestAnimationFrame 告诉浏览器您要执行的动画并且请求浏览器的在下一个动画帧重绘窗口,方法在浏览器重绘之前作为一个回调函数被调用,就是告诉浏览器在刷新屏幕的时候，调用这个方法
再看别人实现粒子效果的时候会有以下代码：
复制代码 代码如下:
window.requestAnimationFrame || (window.requestAnimationFrame = window.webkitRequestAnimationFrame || window.mozRequestAnimationFrame
|| window.oRequestAnimationFrame || window.msRequestAnimationFrame ||
function(callback, element) {
return window.setTimeout(function() {
return callback(+new Date());
}, 1000 / 60)
});
这个到底是什么意思，它又是怎么用的呢？
window.requestAnimationFrame 告诉浏览器您要执行的动画并且请求浏览器的在下一个动画帧重绘窗口。该方法在浏览器重绘之前作为一个回调函数被调用。
就是告诉浏览器在刷新屏幕的时候，调用这个方法。
window.requestAnimationFrame的前世今生：
在90年代，那个互联网做广告的年代，window上面各种走马灯，各种状态文字都是用setTimeout来时实现的,如下：
复制代码 代码如下:
(function(){
function update(){
setTimeout(update,1000)
}
setTimeout(update,1000)
})();
(function(){
function update(){
//
}
setInterval(update,1000)
})();
动画的问题最棘手的是延时问题，对于显示器来说，每一秒60帧频，如果我们按照浏览器的刷新速率来控制我们的动画时间的话会有很好的效果，即17ms,setTimeout（callback,1000/60)，但是：
1.各个浏览器及时精度是不一样的。
2.对于setTimeout 和setInterval 实现机制并不是我们需要的那样，当经过特定的时间后，浏览器会将那部分代码加入到UI的绘制队列当中，如果这个时候UI线程很忙，有其它的任务阻塞，动画的下一帧就不会按时执行。经过长时间的累计堆加之后，可能我们偏离原来的时间点误差越来越大。
Mozilla 的 Robert O'Callahan 在思考这个问题，并想出了一个独特的方案。他指出CSS transitions 和 animations的优势在于浏览器知道哪些动画将会发生，所以得到正确的间隔来刷新UI。而javascript动画，浏览器不知道动画正在发生。他的解决方案是创建一个mozRequestAnimationFrame()方法来告诉浏览器哪些javascript代码正在执行，这使得浏览在执行一些代码后得到优化。
mozRequestAnimationFrame()方法接受一个参数，是一个屏幕重绘前被调用的函数。这个函数用来对生成下合适的dom样式的改变，这些改变用在下一次重绘中。你可以像调用setTimeout()一样的方式链式调用mozRequestAnimationFrame()。
这个就是window.requestAnimationFrame的由来。
在Mozilla官网看到如下
Because this technology's specification has not stabilized, check the compatibility table for the proper prefixes to use in various browsers. Also note that the syntax and behavior of an experimental technology is subject to change in future version of browsers as the spec changes.
由于这项技术的规范还没有稳定，正确的前缀使用在各种浏览器的兼容性表。还要注意的是语法和行为的实验技术是如有改变，在未来版本的浏览器的规格变化。
目前在Android系统下是不支持的，动画只能setTimeout咯。 |
|
发表于 2013-1-13 13:54:08
