JavaScript-js性能与setTimeout 的问题

Question

有时候我们开发复杂交互的web产品时, 会考虑到流畅性而使用setTimeout 让某个操作在进程为空(或者说CPU比较空闲)的时候才去执行, 可以一定程度上提高流畅性, 但是同时 又听说setTimeout会带来性能问题, setTimeout真的会有性能问题吗?
如果有 那么与他带来的流畅度提升的好处之间如何权衡?
如果一个页面中使用了多个 比如10个setTimeout 又会怎样?

//............. 页面初始化时 一大堆DOM操作 事件绑定等代码
setTimeout(function () {
    startPage();//开场动画  为了保证流畅性 延迟执行
},1)

Answer 1

通常我们所说的单线程应该是指的核心的javascript执行引擎是单线程的。实际上，在web客户端整个的运行体系中，肯定是有多线程存在的，这就包括对setTimeout/setInterval的延时分配。 例如 ...; setTimeout(fn, 100); ...; 在解释器解释到这句set***的时候，会启动一个线程，在当前执行时刻100ms后准时“唤醒”（只是唤醒，并不是执行。即使后面遇到死循环也会唤醒。），唤醒后就讲这个回调函数fn加入到执行队列中去，这个队列的执行过程则是单线程的。但是这其中浏览器单独产生了这样一个线程，保证在100ms后准时的“唤醒”回调函数加入到队列。这个多线程的设计保证了这个延时机制的准确性，并不依赖循环检查。

Answer 2

关键是要记得清理掉定时器

Answer 3

首先，你要弄清楚Javascript是单线程执行的，还是多线程执行的？
看如下代码

setTimeout( function(){ while(true){} } , 100);
setTimeout( function(){ alert('你好!'); } , 200);

第二个setTimeout会执行吗？答案是否定的。因为Javascript是单线程的。

你页面只有10个setTimeout，浏览器的内部轮询的耗损可以忽略不计的。setTimeout之所以会让人感觉到有“性能问题”，是因为多个setTimeout的函数堵塞了（先执行的setTimeout有可能堵塞后面的setTimeout）。

希望能帮到你。

Answer 4

还真从来没听说过这种说法……setTimeout和setInterval的原理应该都是浏览器固有时钟中断的地方检查每一个timeOut是否到达。固有中断就算间隔小到1ms，1ms的时间里检查几百个Timeout应该问题也不大的。

更主要的问题是，除了这个方法，你还有别的方法可以用嘛？