setTimeout执行时间

经典问题：

js setTimeout 0秒，会立即执行吗？
setTimeout 1000ms 若是没有其他任务，是到了时间立即执行么，若不是间隔是多久(浏览器刷新率按60帧算就是1000、60=16.7ms)

setTimeout(function(){console.log("setTimeout执行了")},0)
for(var i=0;i<1000000000;i++){
        if(i==999999999){
                console.log(i);
        }
}
//输出：大约过了三秒后(本电脑测试)，控制台才显示出 999999999，其次才显示出 “setTimeout执行了”。

异步执行的运行机制如下(参考 JavaScript 运行机制详解)

（1）所有同步任务都在主线程上执行，形成一个执行栈（execution context stack）。
（2）主线程之外，还存在一个"任务队列"（task queue）。只要异步任务有了运行结果，就在"任务队列"之中放置一个事件。
（3）一旦"执行栈"中的所有同步任务执行完毕，系统就会读取"任务队列"，看看里面有哪些事件。那些对应的异步任务，于是结束等待状态，进入执行栈，开始执行。
（4）主线程不断重复上面的第三步。

因为 JavaScript 是一个单线程序的解释器，因此一定时间内只能执行一段代码。
为了控制要执行的代码，就有一个 JavaScript 任务队列。
这些任务会按照将它们添加到队列的顺序执行。
setTimeout() 的第二个参数告诉 JavaScript 再过多长时间把当前任务添加到队列中。如果队列是空的，那么添加的代码会立即执行；如果队列不是空的，那么它就要等前面的代码执行完了以后再执行

总结：setTimeout并不能按照设置的定时准时触发，这点可以从js事件循环来解释。当设置了该定时器时，假设定时1000毫秒，

首先，绑定函数交由定时器模块处理；
然后，当到达1000毫秒时，定时器模块会将该绑定事件加入到任务队列中，注意，这个时候已经到了我们的预设时间了，但是实际上函数并没有被执行。
最后，当任务队列中优先于该任务的函数执行完成后，才会执行该定时器绑定的函数。所以这里的实际执行的时间相比预设时间会更晚。

利用seTimeout实现的动画在某些低端机上会出现卡顿、抖动的现象。这种现象的产生有两个原因：

setTimeout的执行时间并不是确定的。在Javascript中， setTimeout 任务被放进了异步队列中，只有当主线程上的任务执行完以后，才会去检查该队列里的任务是否需要开始执行，因此 setTimeout 的实际执行时间一般要比其设定的时间晚一些。
刷新频率受屏幕分辨率和屏幕尺寸的影响，因此不同设备的屏幕刷新频率可能会不同，而 setTimeout只能设置一个固定的时间间隔，这个时间不一定和屏幕的刷新时间相同。

以上两种情况都会导致setTimeout的执行步调和屏幕的刷新步调不一致，从而引起丢帧现象。那为什么步调不一致就会引起丢帧呢？

首先要明白，setTimeout的执行只是在内存中对图像属性进行改变，这个变化必须要等到屏幕下次刷新时才会被更新到屏幕上。如果两者的步调不一致，就可能会导致中间某一帧的操作被跨越过去，而直接更新下一帧的图像。假设屏幕每隔16.7ms刷新一次，而setTimeout每隔10ms设置图像向左移动1px，就会出现如下绘制过程：

第0ms: 屏幕未刷新，等待中，setTimeout也未执行，等待中；
第10ms: 屏幕未刷新，等待中，setTimeout开始执行并设置图像属性left=1px；
第16.7ms: 屏幕开始刷新，屏幕上的图像向左移动了1px， setTimeout 未执行，继续等待中；
第20ms: 屏幕未刷新，等待中，setTimeout开始执行并设置left=2px;
第30ms: 屏幕未刷新，等待中，setTimeout开始执行并设置left=3px;
第33.4ms:屏幕开始刷新，屏幕上的图像向左移动了3px， setTimeout未执行，继续等待中；
…

从上面的绘制过程中可以看出，屏幕没有更新left=2px的那一帧画面，图像直接从1px的位置跳到了3px的的位置，这就是丢帧现象，这种现象就会引起动画卡顿。

setTimeou中的方法，在for循环结束后才执行，正是因为执行栈中的同步任务执行完之后，任务对列中的任务才能执行，所以导致 “setTimeout执行了” 在延迟了接近三秒之后才会执行。

requestAnimationFrame

requestAnimationFrame和屏幕刷新是同步的，也就是说屏幕每刷新一次，requestAnimationFrame就触发一次。与setTimeout相比，requestAnimationFrame最大的优势是由系统来决定回调函数的执行时机。

如果屏幕刷新率是60Hz,那么回调函数就每16.7ms（1000/60）被执行一次，如果刷新率是75Hz，那么这个时间间隔就变成了1000/75=13.3ms，换句话说就是，requestAnimationFrame的步伐跟着系统的刷新步伐走。它能保证回调函数在屏幕每一次的刷新间隔中只被执行一次，这样就不会引起丢帧现象，也不会导致动画出现卡顿的问题。

除此之外，requestAnimationFrame还有以下两个优势：

CPU节能：使用setTimeout实现的动画，当页面被隐藏或最小化时，setTimeout 仍然在后台执行动画任务，由于此时页面处于不可见或不可用状态，刷新动画是没有意义的，完全是浪费CPU资源。而requestAnimationFrame则完全不同，当页面处理未激活的状态下，该页面的屏幕刷新任务也会被系统暂停，因此跟着系统步伐走的requestAnimationFrame也会停止渲染，当页面被激活时，动画就从上次停留的地方继续执行，有效节省了CPU开销。

函数节流：在高频率事件(resize,scroll等)中，为了防止在一个刷新间隔内发生多次函数执行，使用requestAnimationFrame可保证每个刷新间隔内，函数只被执行一次，这样既能保证流畅性，也能更好的节省函数执行的开销。一个刷新间隔内函数执行多次时没有意义的，因为显示器每16.7ms刷新一次，多次绘制并不会在屏幕上体现出来。

requestAnimationFrame 会把每一帧中的所有 DOM 操作集中起来，在一次重绘或回流中就完成，并且重绘或回流的时间间隔紧紧跟随浏览器的刷新频率。
在隐藏或不可见的元素中，requsetAnimationFrame 将不会进行重绘或回流，这就意味着更少的 CPU、GPU 和内存使用量。requestAnimationFrame是浏览器专门提供的 api，在运行时浏览器会自动优化方法的调用，并且页面不是激活状态下，动画会暂停执行，有效节省 CPU 开销。

IE9-浏览器不兼容该方法，可以使用 setTimeout 来兼容

if(!window.requestAnimationFrame){
	let lastTime = 0;
	window.requestAnimationFrame = function(callback){
		const currTime = new Date().getTime();
		const timeToCall = Math.max(0, 16.7-(currTime - lastTime));
		const id = window.setTimeout(function(){
			callback(currTime + timeToCall);
		},timeToCall);
		lastTime = currTime + timeToCall;
		return id;
	}
}

if(!window.cancelAnimationFrame){
	window.cancelAnimationFrame = function(id){
		clearTimeout(id);
	}
}

案例说明：

let i=0
const cb=()=>{i++;console.log(i);requestAnimationFrame(cb)}
requestAnimationFrame(cb)
setTimeout(()=>{console.log("setTimeout1"+i);},0);
setTimeout(()=>{console.log("setTimeout"+i);},1000);

如下输出，浏览器默认刷新率基本是每秒60帧，那么 requestAnimationFrame时间间隔就是16.7ms，所以setTimeout 0的实在1之后打印即16.7ms后执行的，1000ms的setTimeout实在60或61输出后执行的，即60*16.7=1000也就是正好1000ms，61就是在延迟了一帧执行的，所以setTimeout不是到了时间就立即执行。

requestAnimationFrame

猜你喜欢