Vue原始碼閱讀- 批量非同步更新與nextTick原理

vue已是目前國內前端web端三分天下之一，同時也作為本人主要技術棧之一，在日常使用中知其然也好奇著所以然，另外最近的社群湧現了一大票vue原始碼閱讀類的文章，在下借這個機會從大家的文章和討論中汲取了一些營養，同時對一些閱讀原始碼時的想法進行總結，出產一些文章，作為自己思考的總結，本人水平有限，歡迎留言討論~

目標Vue版本：2.5.17-beta.0

宣告：文章中原始碼的語法都使用 Flow，並且原始碼根據需要都有刪節(為了不被迷糊 @[email protected])，如果要看完整版的請進入上面的github地址，本文是系列文章，文章地址見底部~

1. 非同步更新

上一篇文章我們在依賴收集原理的響應式化方法 defineReactive

中的 setter 訪問器中有派發更新 dep.notify() 方法，這個方法會挨個通知在 dep 的 subs 中收集的訂閱自己變動的watchers執行update。一起來看看 update 方法的實現：

// src/core/observer/watcher.js

/* Subscriber介面，當依賴發生改變的時候進行回撥 */
update() {
  if (this.computed) {
    // 一個computed watcher有兩種模式：activated lazy(預設)
    // 只有當它被至少一個訂閱者依賴時才置activated，這通常是另一個計算屬性或元件的render function
    if (this.dep.subs.length === 0) {       // 如果沒人訂閱這個計算屬性的變化
      // lazy時，我們希望它只在必要時執行計算，所以我們只是簡單地將觀察者標記為dirty
      // 當計算屬性被訪問時，實際的計算在this.evaluate()中執行
      this.dirty = true
    } else {
      // activated模式下，我們希望主動執行計算，但只有當值確實發生變化時才通知我們的訂閱者
      this.getAndInvoke(() => {
        this.dep.notify()     // 通知渲染watcher重新渲染，通知依賴自己的所有watcher執行update
      })
    }
  } else if (this.sync) {	  // 同步
    this.run()
  } else {
    queueWatcher(this)        // 非同步推送到排程者觀察者佇列中，下一個tick時呼叫
  }
}

123456789101112131415161718192021222324

// src/core/observer/watcher.js/* Subscriber介面，當依賴發生改變的時候進行回撥 */update(){if(this.computed){// 一個computed watcher有兩種模式：activated lazy(預設)// 只有當它被至少一個訂閱者依賴時才置activated，這通常是另一個計算屬性或元件的render functionif(this.dep.subs.length===0){// 如果沒人訂閱這個計算屬性的變化

// lazy時，我們希望它只在必要時執行計算，所以我們只是簡單地將觀察者標記為dirty// 當計算屬性被訪問時，實際的計算在this.evaluate()中執行this.dirty=true}else{// activated模式下，我們希望主動執行計算，但只有當值確實發生變化時才通知我們的訂閱者this.getAndInvoke(()=>{this.dep.notify()// 通知渲染watcher重新渲染，通知依賴自己的所有watcher執行update})}}elseif(this.sync){// 同步this.run()}else{queueWatcher(this)// 非同步推送到排程者觀察者佇列中，下一個tick時呼叫}}

如果不是 computed watcher 也非 sync 會把呼叫update的當前watcher推送到排程者佇列中，下一個tick時呼叫，看看 queueWatcher ：

JavaScript

// src/core/observer/scheduler.js

/* nextTick的回撥函式，在下一個tick時flush掉兩個佇列同時執行watchers */
function flushSchedulerQueue () {
  flushing = true
  let watcher, id

  queue.sort((a, b) => a.id - b.id)					// 排序

  for (index = 0; index < queue.length; index++) {	 // 不要將length進行快取
    watcher = queue[index]
    if (watcher.before) {         // 如果watcher有before則執行
      watcher.before()
    }
    id = watcher.id
    has[id] = null                // 將has的標記刪除
    watcher.run()                 // 執行watcher
    if (process.env.NODE_ENV !== 'production' && has[id] != null) {  // 在dev環境下檢查是否進入死迴圈
      circular[id] = (circular[id] || 0) + 1     // 比如user watcher訂閱自己的情況
      if (circular[id] > MAX_UPDATE_COUNT) {     // 持續執行了一百次watch代表可能存在死迴圈
        warn()								  // 進入死迴圈的警告
        break
      }
    }
  }
  resetSchedulerState()           // 重置排程者狀態
  callActivatedHooks()            // 使子元件狀態都置成active同時呼叫activated鉤子
  callUpdatedHooks()              // 呼叫updated鉤子
}

1234567891011121314151617181920212223242526272829

// src/core/observer/scheduler.js/* nextTick的回撥函式，在下一個tick時flush掉兩個佇列同時執行watchers */functionflushSchedulerQueue(){flushing=truelet watcher,idqueue.sort((a,b)=>a.id-b.id)// 排序for(index=0;index<queue.length;index++){// 不要將length進行快取watcher=queue[index]if(watcher.before){// 如果watcher有before則執行watcher.before()}id=watcher.idhas[id]=null// 將has的標記刪除watcher.run()// 執行watcherif(process.env.NODE_ENV!=='production'&&has[id]!=null){// 在dev環境下檢查是否進入死迴圈circular[id]=(circular[id]||0)+1// 比如user watcher訂閱自己的情況if(circular[id]>MAX_UPDATE_COUNT){// 持續執行了一百次watch代表可能存在死迴圈warn()// 進入死迴圈的警告break}}}resetSchedulerState()// 重置排程者狀態callActivatedHooks()// 使子元件狀態都置成active同時呼叫activated鉤子callUpdatedHooks()// 呼叫updated鉤子}

這裡使用了一個 has 的雜湊map用來檢查是否當前watcher的id是否存在，若已存在則跳過，不存在則就push到 queue 佇列中並標記雜湊表has，用於下次檢驗，防止重複新增。這就是一個去重的過程，比每次查重都要去queue中找要文明，在渲染的時候就不會重複 patch 相同watcher的變化，這樣就算同步修改了一百次檢視中用到的data，非同步 patch 的時候也只會更新最後一次修改。

這裡的 waiting 方法是用來標記 flushSchedulerQueue 是否已經傳遞給 nextTick 的標記位，如果已經傳遞則只push到佇列中不傳遞 flushSchedulerQueue 給 nextTick，等到 resetSchedulerState 重置排程者狀態的時候 waiting 會被置回 false 允許 flushSchedulerQueue 被傳遞給下一個tick的回撥，總之保證了 flushSchedulerQueue 回撥在一個tick內只允許被傳入一次。來看看被傳遞給 nextTick 的回撥 flushSchedulerQueue 做了什麼：

// src/core/observer/scheduler.js

/* nextTick的回撥函式，在下一個tick時flush掉兩個佇列同時執行watchers */
function flushSchedulerQueue () {
  flushing = true
  let watcher, id

  queue.sort((a, b) => a.id - b.id)					// 排序

  for (index = 0; index // 不要將length進行快取
    watcher = queue[index]
    if (watcher.before) {         // 如果watcher有before則執行
      watcher.before()
    }
    id = watcher.id
    has[id] = null                // 將has的標記刪除
    watcher.run()                 // 執行watcher
    if (process.env.NODE_ENV !== 'production' && has[id] != null) {  // 在dev環境下檢查是否進入死迴圈
      circular[id] = (circular[id] || 0) + 1     // 比如user watcher訂閱自己的情況
      if (circular[id] > MAX_UPDATE_COUNT) {     // 持續執行了一百次watch代表可能存在死迴圈
        warn()								  // 進入死迴圈的警告
        break
      }
    }
  }
  resetSchedulerState()           // 重置排程者狀態
  callActivatedHooks()            // 使子元件狀態都置成active同時呼叫activated鉤子
  callUpdatedHooks()              // 呼叫updated鉤子
}
複製程式碼

123456789101112131415161718192021222324252627282930

// src/core/observer/scheduler.js/* nextTick的回撥函式，在下一個tick時flush掉兩個佇列同時執行watchers */functionflushSchedulerQueue(){flushing=truelet watcher,idqueue.sort((a,b)=>a.id-b.id)// 排序for(index=0;index// 不要將length進行快取watcher=queue[index]if(watcher.before){// 如果watcher有before則執行watcher.before()}id=watcher.idhas[id]=null// 將has的標記刪除watcher.run()// 執行watcherif(process.env.NODE_ENV!=='production'&&has[id]!=null){// 在dev環境下檢查是否進入死迴圈circular[id]=(circular[id]||0)+1// 比如user watcher訂閱自己的情況if(circular[id]>MAX_UPDATE_COUNT){// 持續執行了一百次watch代表可能存在死迴圈warn()// 進入死迴圈的警告break}}}resetSchedulerState()// 重置排程者狀態callActivatedHooks()// 使子元件狀態都置成active同時呼叫activated鉤子callUpdatedHooks()// 呼叫updated鉤子}複製程式碼

在 nextTick 方法中執行 flushSchedulerQueue 方法，這個方法挨個執行 queue 中的watcher的 run 方法。我們看到在首先有個 queue.sort() 方法把佇列中的watcher按id從小到大排了個序，這樣做可以保證：

元件更新的順序是從父元件到子元件的順序，因為父元件總是比子元件先建立。
一個元件的user watchers(偵聽器watcher)比render watcher先執行，因為user watchers往往比render watcher更早建立
如果一個元件在父元件watcher執行期間被銷燬，它的watcher執行將被跳過

在挨個執行佇列中的for迴圈中，index < queue.length 這裡沒有將length進行快取，因為在執行處理現有watcher物件期間，更多的watcher物件可能會被push進queue。

那麼資料的修改從model層反映到view的過程：資料更改 -> setter -> Dep -> Watcher -> nextTick -> patch -> 更新檢視

2. nextTick原理

2.1 巨集任務/微任務

這裡就來看看包含著每個watcher執行的方法被作為回撥傳入 nextTick 之後，nextTick 對這個方法做了什麼。不過首先要了解一下瀏覽器中的 EventLoop、macro task、micro task幾個概念，不瞭解可以參考一下 JS與Node.js中的事件迴圈這篇文章，這裡就用一張圖來表明一下後兩者在主執行緒中的執行關係：

解釋一下，當主執行緒執行完同步任務後：

引擎首先從macrotask queue中取出第一個任務，執行完畢後，將microtask queue中的所有任務取出，按順序全部執行；
然後再從macrotask queue中取下一個，執行完畢後，再次將microtask queue中的全部取出；
迴圈往復，直到兩個queue中的任務都取完。

瀏覽器環境中常見的非同步任務種類，按照優先順序：

macro task ：同步程式碼、setImmediate、MessageChannel、setTimeout/setInterval
micro task：Promise.then、MutationObserver

有的文章把 micro task 叫微任務，macro task 叫巨集任務，因為這兩個單詞拼寫太像了 -。- ，所以後面的註釋多用中文表示~

先來看看原始碼中對 micro task 與 macro task 的實現： macroTimerFunc、microTimerFunc

JavaScript

// src/core/util/next-tick.js

const callbacks = []     // 存放非同步執行的回撥
let pending = false      // 一個標記位，如果已經有timerFunc被推送到任務佇列中去則不需要重複推送

/* 挨個同步執行callbacks中回撥 */
function flushCallbacks() {
  pending = false
  const copies = callbacks.slice(0)
  callbacks.length = 0
  for (let i = 0; i < copies.length; i++) {
    copies[i]()
  }
}

let microTimerFunc        // 微任務執行方法
let macroTimerFunc        // 巨集任務執行方法
let useMacroTask = false  // 是否強制為巨集任務，預設使用微任務

// 巨集任務
if (typeof setImmediate !== 'undefined' && isNative(setImmediate)) {
  macroTimerFunc = () => {
    setImmediate(flushCallbacks)
  }
} else if (typeof MessageChannel !== 'undefined' && (
  isNative(MessageChannel) ||
  MessageChannel.toString() === '[object MessageChannelConstructor]'  // PhantomJS
)) {
  const channel = new MessageChannel()
  const port = channel.port2
  channel.port1.onmessage = flushCallbacks
  macroTimerFunc = () => {
    port.postMessage(1)
  }
} else {
  macroTimerFunc = () => {
    setTimeout(flushCallbacks, 0)
  }
}

// 微任務
if (typeof Promise !== 'undefined' && isNative(Promise)) {
  const p = Promise.resolve()
  microTimerFunc = () => {
    p.then(flushCallbacks)
  }
} else {
  microTimerFunc = macroTimerFunc      // fallback to macro
}

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849

// src/core/util/next-tick.jsconstcallbacks=[]// 存放非同步執行的回撥let pending=false// 一個標記位，如果已經有timerFunc被推送到任務佇列中去則不需要重複推送/* 挨個同步執行callbacks中回撥 */functionflushCallbacks(){pending=falseconstcopies=callbacks.slice(0)callbacks.length=0for(leti=0;i<copies.length;i++){copies[i]()}}let microTimerFunc// 微任務執行方法let macroTimerFunc// 巨集任務執行方法let useMacroTask=false// 是否強制為巨集任務，預設使用微任務// 巨集任務if(typeofsetImmediate!=='undefined'&&isNative(setImmediate)){macroTimerFunc=()=>{setImmediate(flushCallbacks)}}elseif(typeofMessageChannel!=='undefined'&&(isNative(MessageChannel)||MessageChannel.toString()==='[object MessageChannelConstructor]'// PhantomJS)){constchannel=newMessageChannel()constport=channel.port2channel.port1.onmessage=flushCallbacksmacroTimerFunc=()=>{port.postMessage(1)}}else{macroTimerFunc=()=>{setTimeout(flushCallbacks,0)}}// 微任務if(typeofPromise!=='undefined'&&isNative(Promise)){constp=Promise.resolve()microTimerFunc=()=>{p.then(flushCallbacks)}}else{microTimerFunc=macroTimerFunc// fallback to macro}

flushCallbacks 這個方法就是挨個同步的去執行callbacks中的回撥函式們，callbacks中的回撥函式是在呼叫 nextTick 的時候新增進去的；那麼怎麼去使用 micro task 與 macro task 去執行 flushCallbacks 呢，這裡他們的實現 macroTimerFunc、microTimerFunc 使用瀏覽器中巨集任務/微任務的API對flushCallbacks 方法進行了一層包裝。比如巨集任務方法 macroTimerFunc=()=>{ setImmediate(flushCallbacks) }，這樣在觸發巨集任務執行的時候 macroTimerFunc() 就可以在瀏覽器中的下一個巨集任務loop的時候消費這些儲存在callbacks陣列中的回調了，微任務同理。同時也可以看出傳給 nextTick 的非同步回撥函式是被壓成了一個同步任務在一個tick執行完的，而不是開啟多個非同步任務。

注意這裡有個比較難理解的地方，第一次呼叫 nextTick 的時候 pending 為false，此時已經push到瀏覽器event loop中一個巨集任務或微任務的task，如果在沒有flush掉的情況下繼續往callbacks裡面新增，那麼在執行這個佔位queue的時候會執行之後新增的回撥，所以 macroTimerFunc、microTimerFunc 相當於task queue的佔位，以後 pending 為true則繼續往佔位queue裡面新增，event loop輪到這個task queue的時候將一併執行。執行 flushCallbacks 時 pending 置false，允許下一輪執行 nextTick 時往event loop佔位。

可以看到上面 macroTimerFunc 與 microTimerFunc 進行了在不同瀏覽器相容性下的平穩退化，或者說降級策略：

macroTimerFunc ：setImmediate -> MessageChannel -> setTimeout。首先檢測是否原生支援 setImmediate，這個方法只在 IE、Edge 瀏覽器中原生實現，然後檢測是否支援 MessageChannel，如果對 MessageChannel 不瞭解可以參考一下這篇文章，還不支援的話最後使用 setTimeout；為什麼優先使用 setImmediate 與 MessageChannel 而不直接使用 setTimeout 呢，是因為HTML5規定setTimeout執行的最小延時為4ms，而巢狀的timeout表現為10ms，為了儘可能快的讓回撥執行，沒有最小延時限制的前兩者顯然要優於 setTimeout。
microTimerFunc：Promise.then -> macroTimerFunc 。首先檢查是否支援 Promise，如果支援的話通過 Promise.then 來呼叫 flushCallbacks 方法，否則退化為 macroTimerFunc ； vue2.5之後 nextTick 中因為相容性原因刪除了微任務平穩退化的 MutationObserver 的方式。

2.2 nextTick實現

最後來看看我們平常用到的 nextTick 方法到底是如何實現的：

// src/core/util/next-tick.js

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)
    }
  })
  if (!pending) {
    pending = true
    if (useMacroTask) {
      macroTimerFunc()
    } else {
      microTimerFunc()
    }
  }
  if (!cb && typeof Promise !== 'undefined') {
    return new Promise(resolve => {
      _resolve = resolve
    })
  }
}

/* 強制使用macrotask的方法 */
export function withMacroTask(fn: Function): Function {
  return fn._withTask || (fn._withTask = function() {
    useMacroTask = true
    const res = fn.apply(null, arguments)
    useMacroTask = false
    return res
  })
}

12345678

Vue原始碼閱讀- 批量非同步更新與nextTick原理

1. 非同步更新

2. nextTick原理

2.1 巨集任務/微任務

2.2 nextTick實現

Vue原始碼閱讀- 批量非同步更新與nextTick原理

Vue.js 內部執行機制（六）---- 批量非同步更新策略及 nextTick 原理

vue的非同步更新佇列 $nextTick

vue 非同步更新佇列 $nextTick

Vue.js非同步更新及nextTick

Vue原始碼閱讀--過濾器

vue 原始碼閱讀記錄

Vue原始碼閱讀

Vue 父元件ajax非同步更新資料，子元件props獲取不到

原始碼分析Dubbo非同步呼叫與事件回撥機制

Curator原始碼閱讀 - ConnectionState的管理與監聽

JVM原始碼閱讀-本地庫載入流程和原理

dubbo原始碼分析22 -- consumer 傳送與接收原理

dubbo原始碼分析23 -- provider 接收與傳送原理

從Vue.js原始碼看非同步更新DOM策略及nextTick

Vue.js原始碼解析(八)【Vue.js非同步更新DOM策略及nextTick】

Vuejs中nextTick()非同步更新佇列原始碼解析

Vue源碼終筆-VNode更新與diff算法初探

JDK原始碼閱讀：InterruptibleChannel與可中斷IO，ig牛逼

mysql 批量更新與批量更新多條記錄的不同值實現方法

Vue原始碼閱讀- 批量非同步更新與nextTick原理

1. 非同步更新

2. nextTick原理

2.1 巨集任務/微任務

2.2 nextTick實現

相關推薦