相信所有做前端開發的同學都會經常使用?setTimeout(0)?來做很多事情，這個一度成為解決了很多前端疑難雜癥的法寶。而且大家也知道?setTImeout(0)?的極限在16ms左右。也許很多人沒想到這個是一個很嚴重的問題，但是在w3c性能小組的專家眼里這是一個非常糾結的設置。

那setTimeout和16ms會帶來什么問題呢？

1.?我們都知道，我們在做頁面動畫的時候大多數都是在用setTImeout來控制每一幀的動畫的， 而多個setTimeout的存在會導致很多次CPU中斷調度的開銷，為了減少這些開銷，我們希望同一個統一的CPU中斷調度管理調度單元來管理所有動畫，

于是就出現了?requestAnimationFrame。?requestAnimationFrame?的出現不僅僅可以解決中斷調度的問題，還可以更加優化得統一管理動畫單元里dom元素的repaint方式。

2.?杯具的16ms，在早期。js的callback執行，是依賴CPU的中斷來進行控制的，如果兩個中斷之間時間太短會導致，CPU性能消耗很高，同時影響能耗，于是微軟和英特公司為了解決這個問題，就約定每個中斷之間的間隔是15.6ms（64 fps）所以就是我們常見的約等于16ms的間隔。不過隨著web的要求不斷增加，大家對這個要求希望是放寬的態度，于是在高端瀏覽器，這個性能被提升了4倍左右，所以在chrome，ie10等瀏覽器，setTimeout的間隔縮短到了 4ms?（250 fps）。 但是問題來了，這么高的消耗以傳統的方式，并不能從根本上解決CPU的調度問題，而且能耗也會提升40%

于是W3C，提出需要取代?setTimeout(0)?的代替品 ---?setImmediate

不過到底底層如何解決了這個CPU調度，還能保證腳本能夠很快執行，這塊舜子還在研究，了解的朋友也歡迎一起交流哈。

?

這是兩個非常好的方法用來取代setTimeout的api，舜子也做了一些小小的實驗來驗證 requestAnimationFrame,setImmediate 和 setTimeout 之間的執行效率區別，在IE10下可以看到，setImmediate 接口的callback次數可以達到每秒 6000 次的的執行。而requestAnimationFrame主要目的是為了保證動畫的圓滑播放，所以基本上是控制在60 fps的范圍，而且根據文檔介紹，只是一個時鐘控制器在進行調度，而且會更加需要來進行按需渲染。

http://www.pjhome.net/web/html5/timing_test.htm

總結

以上是生活随笔為你收集整理的setTimeout(0) 即将退役的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。