一文看懂瀏覽器事件循環(huán)
實(shí)際上瀏覽器的事件循環(huán)標(biāo)準(zhǔn)是由 HTML 標(biāo)準(zhǔn)規(guī)定的，具體來(lái)說(shuō)就是由whatwg規(guī)定的，具體內(nèi)容可以參考event-loops in browser。而NodeJS中事件循環(huán)其實(shí)也略有不同，具體可以參考event-loops in nodejs
我們?cè)谥v解事件模型的時(shí)候，多次提到了事件循環(huán)。 事件指的是其所處理的對(duì)象就是事件本身，每一個(gè)瀏覽器都至少有一個(gè)事件循環(huán)，一個(gè)事件循環(huán)至少有一個(gè)任務(wù)隊(duì)列。循環(huán)指的是其永遠(yuǎn)處于一個(gè)“無(wú)限循環(huán)”中。不斷將注冊(cè)的回調(diào)函數(shù)推入到執(zhí)行棧。
那么事件循環(huán)究竟是用來(lái)做什么的？瀏覽器的事件循環(huán)和NodeJS的事件循環(huán)有什么不同？讓我們從零開始，一步一步探究背后的原因。
為什么要有事件循環(huán)
JS引擎
要回答這個(gè)問(wèn)題，我們先來(lái)看一個(gè)簡(jiǎn)單的例子：
- function c() {}
- function b() {
- c();
- }
- function a() {
- b();
- }
- a();
以上一段簡(jiǎn)單的JS代碼，究竟是怎么被瀏覽器執(zhí)行的？
首先，瀏覽器想要執(zhí)行JS腳本，需要一個(gè)“東西”，將JS腳本（本質(zhì)上是一個(gè)純文本），變成一段機(jī)器可以理解并執(zhí)行的計(jì)算機(jī)指令。這個(gè)“東西”就是JS引擎，它實(shí)際上會(huì)將JS腳本進(jìn)行編譯和執(zhí)行，整個(gè)過(guò)程非常復(fù)雜，這里不再過(guò)多介紹，感興趣可以期待下我的V8章節(jié)，如無(wú)特殊說(shuō)明，以下都拿V8來(lái)舉例子。
有兩個(gè)非常核心的構(gòu)成，執(zhí)行棧和堆。執(zhí)行棧中存放正在執(zhí)行的代碼，堆中存放變量的值，通常是不規(guī)則的。
當(dāng)V8執(zhí)行到a()這一行代碼的時(shí)候，a會(huì)被壓入棧頂。
在a的內(nèi)部，我們碰到了b()，這個(gè)時(shí)候b被壓入棧頂。
在b的內(nèi)部，我們又碰到了c()，這個(gè)時(shí)候c被壓入棧頂。
c執(zhí)行完畢之后，會(huì)從棧頂移除。
函數(shù)返回到b，b也執(zhí)行完了，b也從棧頂移除。
同樣a也會(huì)被移除。
整個(gè)過(guò)程用動(dòng)畫來(lái)表示就是這樣的：
(在線觀看)
這個(gè)時(shí)候我們還沒有涉及到堆內(nèi)存和執(zhí)行上下文棧，一切還比較簡(jiǎn)單，這些內(nèi)容我們放到后面來(lái)講。
DOM 和 WEB API
現(xiàn)在我們有了可以執(zhí)行JS的引擎，但是我們的目標(biāo)是構(gòu)建用戶界面，而傳統(tǒng)的前端用戶界面是基于DOM構(gòu)建的，因此我們需要引入DOM。DOM是文檔對(duì)象模型，其提供了一系列JS可以直接調(diào)用的接口，理論上其可以提供其他語(yǔ)言的接口，而不僅僅是JS。 而且除了DOM接口可以給JS調(diào)用，瀏覽器還提供了一些WEB API。 DOM也好，WEB API也好，本質(zhì)上和JS沒有什么關(guān)系，完全不一回事。JS對(duì)應(yīng)的ECMA規(guī)范，V8用來(lái)實(shí)現(xiàn)ECMA規(guī)范，其他的它不管。 這也是JS引擎和JS執(zhí)行環(huán)境的區(qū)別，V8是JS引擎，用來(lái)執(zhí)行JS代碼，瀏覽器和Node是JS執(zhí)行環(huán)境，其提供一些JS可以調(diào)用的API即JS bindings。
由于瀏覽器的存在，現(xiàn)在JS可以操作DOM和WEB API了，看起來(lái)是可以構(gòu)建用戶界面啦。 有一點(diǎn)需要提前講清楚，V8只有棧和堆，其他諸如事件循環(huán)，DOM，WEB API它一概不知。原因前面其實(shí)已經(jīng)講過(guò)了，因?yàn)閂8只負(fù)責(zé)JS代碼的編譯執(zhí)行，你給V8一段JS代碼，它就從頭到尾一口氣執(zhí)行下去，中間不會(huì)停止。
另外這里我還要繼續(xù)提一下，JS執(zhí)行棧和渲染線程是相互阻塞的。為什么呢？ 本質(zhì)上因?yàn)镴S太靈活了，它可以去獲取DOM中的諸如坐標(biāo)等信息。 如果兩者同時(shí)執(zhí)行，就有可能發(fā)生沖突，比如我先獲取了某一個(gè)DOM節(jié)點(diǎn)的x坐標(biāo)，下一時(shí)刻坐標(biāo)變了。 JS又用這個(gè)“舊的”坐標(biāo)進(jìn)行計(jì)算然后賦值給DOM，沖突便發(fā)生了。 解決沖突的方式有兩種：
- 限制JS的能力，你只能在某些時(shí)候使用某些API。 這種做法極其復(fù)雜，還會(huì)帶來(lái)很多使用不便。
- JS和渲染線程不同時(shí)執(zhí)行就好了，一種方法就是現(xiàn)在廣泛采用的相互阻塞。 實(shí)際上這也是目前瀏覽器廣泛采用的方式。
單線程 or 多線程 or 異步
前面提到了你給V8一段JS代碼，它就從頭到尾一口氣執(zhí)行下去，中間不會(huì)停止。 為什么不停止，可以設(shè)計(jì)成可停止么，就好像C語(yǔ)言一樣？
假設(shè)我們需要獲取用戶信息，獲取用戶的文章，獲取用的朋友。
單線程無(wú)異步
由于是單線程無(wú)異步，因此我們?nèi)齻€(gè)接口需要采用同步方式。
- fetchUserInfoSync().then(doSomethingA); // 1s
- fetchMyArcticlesSync().then(doSomethingB);// 3s
- fetchMyFriendsSync().then(doSomethingC);// 2s
由于上面三個(gè)請(qǐng)求都是同步執(zhí)行的，因此上面的代碼會(huì)先執(zhí)行fetchUserInfoSync，一秒之后執(zhí)行fetchMyArcticlesSync，再過(guò)三秒執(zhí)行fetchMyFriendsSync。 最可怕的是我們剛才說(shuō)了JS執(zhí)行棧和渲染線程是相互阻塞的。 因此用戶就在這期間根本無(wú)法操作，界面無(wú)法響應(yīng)，這顯然是無(wú)法接受的。
多線程無(wú)異步
由于是多線程無(wú)異步，雖然我們?nèi)齻€(gè)接口仍然需要采用同步方式，但是我們可以將代碼分別在多個(gè)線程執(zhí)行，比如我們將這段代碼放在三個(gè)線程中執(zhí)行。
線程一：
- fetchUserInfoSync().then(doSomethingA); // 1s
線程二：
- fetchMyArcticlesSync().then(doSomethingB); // 3s
線程三：
- fetchMyFriendsSync().then(doSomethingC); // 2s
由于三塊代碼同時(shí)執(zhí)行，因此總的時(shí)間最理想的情況下取決與最慢的時(shí)間，也就是3s，這一點(diǎn)和使用異步的方式是一樣的（當(dāng)然前提是請(qǐng)求之間無(wú)依賴）。為什么要說(shuō)最理想呢？由于三個(gè)線程都可以對(duì)DOM和堆內(nèi)存進(jìn)行訪問(wèn)，因此很有可能會(huì)沖突，沖突的原因和我上面提到的JS線程和渲染線程的沖突的原因沒有什么本質(zhì)不同。因此最理想情況沒有任何沖突的話是3s，但是如果有沖突，我們就需要借助于諸如鎖來(lái)解決，這樣時(shí)間就有可能高于3s了。 相應(yīng)地編程模型也會(huì)更復(fù)雜，處理過(guò)鎖的程序員應(yīng)該會(huì)感同身受。
單線程 + 異步
如果還是使用單線程，改成異步是不是會(huì)好點(diǎn)？問(wèn)題的是關(guān)鍵是如何實(shí)現(xiàn)異步呢？這就是我們要講的主題 - 事件循環(huán)。
事件循環(huán)究竟是怎么實(shí)現(xiàn)異步的？
我們知道瀏覽器中JS線程只有一個(gè)，如果沒有事件循環(huán)，就會(huì)造成一個(gè)問(wèn)題。 即如果JS發(fā)起了一個(gè)異步IO請(qǐng)求，在等待結(jié)果返回的這個(gè)時(shí)間段，后面的代碼都會(huì)被阻塞。 我們知道JS主線程和渲染進(jìn)程是相互阻塞的，因此這就會(huì)造成瀏覽器假死。 如何解決這個(gè)問(wèn)題？ 一個(gè)有效的辦法就是我們這節(jié)要講的事件循環(huán)。
其實(shí)事件循環(huán)就是用來(lái)做調(diào)度的，瀏覽器和NodeJS中的事件循壞就好像操作系統(tǒng)的調(diào)度器一樣。操作系統(tǒng)的調(diào)度器決定何時(shí)將什么資源分配給誰(shuí)。對(duì)于有線程模型的計(jì)算機(jī)，那么操作系統(tǒng)執(zhí)行代碼的最小單位就是線程，資源分配的最小單位就是進(jìn)程，代碼執(zhí)行的過(guò)程由操作系統(tǒng)進(jìn)行調(diào)度，整個(gè)調(diào)度過(guò)程非常復(fù)雜。 我們知道現(xiàn)在很多電腦都是多核的，為了讓多個(gè)core同時(shí)發(fā)揮作用，即沒有一個(gè)core是特別閑置的，也沒有一個(gè)core是特別累的。操作系統(tǒng)的調(diào)度器會(huì)進(jìn)行某一種神秘算法，從而保證每一個(gè)core都可以分配到任務(wù)。 這也就是我們使用NodeJS做集群的時(shí)候，Worker節(jié)點(diǎn)數(shù)量通常設(shè)置為core的數(shù)量的原因，調(diào)度器會(huì)盡量將每一個(gè)Worker平均分配到每一個(gè)core，當(dāng)然這個(gè)過(guò)程并不是確定的，即不一定調(diào)度器是這么分配的，但是很多時(shí)候都會(huì)這樣。
了解了操作系統(tǒng)調(diào)度器的原理，我們不妨繼續(xù)回頭看一下事件循環(huán)。 事件循環(huán)本質(zhì)上也是做調(diào)度的，只不過(guò)調(diào)度的對(duì)象變成了JS的執(zhí)行。事件循環(huán)決定了V8什么時(shí)候執(zhí)行什么代碼。V8只是負(fù)責(zé)JS代碼的解析和執(zhí)行，其他它一概不知。瀏覽器或者NodeJS中觸發(fā)事件之后，到事件的監(jiān)聽函數(shù)被V8執(zhí)行這個(gè)時(shí)間段的所有工作都是事件循環(huán)在起作用。
我們來(lái)小結(jié)一下：
- 對(duì)于V8來(lái)說(shuō)，它有：
- 調(diào)用棧（call stack）
這里的單線程指的是只有一個(gè)call stack。只有一個(gè)call stack 意味著同一時(shí)間只能執(zhí)行一段代碼。
- 堆（heap）
- 對(duì)于瀏覽器運(yùn)行環(huán)境來(lái)說(shuō)：
- WEB API
- DOM API
- 任務(wù)隊(duì)列
事件來(lái)觸發(fā)事件循環(huán)進(jìn)行流動(dòng)
以如下代碼為例：
- function c() {}
- function b() {
- c();
- }
- function a() {
- setTimeout(b, 2000)
- }
- a();
執(zhí)行過(guò)程是這樣的：
(在線觀看)
因此事件循環(huán)之所以可以實(shí)現(xiàn)異步，是因?yàn)榕龅疆惒綀?zhí)行的代碼“比如fetch，setTimeout”，瀏覽器會(huì)將用戶注冊(cè)的回調(diào)函數(shù)存起來(lái)，然后繼續(xù)執(zhí)行后面的代碼。等到未來(lái)某一個(gè)時(shí)刻，“異步任務(wù)”完成了，會(huì)觸發(fā)一個(gè)事件，瀏覽器會(huì)將“任務(wù)的詳細(xì)信息”作為參數(shù)傳遞給之前用戶綁定的回調(diào)函數(shù)。具體來(lái)說(shuō)，就是將用戶綁定的回調(diào)函數(shù)推入瀏覽器的執(zhí)行棧。
但并不是說(shuō)隨便推入的，只有瀏覽器將當(dāng)然要執(zhí)行的JS腳本“一口氣”執(zhí)行完，要”換氣“的時(shí)候才會(huì)去檢查有沒有要被處理的“消息”。
如果于則將對(duì)應(yīng)消息綁定的回調(diào)函數(shù)推入棧。當(dāng)然如果沒有綁定事件，這個(gè)事件消息實(shí)際上會(huì)被丟棄，不被處理。比如用戶觸發(fā)了一個(gè)click事件，但是用戶沒有綁定click事件的監(jiān)聽函數(shù)，那么實(shí)際上這個(gè)事件會(huì)被丟棄掉。
我們來(lái)看一下加入用戶交互之后是什么樣的，拿點(diǎn)擊事件來(lái)說(shuō)：
- $.on('button', 'click', function onClick() {
- setTimeout(function timer() {
- console.log('You clicked the button!');
- }, 2000);
- });
- console.log("Hi!");
- setTimeout(function timeout() {
- console.log("Click the button!");
- }, 5000);
- console.log("Welcome to loupe.");
上述代碼每次點(diǎn)擊按鈕，都會(huì)發(fā)送一個(gè)事件，由于我們綁定了一個(gè)監(jiān)聽函數(shù)。因此每次點(diǎn)擊，都會(huì)有一個(gè)點(diǎn)擊事件的消息產(chǎn)生，瀏覽器會(huì)在“空閑的時(shí)候”對(duì)應(yīng)將用戶綁定的事件處理函數(shù)推入棧中執(zhí)行。
偽代碼:
- while (true) {
- if (queue.length > 0) {
- queue.processNextMessage()
- }
- }
動(dòng)畫演示：
(在線觀看)
加入宏任務(wù)&微任務(wù)
我們來(lái)看一個(gè)更復(fù)制的例子感受一下。
- console.log(1)
- setTimeout(() => {
- console.log(2)
- }, 0)
- Promise.resolve().then(() => {
- return console.log(3)
- }).then(() => {
- console.log(4)
- })
- console.log(5)
上面的代碼會(huì)輸出：1、5、3、4、2。 如果你想要非常嚴(yán)謹(jǐn)?shù)慕忉尶梢詤⒖?whatwg 對(duì)其進(jìn)行的描述 -event-loop-processing-model。
下面我會(huì)對(duì)其進(jìn)行一個(gè)簡(jiǎn)單的解釋。
- 瀏覽器首先執(zhí)行宏任務(wù)，也就是我們script（僅僅執(zhí)行一次）
- 完成之后檢查是否存在微任務(wù)，然后不停執(zhí)行，直到清空隊(duì)列
- 執(zhí)行宏任務(wù)
其中：
宏任務(wù)主要包含：setTimeout、setInterval、setImmediate、I/O、UI交互事件
微任務(wù)主要包含：Promise、process.nextTick、MutaionObserver 等
有了這個(gè)知識(shí)，我們不難得出上面代碼的輸出結(jié)果。
由此我們可以看出，宏任務(wù)&微任務(wù)只是實(shí)現(xiàn)異步過(guò)程中，我們對(duì)于信號(hào)的處理順序不同而已。如果我們不加區(qū)分，全部放到一個(gè)隊(duì)列，就不會(huì)有宏任務(wù)&微任務(wù)。這種人為劃分優(yōu)先級(jí)的過(guò)程，在某些時(shí)候非常有用。
加入執(zhí)行上下文棧
說(shuō)到執(zhí)行上下文，就不得不提到瀏覽器執(zhí)行JS函數(shù)其實(shí)是分兩個(gè)過(guò)程的。一個(gè)是創(chuàng)建階段Creation Phase,一個(gè)是執(zhí)行階段Execution Phase。
同執(zhí)行棧一樣，瀏覽器每遇到一個(gè)函數(shù)，也會(huì)將當(dāng)前函數(shù)的執(zhí)行上下文棧推入棧頂。
舉個(gè)例子：
- function a(num) {
- function b(num) {
- function c(num) {
- const n = 3
- console.log(num + n)
- }
- c(num);
- }
- b(num);
- }
- a(1);
遇到上面的代碼。 首先會(huì)將a的壓入執(zhí)行棧，我們開始進(jìn)行創(chuàng)建階段Creation Phase， 將a的執(zhí)行上下文壓入棧。然后初始化a的執(zhí)行上下文，分別是VO，ScopeChain（VO chain）和 This。 從這里我們也可以看出，this其實(shí)是動(dòng)態(tài)決定的。VO指的是variables, functions 和 arguments。 并且執(zhí)行上下文棧也會(huì)同步隨著執(zhí)行棧的銷毀而銷毀。
偽代碼表示：
- const EC = {
- 'scopeChain': { },
- 'variableObject': { },
- 'this': { }
- }
我們來(lái)重點(diǎn)看一下ScopeChain(VO chain)。如上圖的執(zhí)行上下文大概長(zhǎng)這個(gè)樣子，偽代碼：
- global.VO = {
- a: pointer to a(),
- scopeChain: [global.VO]
- }
- a.VO = {
- b: pointer to b(),
- arguments: {
- 0: 1
- },
- scopeChain: [a.VO, global.VO]
- }
- b.VO = {
- c: pointer to c(),
- arguments: {
- 0: 1
- },
- scopeChain: [b.VO, a.VO, global.VO]
- }
- c.VO = {
- arguments: {
- 0: 1
- },
- n: 3
- scopeChain: [c.VO, b.VO, a.VO, global.VO]
- }
引擎查找變量的時(shí)候，會(huì)先從VOC開始找，找不到會(huì)繼續(xù)去VOB...，直到GlobalVO，如果GlobalVO也找不到會(huì)返回Referrence Error，整個(gè)過(guò)程類似原型鏈的查找。
值得一提的是，JS是詞法作用域，也就是靜態(tài)作用域。換句話說(shuō)就是作用域取決于代碼定義的位置，而不是執(zhí)行的位置，這也就是閉包產(chǎn)生的本質(zhì)原因。 如果上面的代碼改造成下面的：
- function c() {}
- function b() {}
- function a() {}
- a()
- b()
- c()
或者這種：
- function c() {}
- function b() {
- c();
- }
- function a() {
- b();
- }
- a();
其執(zhí)行上下文棧雖然都是一樣的，但是其對(duì)應(yīng)的scopeChain則完全不同，因?yàn)楹瘮?shù)定義的位置發(fā)生了變化。拿上面的代碼片段來(lái)說(shuō),c.VO會(huì)變成這樣：
- c.VO = {
- scopeChain: [c.VO, global.VO]
- }
也就是說(shuō)其再也無(wú)法獲取到a和b中的VO了。
總結(jié)
通過(guò)這篇文章，希望你對(duì)單線程，多線程，異步，事件循環(huán)，事件驅(qū)動(dòng)等知識(shí)點(diǎn)有了更深的理解和感悟。除了這些大的層面，我們還從執(zhí)行棧，執(zhí)行上下文棧角度講解了我們代碼是如何被瀏覽器運(yùn)行的，我們順便還解釋了作用域和閉包產(chǎn)生的本質(zhì)原因。
最后我總結(jié)了一個(gè)瀏覽器運(yùn)行代碼的整體原理圖，希望對(duì)你有幫助：
下一節(jié)瀏覽器的事件循環(huán)和NodeJS的事件循環(huán)有什么不同, 敬請(qǐng)期待～
