摘要：事件循環(huán)持續(xù)運行，直到清空列隊的任務。在執(zhí)行期間，瀏覽器可能更新渲染。線索可能會發(fā)生多次。由于冒泡，函數(shù)再一次執(zhí)行。這意味著隊列不會在事件回調之間處理，而是在它們之后處理。當觸發(fā)成功事件時，相關的對象在事件之后轉為非激活狀態(tài)第四步。

一直想對異步處理做一個研究，在查閱資料時發(fā)現(xiàn)了這篇文章，非常深入的解釋了事件循環(huán)中重的任務隊列。原文中有代碼執(zhí)行工具，強烈建議自己執(zhí)行一下查看結果，深入體會task執(zhí)行順序。
建議看這篇譯文之前先看這篇全面講解事件循環(huán)的文章：https://mp.weixin.qq.com/s/vI...
翻譯參考了這篇文章的部分內容：https://juejin.im/entry/55dbd...

原文地址：Tasks, microtasks, queues and schedules

當我告訴我的同事 Matt Gaunt 我想寫一篇關于mircrotask、queueing和瀏覽器的Event Loop的文章。他說：“我實話跟你說吧，我是不會看的?！?好吧，無論如何我已經(jīng)寫完了，那么我們坐下來一起看看，好吧？

如果你更喜歡視頻，Philip Roberts 在 JSConf 上就事件循環(huán)有一個很棒的演講——沒有講 microtasks，不過很好的介紹了其它概念。好，繼續(xù)！

思考下面 JavaScript 代碼：

console.log("script start");

setTimeout(function() {
  console.log("setTimeout");
}, 0);

Promise.resolve().then(function() {
  console.log("promise1");
}).then(function() {
  console.log("promise2");
});

console.log("script end");

控制臺上的輸出順序是怎樣的呢？

正確的答案是：

script start

script end

promise1

promise2

setTimeout

但是由于瀏覽器實現(xiàn)支持不同導致結果也不一致。

Microsoft Edge, Firefox 40, iOS Safari 及桌面 Safari 8.0.8 在 promise1 和 promise2 之前打印 setTimeout -- 這似乎是瀏覽器廠商相互競爭導致的實現(xiàn)不同。但是很奇怪的是，F(xiàn)irefox 39 和 Safari 8.0.7 竟然結果都是對的（一致的）。

要想弄明白這些，你需要知道Event Loop是如何處理 tasks 和 microtasks的。如果你是第一次接觸它，需要花些功夫才能弄明白。深呼吸。。。

每個線程都有自己的事件循環(huán)，所以每個 web worker 都有自己的事件循環(huán)，因此web worker才可以獨立執(zhí)行。而來自同域的所有窗口共享一個事件循環(huán)，所以它們可以同步地通信。事件循環(huán)持續(xù)運行，直到清空 tasks 列隊的任務。事件循環(huán)包括多種任務源，事件循環(huán)執(zhí)行時會訪問這些任務源，這樣就確定了各個任務源的執(zhí)行順序（IndexedDB 等規(guī)范定義了自己的任務源和執(zhí)行順序），但瀏覽器可以在每次循環(huán)中選擇從哪個任務源去執(zhí)行一個任務。這允許瀏覽器優(yōu)先考慮性能敏感的任務，例如用戶輸入。Ok ok, 留下來陪我坐會兒……

Tasks 被放到任務源中，瀏覽器內部執(zhí)行轉移到JavaScript/DOM領域，并且確保這些 tasks按序執(zhí)行。在tasks執(zhí)行期間，瀏覽器可能更新渲染。來自鼠標點擊的事件回調需要安排一個task，解析HTML和setTimeout同樣需要。

setTimeout延遲給定的時間，然后為它的回調安排一個新的task。這就是為什么 setTimeout在 script end 之后打?。簊cript end 在第一個task 內，setTimeout 在另一個 task 內。好了，我們快講完了，剩下一點我需要你們堅持下……

Mircotasks隊列通常用于存放一些任務，這些任務應該在正在執(zhí)行的腳本之后立即執(zhí)行，比如對一批動作作出反應，或者操作異步執(zhí)行避免創(chuàng)建整個新任務造成的性能浪費。 只要沒有其他JavaScript代碼在執(zhí)行中，并且在每個task隊列的任務結束時，microtask隊列就會被處理。在處理 microtasks 隊列期間，新添加到 microtasks 隊列的任務也會被執(zhí)行。 microtasks 包括 MutationObserver callbacks。例如上面的例子中的 promise的callback。

一個settled狀態(tài)的promise（直接調用resolve或者reject）或者已經(jīng)變成settled狀態(tài)(異步請求被settled)的promise，會立刻將它的callback（then）放到microtask隊列里面。這就能保證promise的回調是異步的，即便promise已經(jīng)變?yōu)閟ettled狀態(tài)。因此一個已settled的promise調用.then(yey,nay)時將立即把一個microtask任務加入microtasks任務隊列。這就是為什么 promise1 和 promise2 在 script end 之后打印，因為正在運行的代碼必須在處理 microtasks 之前完成。promise1 和 promise2 在 setTimeout 之前打印，因為 microtasks 總是在下一個 task 之前執(zhí)行。

好，一步一步的運行：

console.log("script start");

setTimeout(function() {
  console.log("setTimeout");
}, 0);

Promise.resolve().then(function() {
  console.log("promise1");
}).then(function() {
  console.log("promise2");
});

沒錯，就是上面這個，我做了一個 step-by-step 動畫圖解。你周六是怎么過的？和朋友們一起出去玩？我沒有出去。嗯，如果搞不明白我的令人驚嘆的UI設計界面，點擊上面的箭頭試試。

瀏覽器實現(xiàn)差異

一些瀏覽器的打印結果：

script start
script end
setTimeout
promise1
promise2

在 setTimeout 之后運行 promise 的回調，就好像將 promise 的回調當作一個新的 task 而不是 microtask。

這多少情有可原，因為 promise 來自 ECMAScript 規(guī)范而不是 HTML 規(guī)范。ECAMScript 有一個概念 job，和 microtask 相似，但是兩者的關系在郵件列表討論中沒有明確。不過，一般共識是 promise 應該是 microtask 隊列的一部分，并且有充足的理由。

將 promise當作task（macrotask）會帶來一些性能問題，因為回調沒有必要因為task相關的事（比如渲染）而延遲執(zhí)行。與其它 task 來源交互時它也產(chǎn)生不確定性，也會打斷與其它 API 的交互，不過后面再細說。

我提交了一條 Edge 反饋，它錯誤地將 promises 當作 task。WebKit nightly 做對了，所以我認為 Safari 最終會修復，而 Firefox 43 似乎已經(jīng)修復。

有趣的是 Safari 和 Firefox 發(fā)生了退化，而之前的版本是對的。我在想這是否只是巧合。

動手試一試是一種辦法，查看相對于promise和setTimeout如何打印，盡管這取決于實現(xiàn)是否正確。

一種方法是查看規(guī)范：
將一個 task 加入隊列： step 14 of setTimeout
將 microtask 加入隊列：step 5 of queuing a mutation record

如上所述，ECMAScript 將 microtask 稱為 job：
調用 EnqueueJob 將一個 microtask 加入隊列：step 8.a of PerformPromiseThen

現(xiàn)在，讓我們看一個更復雜的例子。一個有心的學徒 ：“但是他們還沒有準備好”。別管他，你已經(jīng)準備好了，讓我們開始……

在發(fā)出這篇文章之前，我犯過一個錯誤。下面是一段html代碼：

給出下面的JS代碼，如果click div.inner將會打印出什么呢？

// Let"s get hold of those elements
var outer = document.querySelector(".outer");
var inner = document.querySelector(".inner");

// Let"s listen for attribute changes on the
// outer element
new MutationObserver(function() {
  console.log("mutate");
}).observe(outer, {
  attributes: true
});

// Here"s a click listener…
function onClick() {
  console.log("click");

  setTimeout(function() {
    console.log("timeout");
  }, 0);

  Promise.resolve().then(function() {
    console.log("promise");
  });

  outer.setAttribute("data-random", Math.random());
}

// …which we"ll attach to both elements
inner.addEventListener("click", onClick);
outer.addEventListener("click", onClick);

繼續(xù)，在查看答案之前先試一試。 線索：logs可能會發(fā)生多次。

點擊inner區(qū)域觸發(fā)click事件：

click div.inner :

click
promise
mutate
click
promise
mutate
timeout
timeout

click div.outer :

click
promise
mutate
timeout

和你猜想的有不同嗎？如果是，你得到的結果可能也是正確的。不幸的是，瀏覽器實現(xiàn)并不統(tǒng)一，下面是各個瀏覽器下測試結果：

觸發(fā) click 事件是一個 task，Mutation observer 和 promise 的回調 加入microtask列隊，setTimeout 回調加入task列隊。因此運行過程如下：

點擊內部區(qū)域觸發(fā)內部區(qū)域點擊事件 -> 冒泡到外部區(qū)域 -> 觸發(fā)外部區(qū)域點擊事件
這里要注意一點： setTimeout 執(zhí)行時機在冒泡之后，因為也是在microtask之后，準確的說是在最后的時機執(zhí)行了。

堆棧為空之后將會執(zhí)行microtasks里面的任務。

由于冒泡， click函數(shù)再一次執(zhí)行。

最后將執(zhí)行setTimeout。

所以 Chrome 是對的。對我來說新發(fā)現(xiàn)是，microtasks 在回調之后運行（只要沒有其它的 Javascript 在運行），我原以為它只能在一個task 的末尾執(zhí)行。這個規(guī)則來自 HTML 規(guī)范，調用一個回調：

If the stack of script settings objects is now empty, perform a microtask checkpoint

— HTML: Cleaning up after a callback step 3

一個 microtask checkpoint 逐個檢查 microtask隊列，除非我們已經(jīng)在處理一個 microtask 隊列。類似地，ECMAScript 規(guī)范這么說 jobs：

Execution of a Job can be initiated only when there is no running execution context and the execution context stack is empty…

ECMAScript: Jobs and Job Queues
盡管在 HTML 中"can be"變成了"must be"。

對于 mutation callbacks，F(xiàn)irefox 和 Safari 都正確地在內部區(qū)域和外部區(qū)域單擊事件之間執(zhí)行完畢，清空了microtask 隊列，但是 promises 列隊的處理看起來和chrome不一樣。這多少情有可原，因為 jobs 和 microtasks 的關系不清楚，但是我仍然期望在事件回調之間處理。Firefox ticket. Safari ticket.

對于 Edge，我們已經(jīng)看到它錯誤的將 promises 當作 task，它也沒有在單擊回調之間清空 microtask 隊列，而是在所有單擊回調執(zhí)行完之后清空，于是總共只有一個 mutate 在兩個 click 之后打印。 Bug ticket.

仍然使用上面的例子，假如我們運行下面代碼會怎么樣：

inner.click();

跟之前一樣，它會觸發(fā) click 事件，不過是通過代碼而不是實際的交互動作。

下面是各個瀏覽器的運行情況：

我發(fā)誓我一直在Chrome 中得到不同的結果，我已經(jīng)更新了這個表許許多次了。我覺得我是錯誤地測試了Canary。假如你在 Chrome 中得到了不同的結果，請在評論中告訴我是哪個版本。

這里介紹了它是怎樣發(fā)生的：

將Run srcipt加入Tasks隊列，將inner.click加入執(zhí)行堆棧：

執(zhí)行click函數(shù)：

按順序執(zhí)行，分別將setTimeout加入Tasks隊列，將Promise MultationObserver加入microtasks隊列：

click函數(shù)執(zhí)行完畢之后，我們沒有去處理microtasks隊列的任務，因為此時堆棧不為空：

我們不能將 MultationObserver加入microtasks隊列，因為有一個等待處理的 MultationObserver：

現(xiàn)在堆棧為空了，我們可以處理microtasks隊列的任務了：

最終結果：

通過對比事件觸發(fā)，我們要注意兩個地方：JS stack是否是空的決定了microtasks隊列里任務的執(zhí)行；microtasks隊列里不能同時有多個MultationObserver。

正確的順序是：click, click, promise, mutate, promise, timeout, timeout，似乎 Chrome 是對的。

在每個listerner callback被調用之后：

If the stack of script settings objects is now empty，perform a microtask checkpoint.

— HTML: 回調之后的清理第三步

之前，這意味著 microtasks 在事件回調之間運行，但是現(xiàn)在.click()讓事件同步觸發(fā)，因此調用.click（）的腳本仍處于回調之間的堆棧中。上面的規(guī)則確保了 microtasks 不會中斷正在執(zhí)行的JS代碼。這意味著 microtasks 隊列不會在事件回調之間處理，而是在它們之后處理。

重要，它會在偏角處咬你（疼）。我就遇到了這個問題，我在嘗試為IndexedDB創(chuàng)建一個使用promises而不是奇怪的IDBRequest對象的簡單包裝庫時遇到了此問題。它讓 IDB 用起來很有趣。

當 IDB 觸發(fā)成功事件時，相關的 transaction 對象在事件之后轉為非激活狀態(tài)（第四步）。如果我創(chuàng)建的 promise 在這個事件發(fā)生時被resolved，回調應當在第四步之前執(zhí)行，這時這個對象仍然是激活狀態(tài)。但是在 Chrome 之外的瀏覽器中不是這樣，導致這個庫有些無用。

實際上你可以在 Firefox 中解決這個問題，因為 promise polyfills 如 es6-promise 使用 mutation observers 執(zhí)行回調，它正確地使用了 microtasks。而它在 Safari 下似乎存在競態(tài)條件，不過這可能是因為他們糟糕的 IDB 實現(xiàn)。不幸的是 IE/Edge 不一致，因為 mutation 事件不在回調之后處理。

希望不久我們能看到一些互通性。

總結：

tasks 按序執(zhí)行，瀏覽器會在 tasks 之間執(zhí)行渲染。

microtasks 按序執(zhí)行，在下面情況時執(zhí)行：

在每個回調之后，只要沒有其它代碼正在運行。

在每個 task 的末尾。

希望你現(xiàn)在明白了事件循環(huán)，或者至少得到一個借口出去走一走，躺一躺。

呃，還有人在嗎？Hello？Hello？

感謝 Anne van Kesteren, Domenic Denicola, Brian Kardell 和 Matt Gaunt 校對和修正。是的，Matt 最后還是看了此文，我不必把他整成發(fā)條橙了。

1.microtask隊列就會被處理的時機

（1）只要沒有其他JavaScript代碼在執(zhí)行中，
（2）并且在每個task隊列的任務結束時，

  microtask隊列就會被處理。
  

也就是說可以在執(zhí)行一個task之后連續(xù)執(zhí)行多個microtask。

2. promise相關

（1）promise一旦創(chuàng)建就會馬上執(zhí)行
（2）當狀態(tài)變?yōu)閟ettled的時候，callback才會被加入microtask 隊列

所以要注意promise創(chuàng)建和callback被執(zhí)行的時機。