前几天刚发了一篇利用setTimeout提高ui响应速度的文章，本来感觉自己对setTimeout的理解已经够深入了，但是昨天偶然听说setTimeout其实是有“bug”的:在setTimeout 0时，并不能精确定时，还说IE会有16ms的延时
虽然早就想到js这种东西定时肯定不会很精确的，而且这个时延对“提高ui响应速度”影响也不大，但是如果是做动画的话，影响可能就比较大了，还说抽空写了段小程序试了试
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| //定时长度
var OUT_TIME = 0;
//循环次数
var LOOP_COUNT = 100;
$(function(){
$('a#start').click(function(){
var t1 = mst();
loopOut(LOOP_COUNT, t1);
});
});
//递归循环
function loopOut(i, t1){
if(--i > 0){
setTimeout(function(){
loopOut(i, t1);
}, OUT_TIME);
}else{
var t2 = mst();
alert(t2 - t1);
}
}
//返回当前时间点的毫秒数
function mst(){
return new Date().getTime();
} |
上面的程序，当点击“start”按钮后，首先会取当前时间t1，然后调用loopOut，当循环参数i大于0时，会通过setTimeout定时0ms递归调用loopOut，同时i会减1，形成循环终止条件，放循环满100次时，再次取当前时间，与t1相减，也就是100此setTimeout循环的用时
测试结果发现，“IE会有16ms的延时”，这话并不算错，IE7、8，最后的返回值大概是1530~1550，算起来，一次setTimeout大概要延迟DT=15.4ms
而且chrome/safari/firefox，返回值大概是420~430，即DT=4.2ms
当增大定时长度OUT_TIME时，只有增大到各浏览器的DT时，实际的定时长度才会有效，也就是DT可以看成“最小定时长度”
但是即便定时长度大于DT定时也是不精确的，非IE大概是0.2ms，IE就有点离谱了，比如OUT_TIME=50时，平均每次的定时长度大概是60ms，差了10ms（鄙视）
综上所述，虽然setTimeout传入的时间值是毫秒，但是是在并不精确，如果对精度要求较高，最好好好计算各浏览器的误差
下面讨论另外两种情况
1. 既然setTimeout有这种问题，那么与它类似的setInterval有问题吗？
将上面的“loopOut”方法稍加改进，即可setInterval：
1
2
3
4
5
6
7
8
9
| function loopOut(i, t1){
var si = setInterval(function(){
if(--i == OUT_TIME){
var t2 = mst();
alert(t2 - t1);
clearInterval(si);
}
}, OUT_TIME);
} |
这是，IE再次表型了它的卓尔不群：当OUT_TIME=0的时候，setInterval的回调方法只会执行一次，只有OUT_TIME>0，这段脚本在IE里才能正常执行
除此之外，setInterval和前面setTimeout的表现基本相同
2. node.js的setTimeout精确吗？
将上面click部分的代码去掉，稍加修改，既可以让代码再node里执行，但是为了去除代码初始化的影响，这里用了另外一个setTimeout，让其在程序初始化100ms以后在执行
1
2
3
4
| setTimeout(function(){
var t1 = mst();
loopOut(LOOP_COUNT, t1);
}, 100); |
测试结果发现，服务器端脚本相对浏览器端的效率果然高出不少，在循环次数为100的时候，node.js的setTimeout 0ms的延迟大约在0.1ms左右，当把循环次数提高的100000后，平均的延迟降到了0.01ms
关于本站