Event Loop 與異步更新策略

Vue 和 React 都實現了異步更新策略。雖然實現的方式不盡相同，但都達到了減少 DOM 操作、避免過度渲染的目的。通過研究框架的運行機制，其設計思路將深化我們對 DOM 優化的理解，其實現手法將拓寬我們對 DOM 實踐的認知。

本節我們將基於 Event Loop 機制，對 Vue 的異步更新策略作探討。

前置知識：Event Loop 中的“渲染時機”

搞懂 Event Loop，是理解 Vue 對 DOM 操作優化的第一步。

Micro-Task 與 Macro-Task

事件循環中的異步隊列有兩種：macro（宏任務）隊列和 micro（微任務）隊列。

常見的 macro-task 比如： setTimeout、setInterval、 setImmediate、script（整體代碼）、 I/O 操作、UI 渲染等。
常見的 micro-task 比如: process.nextTick、Promise、MutationObserver 等。

Event Loop 過程解析

基於對 micro 和 macro 的認知，我們來走一遍完整的事件循環過程。

一個完整的 Event Loop 過程，可以概括爲以下階段：
初始狀態：調用棧空。micro 隊列空，macro 隊列裏有且只有一個 script 腳本（整體代碼）。
全局上下文（script 標籤）被推入調用棧，同步代碼執行。在執行的過程中，通過對一些接口的調用，可以產生新的 macro-task 與 micro-task，它們會分別被推入各自的任務隊列裏。同步代碼執行完了，script 腳本會被移出 macro 隊列，這個過程本質上是隊列的 macro-task 的執行和出隊的過程。
上一步我們出隊的是一個 macro-task，這一步我們處理的是 micro-task。但需要注意的是：當 macro-task 出隊時，任務是一個一個執行的；而 micro-task 出隊時，任務是一隊一隊執行的（如下圖所示）。因此，我們處理 micro 隊列這一步，會逐個執行隊列中的任務並把它出隊，直到隊列被清空。

執行渲染操作，更新界面（敲黑板劃重點）。
檢查是否存在 Web worker 任務，如果有，則對其進行處理。

（上述過程循環往復，直到兩個隊列都清空）

我們總結一下，每一次循環都是一個這樣的過程：

渲染的時機

大家現在思考一個這樣的問題：假如我想要在異步任務裏進行DOM更新，我該把它包裝成 micro 還是 macro 呢？

我們先假設它是一個 macro 任務，比如我在 script 腳本中用 setTimeout 來處理它：

// task是一個用於修改DOM的回調
setTimeout(task, 0)

現在 task 被推入的 macro 隊列。但因爲 script 腳本本身是一個 macro 任務，所以本次執行完 script 腳本之後，下一個步驟就要去處理 micro 隊列了，再往下就去執行了一次 render，對不對？

但本次render我的目標task其實並沒有執行，想要修改的DOM也沒有修改，因此這一次的render其實是一次無效的render。

macro 不 ok，我們轉向 micro 試試看。我用 Promise 來把 task 包裝成是一個 micro 任務：

Promise.resolve().then(task)

那麼我們結束了對 script 腳本的執行，是不是緊接着就去處理 micro-task 隊列了？micro-task 處理完，DOM 修改好了，緊接着就可以走 render 流程了——不需要再消耗多餘的一次渲染，不需要再等待一輪事件循環，直接爲用戶呈現最即時的更新結果。

因此，我們更新 DOM 的時間點，應該儘可能靠近渲染的時機。當我們需要在異步任務中實現 DOM 修改時，把它包裝成 micro 任務是相對明智的選擇。

異步更新策略——以 Vue 爲例

什麼是異步更新？

當我們使用 Vue 或 React 提供的接口去更新數據時，這個更新並不會立即生效，而是會被推入到一個隊列裏。待到適當的時機，隊列中的更新任務會被批量觸發。這就是異步更新。

異步更新可以幫助我們避免過度渲染，是我們上節提到的“讓 JS 爲 DOM 分壓”的典範之一。

異步更新的優越性
異步更新的特性在於它只看結果，因此渲染引擎不需要爲過程買單。

最典型的例子，比如有時我們會遇到這樣的情況：

// 任務一
this.content = '第一次測試'
// 任務二
this.content = '第二次測試'
// 任務三
this.content = '第三次測試'

我們在三個更新任務中對同一個狀態修改了三次，如果我們採取傳統的同步更新策略，那麼就要操作三次 DOM。但本質上需要呈現給用戶的目標內容其實只是第三次的結果，也就是說只有第三次的操作是有意義的——我們白白浪費了兩次計算。

但如果我們把這三個任務塞進異步更新隊列裏，它們會先在 JS 的層面上被批量執行完畢。當流程走到渲染這一步時，它僅僅需要針對有意義的計算結果操作一次 DOM——這就是異步更新的妙處。

Vue狀態更新手法：nextTick

Vue 每次想要更新一個狀態的時候，會先把它這個更新操作給包裝成一個異步操作派發出去。這件事情，在源碼中是由一個叫做 nextTick 的函數來完成的：

export function nextTick (cb?: Function, ctx?: Object) {
  let _resolve
  callbacks.push(() => {
    if (cb) {
      try {
        cb.call(ctx)
      } catch (e) {
        handleError(e, ctx, 'nextTick')
      }
    } else if (_resolve) {
      _resolve(ctx)
    }
  })
  // 檢查上一個異步任務隊列（即名爲callbacks的任務數組）是否派發和執行完畢了。pending此處相當於一個鎖
  if (!pending) {
    // 若上一個異步任務隊列已經執行完畢，則將pending設定爲true（把鎖鎖上）
    pending = true
    // 是否要求一定要派發爲macro任務
    if (useMacroTask) {
      macroTimerFunc()
    } else {
      // 如果不說明一定要macro 你們就全都是micro
      microTimerFunc()
    }
  }
  // $flow-disable-line
  if (!cb && typeof Promise !== 'undefined') {
    return new Promise(resolve => {
      _resolve = resolve
    })
  }
}

我們看到，Vue 的異步任務默認情況下都是用 Promise 來包裝的，也就是是說它們都是 micro-task。這一點和我們“前置知識”中的渲染時機的分析不謀而合。

爲了帶大家熟悉一下常見的 macro 和 micro 派發方式、加深對 Event Loop 的理解，我們繼續細化解析一下 macroTimeFunc() 和 microTimeFunc() 兩個方法。

macroTimeFunc() 是這麼實現的：

// macro首選setImmediate 這個兼容性最差
if (typeof setImmediate !== 'undefined' && isNative(setImmediate)) {
  macroTimerFunc = () => {
    setImmediate(flushCallbacks)
  }
} else if (typeof MessageChannel !== 'undefined' && (
    isNative(MessageChannel) ||
    // PhantomJS
    MessageChannel.toString() === '[object MessageChannelConstructor]'
  )) {
  const channel = new MessageChannel()
  const port = channel.port2
  channel.port1.onmessage = flushCallbacks
  macroTimerFunc = () => {
    port.postMessage(1)
  }
} else {
  // 兼容性最好的派發方式是setTimeout
  macroTimerFunc = () => {
    setTimeout(flushCallbacks, 0)
  }
}

microTimeFunc() 是這麼實現的：

// 簡單粗暴 不是ios全都給我去Promise 如果不兼容promise 那麼你只能將就一下變成macro了
if (typeof Promise !== 'undefined' && isNative(Promise)) {
  const p = Promise.resolve()
  microTimerFunc = () => {
    p.then(flushCallbacks)
    // in problematic UIWebViews, Promise.then doesn't completely break, but
    // it can get stuck in a weird state where callbacks are pushed into the
    // microtask queue but the queue isn't being flushed, until the browser
    // needs to do some other work, e.g. handle a timer. Therefore we can
    // "force" the microtask queue to be flushed by adding an empty timer.
    if (isIOS) setTimeout(noop)
  }
} else {
  // 如果無法派發micro，就退而求其次派發爲macro
  microTimerFunc = macroTimerFunc
}

我們注意到，無論是派發 macro 任務還是派發 micro 任務，派發的任務對象都是一個叫做 flushCallbacks 的東西，這個東西做了什麼呢？

flushCallbacks 源碼如下：

function flushCallbacks () {
  pending = false
  // callbacks在nextick中出現過 它是任務數組（隊列）
  const copies = callbacks.slice(0)
  callbacks.length = 0
  // 將callbacks中的任務逐個取出執行
  for (let i = 0; i < copies.length; i++) {
    copies[i]()
  }
}

現在我們理清楚了：Vue 中每產生一個狀態更新任務，它就會被塞進一個叫 callbacks 的數組（此處是任務隊列的實現形式）中。這個任務隊列在被丟進 micro 或 macro 隊列之前，會先去檢查當前是否有異步更新任務正在執行（即檢查 pending 鎖）。如果確認 pending 鎖是開着的（false），就把它設置爲鎖上（true），然後對當前 callbacks 數組的任務進行派發（丟進 micro 或 macro 隊列）和執行。設置 pending 鎖的意義在於保證狀態更新任務的有序進行，避免發生混亂。

本小節我們從性能優化的角度出發，通過解析Vue源碼，對異步更新這一高效的 DOM 優化手段有了感性的認知。同時幫助大家進一步熟悉了 micro 與 macro 在生產中的應用，加深了對 Event Loop 的理解。事實上，Vue 源碼中還有許多值得稱道的生產實踐，其設計模式與編碼細節都值得我們去細細品味。

其它前端性能優化：

前端技術架構體系（沒有鏈接的後續跟進）：

調用堆棧
作用域閉包
this全面解析
深淺拷貝的原理
原型prototype
事件機制、
Event Loop
Promise機制、
async / await原理、
防抖/節流原理
模塊化詳解、
es6重難點、
瀏覽器薰染原理、
webpack配置(原理)
前端監控、
跨域和安全、
性能優化（參見上面性能優化相關）
VirtualDom原理、
Diff算法、
數據的雙向綁定
[TCP協議(三次握手、四次揮手)](https://blog.csdn.net/woleigequshawanyier/article/details/85223642
DNS域名解析

其它相關

歡迎各位看官的批評和指正，共同學習和成長
希望該文章對您有幫助，你的 支持和鼓勵會是我持續的動力

Event Loop 與異步更新策略