Facebook加入
LINE加入
2021/12/25
作者：李三思
原文：www.cnblogs.com/fly-snow/archive/2016/04/24/5427865.html
（點擊文末閱讀原文即可前往）
setTimeout,前端工程師必定會打交道的一個函數.它看上去非常的簡單,樸實.有著一個很不平凡的名字–定時器.讓年少的我天真的以為自己可以操縱未來.卻不知樸實之中隱含著驚天大密.我還記得我第一次用這個函數的時候,我天真的以為它就是js實現多線程的工具.當時用它實現了一個坦克大戰的小遊戲,玩兒不亦樂乎.可是隨著在前端這條路上越走越遠,對它理解開始產生了變化.它似乎開始蒙上了面紗,時常有一些奇怪的表現讓我捉摸不透.終於,我的耐心耗盡,下定決心,要撕開它的面具,一探究竟.
要說setTimeout的淵源,就得從它的官方定義說起.w3c是這麼定義的
setTimeout 方法用於在指定的毫秒數后調用函數或計算表達式。
看到這樣一個說明,我們明白了它就是一個定時器,我們設定的函數就是一個」鬧鐘」,時間到了它就會去執行.然而聰明的你不禁有這樣一個疑問,如果是settimeout(fn,0)呢?按照定義的說明,它是否會立馬執行?實踐是檢驗真理的唯一標準,讓我們來看看下面的實驗
DOCTYPE html
<html lang="en"
<head
<meta charset="UTF-8"
<titletitle
head
<body
body
html
這是一個很簡單的實驗,如果settimeout(0)會立即執行,那麼這裡的執行結果就應該是1->2>3 . 然而實際的結果卻是1->3->2. 這說明了settimeout(0)並不是立即執行.同時讓我們對settimeout的行為感到很詭異.
js引擎是單線程執行的
我們先把上面的問題放一放.從js語言的設計上來看看是否能找到蛛絲馬跡.
我們發現js語言設計的一個很重要的點是,js是沒有多線程的.js引擎的執行是單線程執行.這個特性曾經困擾我很久,我想不明白既然js是單線程的,那麼是誰來為定時器計時的?是誰來發送ajax請求的?我陷入了一個盲區.即將js等同於瀏覽器.我們習慣了在瀏覽器裡面執行代碼,卻忽略了瀏覽器本身.js引擎是單線程的,可是瀏覽器卻可以是多線程的,js引擎只是瀏覽器的一個線程而已.定時器計時,網路請求,瀏覽器渲染等等.都是由不同的線程去完成的. 口說無憑,咱們依然看一個例子
DOCTYPE html
<head
head
<body
body
html
isEnd默認是true的,在while中是死循環的.最後的alert是不會執行的. 我添加了一個定時器,1秒后將isEnd改為false. 如果說js引擎是多線程的,那麼在1秒后,alert就會被執行.然而實際情況是,頁面會永遠死循環下去.alert並沒有執行.這很好的證明了,settimeout並不能作為多線程使用.js引擎執行是單線程的.
event loop
從上面的實驗中,我們更加疑惑了,settimeout到底做了什麼事情呢?
原來還是得從js語言的設計上尋找答案.
js引擎單線程執行的,它是基於事件驅動的語言.它的執行順序是遵循一個叫做事件隊列的機制.從圖中我們可以看出,瀏覽器有各種各樣的線程,比如事件觸發器,網路請求,定時器等等.線程的聯繫都是基於事件的.js引擎處理到與其他線程相關的代碼,就會分發給其他線程,他們處理完之後,需要js引擎計算時就是在事件隊列裡面添加一個任務. 這個過程中,js並不會阻塞代碼等待其他線程執行完畢,而且其他線程執行完畢后添加事件任務告訴js引擎執行相關操作.這就是js的非同步編程模型.
如此我們再回過頭來看settimeout(0)就會恍然大悟.js代碼執行到這裡時,會開啟一個定時器線程,然後繼續執行下面的代碼.該線程會在指定時間后往事件隊列裡面插入一個任務.由此可知settimeout(0)裡面的操作會放在所有主線程任務之後. 這也就解釋了為什麼第一個實驗結果是1->3-2 .
由此可見官方對於settimeout的定義是有迷惑性的.應該給一個新的定義:
在指定時間內, 將任務放入事件隊列,等待js引擎空閑后被執行.
js引擎與GUI引擎是互斥的
談到這裡,就不得不說瀏覽器的另外一個引擎—GUI渲染引擎. 在js中渲染操作也是非同步的.比如dom操作的代碼會在事件隊列中生成一個任務,js執行到這個任務時就會去調用GUI引擎渲染.
js語言設定js引擎與GUI引擎是互斥的,也就是說GUI引擎在渲染時會阻塞js引擎計算.原因很簡單,如果在GUI渲染的時候,js改變了dom,那麼就會造成渲染不同步. 我們需要深刻理解js引擎與GUI引擎的關係,因為這與我們平時開發息息相關,我們時長會遇到一些很奇葩的渲染問題.看這個例子
DOCTYPE html
<head
head
<body
<table border=1
<tr><td><button id='do'Do long calc - bad status!buttontd
<td><div id='status'Not Calculating yet.divtd
tr
<tr><td><button id='do_ok'Do long calc - good status!buttontd
<td><div id='status_ok'Not Calculating yet.divtd
tr
table>
body
html
我們希望能看到計算的每一個過程,我們在程序開始,計算,結束時,都執行了一個dom操作,插入了代表當前狀態的字元串,Not Calculating yet.和calculating….和calclation done.計算中是一個耗時的3重for循環. 在沒有使用settimeout的時候,執行結果是由Not Calculating yet 直接跳到了calclation done.這顯然不是我們希望的.而造成這樣結果的原因正是js的事件循環單線程機制.dom操作是非同步的,for循環計算是同步的.非同步操作都會被延遲到同步計算之後執行.也就是代碼的執行順序變了.calculating….和calclation done的dom操作都被放到事件隊列後面而且緊跟在一起,造成了丟幀.無法實時的反應.這個例子也告訴了我們,在需要實時反饋的操作,如渲染等,和其他相關同步的代碼,要麼一起同步,要麼一起非同步才能保證代碼的執行順序.在js中,就只能讓同步代碼也非同步.即給for計算加上settimeout.
settimeout(0)的作用
不同瀏覽器的實現情況不同,HTML5定義的最小時間間隔是4毫秒. 使用settimeout(0)會使用瀏覽器支持的最小時間間隔.所以當我們需要把一些操作放到下一幀處理的時候,我們通常使用settimeout(0)來hack.
requestAnimationFrame
這個函數與settimeout很相似,但它是專門為動畫而生的.settimeout經常被用來做動畫.我們知道動畫達到60幀,用戶就無法感知畫面間隔.每一幀大約16毫秒.而requestAnimationFrame的幀率剛好是這個頻率.除此之外相比於settimeout,還有以下的一些優點:
requestAnimationFrame 會把每一幀中的所有DOM操作集中起來，在一次重繪或迴流中就完成，並且重繪或迴流的時間間隔緊緊跟隨瀏覽器的刷新頻率，一般來說，這個頻率為每秒60幀,每幀大約16毫秒.
在隱藏或不可見的元素中，requestAnimationFrame將不會進行重繪或迴流，這當然就意味著更少的的cpu，gpu和內存使用量。
但它優於setTimeout/setInterval的地方在於它是由瀏覽器專門為動畫提供的API，在運行時瀏覽器會自動優化方法的調用，並且如果頁面不是激活狀態下的話，動畫會自動暫停，有效節省了CPU開銷。
瀏覽器的內核是多線程的，它們在內核制控下相互配合以保持同步，一個瀏覽器至少實現三個常駐線程：javascript引擎線程，GUI渲染線程，瀏覽器事件觸發線程。
javascript引擎是基於事件驅動單線程執行的.JS引擎一直等待著任務隊列中任務的到來，然後加以處理，瀏覽器無論什麼時候都只有一個JS線程在運行JS程序。
當界面需要重繪（Repaint）或由於某種操作引發迴流(reflow)時,該線程就會執行。但需要注意 GUI渲染線程與JS引擎是互斥的，當JS引擎執行時GUI線程會被掛起，GUI更新會被保存在一個隊列中等到JS引擎空閑時立即被執行。
當一個事件被觸發時該線程會把事件添加到待處理隊列的隊尾，等待JS引擎的處理。這些事件可來自JavaScript引擎當前執行的代碼塊如setTimeOut、也可來自瀏覽器內核的其他線程如滑鼠點擊、AJAX非同步請求等，但由於JS的單線程關係所有這些事件都得排隊等待JS引擎處理。
熱門推薦
留言回覆
