JavaScript 事件循環中微任務和宏任務有什么區別，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。
事件循環：微任務和宏任務
瀏覽器中 JavaScript 的執行流程和 Node.js 中的流程都是基于 事件循環 的。
理解事件循環的工作方式對于代碼優化很重要，有時對于正確的架構也很重要。
在本章中，我們首先介紹有關事件循環工作方式的理論細節，然后介紹該知識的實際應用。
事件循環
事件循環 的概念非常簡單。它是一個在 JavaScript 引擎等待任務，執行任務和進入休眠狀態等待更多任務這幾個狀態之間轉換的無限循環。
引擎的一般算法：
1.當有任務時：
從最先進入的任務開始執行。
2.休眠直到出現任務，然后轉到第 1 步。
當我們瀏覽一個網頁時就是上述這種形式。JavaScript 引擎大多數時候不執行任何操作，它僅在腳本/處理程序/事件激活時執行。
任務示例：
當外部腳本<script src="..."> 加載完成時，任務就是執行它。
當用戶移動鼠標時，任務就是派生出 mousemove 事件和執行處理程序。
當安排的（scheduled）setTimeout 時間到達時，任務就是執行其回調。
……諸如此類。
設置任務 —— 引擎處理它們 —— 然后等待更多任務(即休眠，幾乎不消耗 CPU 資源)。
一個任務到來時，引擎可能正處于繁忙狀態，那么這個任務就會被排入隊列。
多個任務組成了一個隊列，即所謂的“宏任務隊列”(v8 術語)：
例如，當引擎正在忙于執行一段 script 時，用戶可能會移動鼠標而產生 mousemove 事件，setTimeout 或許也剛好到期，以及其他任務，這些任務組成了一個隊列，如上圖所示。
隊列中的任務基于“先進先出”的原則執行。當瀏覽器引擎執行完 script 后，它會處理 mousemove 事件，然后處理 setTimeout 處理程序，依此類推。
到目前為止，很簡單，對吧?
兩個細節：
鴻蒙官方戰略合作共建——HarmonyOS技術社區
引擎執行任務時永遠不會進行渲染(render)。如果任務執行需要很長一段時間也沒關系。僅在任務完成后才會繪制對 DOM 的更改。
如果一項任務執行花費的時間過長，瀏覽器將無法執行其他任務，例如處理用戶事件。因此，在一定時間后，瀏覽器會拋出一個如“頁面未響應”之類的警報，建議你終止這個任務。這種情況常發生在有大量復雜的計算或導致死循環的程序錯誤時。
以上是理論知識?，F在，讓我們來看看如何應用這些知識。
用例 1：拆分 CPU 過載任務
假設我們有一個 CPU 過載任務。
例如，語法高亮(用來給本頁面中的示例代碼著色)是相當耗費 CPU 資源的任務。為了高亮顯示代碼，它執行分析，創建很多著了色的元素，然后將它們添加到文檔中 —— 對于文本量大的文檔來說，需要耗費很長時間。
當引擎忙于語法高亮時，它就無法處理其他 DOM 相關的工作，例如處理用戶事件等。它甚至可能會導致瀏覽器“中斷(hiccup)”甚至“掛起(hang)”一段時間，這是不可接受的。
我們可以通過將大任務拆分成多個小任務來避免這個問題。高亮顯示前 100 行，然后使用 setTimeout(延時參數為 0)來安排(schedule)后 100 行的高亮顯示，依此類推。
為了演示這種方法，簡單起見，讓我們寫一個從 1 數到 1000000000 的函數，而不寫文本高亮。
如果你運行下面這段代碼，你會看到引擎會“掛起”一段時間。對于服務端 JS 來說這顯而易見，并且如果你在瀏覽器中運行它，嘗試點擊頁面上其他按鈕時，你會發現在計數結束之前不會處理其他事件。
let i = 0; let start = Date.now(); function count() { // 做一個繁重的任務 for (let j = 0; j < 1e9; j++) { i++; } alert("Done in " + (Date.now() - start) + 'ms'); } count();瀏覽器甚至可能會顯示一個“腳本執行時間過長”的警告。
讓我們使用嵌套的 setTimeout 調用來拆分這個任務：
let i = 0; let start = Date.now(); function count() { // 做繁重的任務的一部分 (*) do { i++; } while (i % 1e6 != 0); if (i == 1e9) { alert("Done in " + (Date.now() - start) + 'ms'); } else { setTimeout(count); // 安排（schedule）新的調用 (**) } } count();現在，瀏覽器界面在“計數”過程中可以正常使用。
單次執行 count 會完成工作 (*) 的一部分，然后根據需要重新安排(schedule)自身的執行 (**)：
鴻蒙官方戰略合作共建——HarmonyOS技術社區
首先執行計數：i=1...1000000。
然后執行計數：i=1000001..2000000。
……以此類推。
現在，如果在引擎忙于執行第一部分時出現了一個新的副任務(例如 onclick 事件)，則該任務會被排入隊列，然后在第一部分執行結束時，并在下一部分開始執行前，會執行該副任務。周期性地在兩次 count 執行期間返回事件循環，這為 JavaScript 引擎提供了足夠的“空氣”來執行其他操作，以響應其他的用戶行為。
值得注意的是這兩種變體 —— 是否使用了 setTimeout 對任務進行拆分 —— 在執行速度上是相當的。在執行計數的總耗時上沒有多少差異。
為了使兩者耗時更接近，讓我們來做一個改進。
我們將要把調度(scheduling)移動到 count() 的開頭：
let i = 0; let start = Date.now(); function count() { // 將調度（scheduling）移動到開頭 if (i < 1e9 - 1e6) { setTimeout(count); // 安排（schedule）新的調用 } do { i++; } while (i % 1e6 != 0); if (i == 1e9) { alert("Done in " + (Date.now() - start) + 'ms'); } } count();現在，當我們開始調用 count() 時，會看到我們需要對 count() 進行更多調用，我們就會在工作前立即安排(schedule)它。
如果你運行它，你很容易注意到它花費的時間明顯減少了。
為什么?
這很簡單：你應該還記得，多個嵌套的 setTimeout 調用在瀏覽器中的最小延遲為 4ms。即使我們設置了 0，但還是 4ms(或者更久一些)。所以我們安排(schedule)得越早，運行速度也就越快。
最后，我們將一個繁重的任務拆分成了幾部分，現在它不會阻塞用戶界面了。而且其總耗時并不會長很多。
用例 2：進度指示
對瀏覽器腳本中的過載型任務進行拆分的另一個好處是，我們可以顯示進度指示。
正如前面所提到的，僅在當前運行的任務完成后，才會對 DOM 中的更改進行繪制，無論這個任務運行花費了多長時間。
從一方面講，這非常好，因為我們的函數可能會創建很多元素，將它們一個接一個地插入到文檔中，并更改其樣式 —— 訪問者不會看到任何未完成的“中間態”內容。很重要，對吧?
這是一個示例，對 i 的更改在該函數完成前不會顯示出來，所以我們將只會看到最后的值：
<div id="progress"></div> <script> function count() { for (let i = 0; i < 1e6; i++) { i++; progress.innerHTML = i; } } count(); </script>……但是我們也可能想在任務執行期間展示一些東西，例如進度條。
如果我們使用 setTimeout 將繁重的任務拆分成幾部分，那么變化就會被在它們之間繪制出來。
這看起來更好看：
<div id="progress"></div> <script> let i = 0; function count() { // 做繁重的任務的一部分 (*) do { i++; progress.innerHTML = i; } while (i % 1e3 != 0); if (i < 1e7) { setTimeout(count); } } count(); </script>現在 div 顯示了 i 的值的增長，這就是進度條的一種。
用例 3：在事件之后做一些事情
在事件處理程序中，我們可能會決定推遲某些行為，直到事件冒泡并在所有級別上得到處理后。我們可以通過將該代碼包裝到零延遲的 setTimeout 中來做到這一點。
在 創建自定義事件[1] 一章中，我們看到過這樣一個例子：自定義事件 menu-open 被在 setTimeout 中分派(dispatched)，所以它在 click 事件被處理完成之后發生。
menu.onclick = function() { // ... // 創建一個具有被點擊的菜單項的數據的自定義事件 let customEvent = new CustomEvent("menu-open", { bubbles: true }); // 異步分派（dispatch）自定義事件 setTimeout(() => menu.dispatchEvent(customEvent)); };宏任務和微任務
除了本章中所講的 宏任務(macrotask) 外，還有在 微任務隊列[2] 一章中提到的 微任務(microtask)。
微任務僅來自于我們的代碼。它們通常是由 promise 創建的：對 .then/catch/finally 處理程序的執行會成為微任務。微任務也被用于 await 的“幕后”，因為它是 promise 處理的另一種形式。
還有一個特殊的函數 queueMicrotask(func)，它對 func 進行排隊，以在微任務隊列中執行。
每個宏任務之后，引擎會立即執行微任務隊列中的所有任務，然后再執行其他的宏任務，或渲染，或進行其他任何操作。
例如，看看下面這個示例：
setTimeout(() => alert("timeout")); Promise.resolve() .then(() => alert("promise")); alert("code");這里的執行順序是怎樣的?
鴻蒙官方戰略合作共建——HarmonyOS技術社區
code 首先顯示，因為它是常規的同步調用。
promise 第二個出現，因為 then 會通過微任務隊列，并在當前代碼之后執行。
timeout 最后顯示，因為它是一個宏任務。
更詳細的事件循環圖示如下(順序是從上到下，即：首先是腳本，然后是微任務，渲染等)：
微任務會在執行任何其他事件處理，或渲染，或執行任何其他宏任務之前完成。
這很重要，因為它確保了微任務之間的應用程序環境基本相同(沒有鼠標坐標更改，沒有新的網絡數據等)。
如果我們想要異步執行(在當前代碼之后)一個函數，但是要在更改被渲染或新事件被處理之前執行，那么我們可以使用 queueMicrotask 來對其進行安排(schedule)。
這是一個與前面那個例子類似的，帶有“計數進度條”的示例，但是它使用了 queueMicrotask而不是 setTimeout。你可以看到它在最后才渲染。就像寫的是同步代碼一樣：
<div id="progress"></div> <script> let i = 0; function count() { // 做繁重的任務的一部分 (*) do { i++; progress.innerHTML = i; } while (i % 1e3 != 0); if (i < 1e6) { queueMicrotask(count); } } count(); </script>總結
更詳細的事件循環算法(盡管與 規范[3] 相比仍然是簡化過的)：
1.從 宏任務 隊列(例如 "script")中出隊(dequeue)并執行最早的任務。
2.執行所有 微任務：
出隊(dequeue)并執行最早的微任務。
當微任務隊列非空時：
3.執行渲染，如果有。
4.如果宏任務隊列為空，則休眠直到出現宏任務。
5.轉到步驟 1。
安排(schedule)一個新的 宏任務：
使用零延遲的 setTimeout(f)。
它可被用于將繁重的計算任務拆分成多個部分，以使瀏覽器能夠對用戶事件作出反應，并在任務的各部分之間顯示任務進度。
此外，也被用于在事件處理程序中，將一個行為(action)安排(schedule)在事件被完全處理(冒泡完成)后。
安排一個新的 微任務：
使用 queueMicrotask(f)。
promise 處理程序也會通過微任務隊列。
在微任務之間沒有 UI 或網絡事件的處理：它們一個立即接一個地執行。
所以，我們可以使用 queueMicrotask 來在保持環境狀態一致的情況下，異步地執行一個函數。
Web Workers:
對于不應該阻塞事件循環的耗時長的繁重計算任務，我們可以使用 Web Workers[4]。
這是在另一個并行線程中運行代碼的方式。
Web Workers 可以與主線程交換消息，但是它們具有自己的變量和事件循環。
Web Workers 沒有訪問 DOM 的權限，因此，它們對于同時使用多個 CPU 內核的計算非常有用。
看完上述內容，你們掌握 JavaScript 事件循環中微任務和宏任務有什么區別的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
