Eventloop
要說Eventloop,就不得不提瀏覽器進(jìn)程和JavaScript單線程的三兩事。
瀏覽器的工作原理,這里不提了,細(xì)摳的話很復(fù)雜,這里只說瀏覽器進(jìn)程的組成名扛。
瀏覽器進(jìn)程
簡單了解下瀏覽器進(jìn)程,但這不是本文重點,本文重點是: 瀏覽器渲染進(jìn)程（內(nèi)核）,也叫 瀏覽器內(nèi)核進(jìn)程
- Browser進(jìn)程: 瀏覽器的主進(jìn)程,負(fù)責(zé)協(xié)調(diào)助析、主控,只有一個
- 第三方插件進(jìn)程: 每種類型的插件對應(yīng)一個進(jìn)程综芥，僅當(dāng)使用該插件時才創(chuàng)建
- GPU進(jìn)程：最多一個果港，用于3D繪制
- 瀏覽器渲染進(jìn)程（內(nèi)核）：默認(rèn)每個Tab頁面一個進(jìn)程辩块，互不影響烙常，控制頁面渲染，腳本執(zhí)行召耘，事件處理等（有時候會優(yōu)化百炬，如多個空白tab會合并成一個進(jìn)程）
以下是本文重點
瀏覽器內(nèi)核進(jìn)程中主要有5大常駐線程,他們各自有分工:
- GUI渲染線程：負(fù)責(zé)頁面渲染
- JS引擎線程：主線程,執(zhí)行JavaScript腳本
- 事件觸發(fā)線程： 顧名思義
- 定時器線程：顧名思義
- 異步http請求線程： 顧名思義
大家都知道JavaScript是單線程腳本語言，為啥是單線程污它，有一定的歷史原因剖踊，也有專業(yè)性的考量，感興趣的話推薦閱讀 阮一峰 老師的 JavaScript 運行機(jī)制詳解：再談Event Loop
上面列出來的5大常駐線程衫贬，其中GUI渲染線程和JS引擎線程是“相愛相殺”的德澈，JS引擎線程在執(zhí)行過程中會阻塞GUI渲染線程進(jìn)行頁面渲染，導(dǎo)致頁面卡頓固惯。
如果你說感覺不到梆造，那只能說卡頓時間長短的問題，可以試試這個,先在瀏覽器打開看看葬毫，再把while(true) {}注釋掉刷新試試澳窑。
test.html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
<script>
while(true) {}
</script>
</head>
<body>
這是測試GUI線程渲染結(jié)果顯示的內(nèi)容，很簡單供常，就一行文字而已摊聋。。栈暇。
</body>
</html>
這就是為什么在聊到頁面優(yōu)化的時候麻裁，有一項是： 把沒有上下文依賴的外部腳本引入放到</body>上一行的原因。
除了GUI渲染線程和JS引擎線程之外源祈，剩下的3個線程：事件觸發(fā)線程煎源、定時器線程、異步http請求線程香缺，都是用來處理異步邏輯的手销。
任務(wù)隊列（消息隊列）
除了這些線程之外，還有一個消息隊列（任務(wù)隊列）图张，任務(wù)對列不是線程锋拖，而是一個存儲結(jié)構(gòu)。
下面說的內(nèi)容可能會有偏差祸轮，因為我查詢到的有各個版本的說法兽埃，難以總結(jié)，大致有個概念就行
任務(wù)對列分為2種類型：
- 宏任務(wù)隊列: Task Queue(MacroTask Queue)适袜，可以有多個
- 微任務(wù)隊列: MicroTask Queue
異步代碼會根據(jù)類型分別丟到 宏任務(wù)隊列 和 微任務(wù)隊列 中處理柄错，下面是一些劃分(左邊是高優(yōu)先級):
- 宏任務(wù): setTimeout => setInterval => setImmediate(nodeJS) => I/O => UI Rendering
- 微任務(wù): process.nextTick(nodeJS) => Promise(Promise.then) => mutationObserver
EventLoop（事件循環(huán)）
當(dāng)JavaScrip會創(chuàng)建一個類似于while(true)的循環(huán)，不停地執(zhí)行,每當(dāng)JS主線程執(zhí)行完棧中同步代碼后，就會去任務(wù)隊列中讀取售貌，被讀取到主線程棧中的代碼一定是已經(jīng)執(zhí)行完成的異步代碼给猾，如果異步代碼還沒有完成，怎么繼續(xù)等待颂跨，直到完成后才會被讀取到主進(jìn)程中執(zhí)行敢伸，因為JavaScript單線程特性決定了它不可能等待不知道什么時候能完成的任務(wù)。
其實上面都是概念性的內(nèi)容毫捣，其實本文的核心是想說一說 宏任務(wù)和微任務(wù) 的執(zhí)行順序。
案例
在面試題中經(jīng)常會看到類似于這樣的代碼帝际，來判斷輸出的順序蔓同，這里就借這個案例來摳一摳：
先別慌思考和運行，看看示例代碼塊下面的規(guī)則蹲诀，然后再去思考斑粱，寫出順序。
如果你都覺得這是小case脯爪，那么瀏覽器Tab右上角有個“叉號”则北， 請點一點；
如果你錯了痕慢，那么看看規(guī)則下方的分析吧尚揣。。掖举。
console.log('1');
setTimeout(function() {
console.log('2');
Promise.resolve().then(function() {
console.log('3');
})
new Promise(function(resolve) {
console.log('4');
resolve();
}).then(function() {
console.log('5')
Promise.resolve().then(function() {
console.log('14');
})
})
}, 100)
Promise.resolve().then(function() {
console.log('6');
})
new Promise(function(resolve) {
console.log('7');
resolve();
}).then(function() {
console.log('8')
Promise.resolve().then(function() {
console.log('15');
})
})
Promise.resolve().then(function() {
console.log('100');
})
setTimeout(function() {
console.log('9');
Promise.resolve().then(function() {
console.log('10');
})
new Promise(function(resolve) {
console.log('11');
resolve();
}).then(function() {
console.log('12')
})
}, 0)
console.log('13')
有以下幾個規(guī)則：
- JavaScript在執(zhí)行時快骗，遇到同步代碼就直接執(zhí)行，遇到異步代碼會分類：
- 宏任務(wù)丟到宏任務(wù)隊列塔次；
- 微任務(wù)丟到微任務(wù)隊列
- 宏任務(wù)優(yōu)先于微任務(wù)執(zhí)行（你可能會對這個規(guī)則有疑惑方篮，不急，往下看）
每個宏任務(wù)執(zhí)行完后執(zhí)行渲染（這是擴(kuò)展的励负，放這里純粹是防止忘記） - 繼續(xù)執(zhí)行下一個宏任務(wù)
- 重點：每個宏任務(wù)執(zhí)行完后藕溅，不會立即進(jìn)入渲染或進(jìn)入下一個宏任務(wù)，而是把在當(dāng)前宏任務(wù)執(zhí)行過程中產(chǎn)生的所有微任務(wù)執(zhí)行完后才會進(jìn)入下一步
執(zhí)行結(jié)果為：
1 // console.log('1')
7
13 // console.log('13')
6
8
100
15
// 以下為第二個setTimeout
9
11
10
12
// 以下為第一個setTimeout
2
4
3
5
14
分析
-
console.log('1')和console.log('13')是同步代碼继榆，輸出：1 => 13很好理解巾表，但是7為什么會在13之前輸出？
原因： 雖然 console.log('7') 是 new Promise的回調(diào)函數(shù)內(nèi)的略吨，但這里并不意味著它就是異步的攒发，可以想象一下這樣一個過程: new Promise(callback),而Promise的構(gòu)造函數(shù)是這樣的:
function Promise (cb) {
let resolve = function (data) { xxx }
typeof cb === 'function' && cb(resolve)
}
那么new Promise內(nèi)部就是同步執(zhí)行的，起碼按照目前的表現(xiàn)是可以這么猜測和解釋的晋南。
所以 輸出：1 => 7 => 13 就可以理解了惠猿。
接下來是
6 => 8 => 100的輸出的分析
疑惑： 規(guī)則里不是說了先執(zhí)行宏任務(wù)嗎？為什么不是先執(zhí)行setTimeout里的代碼？而是執(zhí)行微任務(wù)里的Promise.then?
其實這問題我也疑惑了挺久的偶妖，弄得一直搞不清到底誰先誰后姜凄，后來想到了原因。
原因： 因為代碼執(zhí)行的上下文就是被當(dāng)做一個最外層的宏任務(wù)趾访，而Promise.resolve().then(function() {console.log('6');})态秧、Promise.xxxx.then(function() {console.log('8');})以及Promise.resolve().then(function() {console.log('100');})外部沒有被屬于宏任務(wù)的代碼包裹，就說明屬于頂層宏任務(wù)的微任務(wù)扼鞋，所以會先執(zhí)行申鱼。再看看 15 和 8 都在一個Promise.then的代碼塊里穗泵，為什么會在 100 之后輸出也拜？
原因：
- 實際上 console.log('8') 和 Promise.resolve()確實是同步執(zhí)行的
- 但遇到了 .then，發(fā)現(xiàn)這是一個微任務(wù)钾菊，所以又把 console.log('15') 丟到了微任務(wù)隊列中
- 雖然這是一個異步溃槐，但根據(jù)規(guī)則同一個宏任務(wù)中的微任務(wù)會被等待到執(zhí)行完匣砖，所以 console.log('15')是一定會被在下一個宏任務(wù)之前被執(zhí)行的。
但我們不要忘記了昏滴，隊列的數(shù)據(jù)結(jié)構(gòu)是 先進(jìn)先出 的猴鲫，console.log('8') 和 console.log('100')由于被先丟到微任務(wù)隊列中，所以會先執(zhí)行谣殊，console.log('15') 就會后執(zhí)行拂共。
new Promise(function(resolve) {
console.log('7');
resolve();
}).then(function() {
console.log('8')
Promise.resolve().then(function() {
console.log('15');
})
})
綜合以上分析那么下面兩個定時器分別按順序輸出:
9 => 11 =>10 =>12和
2 => 4 =>3 => 5 =>14
就順理成章了還有個問題，不是 2 => 4 =>3 => 5 =>14 應(yīng)該被先輸出嗎姻几，為什么反了匣缘？
原因： 示例代碼里其實有一個坑。鲜棠。肌厨。兩個定時器的延遲時間不同，第一個定時器是 100ms豁陆，而第二個定時器是 0ms柑爸，是立即執(zhí)行的。
新的疑惑： 雖然兩個定時器的延遲時間不同盒音，但是第一個定時器被先添加到宏任務(wù)隊列中表鳍，按照隊列先進(jìn)先出規(guī)則，豈不是自己打臉了祥诽？
原因： 這些異步代碼是通過EventLoop不停地輪詢隊列譬圣，然后添加到主線程中執(zhí)行的。
但是有一個前提雄坪，這個前提在上面介紹EventLoop已經(jīng)加粗顯示了：
被讀取到主線程棧中的代碼一定是已經(jīng)執(zhí)行完成的異步代碼
注意已經(jīng)執(zhí)行完成這6個字厘熟，因為第二個定時器先執(zhí)行完，所以EventLoop先發(fā)現(xiàn)了它，所以它被先取到主線程中執(zhí)行绳姨。
這樣疑問就解決了登澜。。飘庄。
