我們先來看一段Vue的執行代碼：
export default { data () { return { msg: 0 } }, mounted () { this.msg = 1 this.msg = 2 this.msg = 3 }, watch: { msg () { console.log(this.msg) } }}這段腳本執行我們猜測1000m后會依次打?。?、2、3。但是實際效果中，只會輸出一次：3。為什么會出現這樣的情況？我們來一探究竟。
queueWatcher
我們定義 watch 監聽 msg ，實際上會被Vue這樣調用 vm.$watch(keyOrFn, handler, options) 。 $watch 是我們初始化的時候，為 vm 綁定的一個函數，用于創建 Watcher 對象。那么我們看看 Watcher 中是如何處理 handler 的：
this.deep = this.user = this.lazy = this.sync = false... update () { if (this.lazy) { this.dirty = true } else if (this.sync) { this.run() } else { queueWatcher(this) } }...初始設定 this.deep = this.user = this.lazy = this.sync = false ，也就是當觸發 update 更新的時候，會去執行 queueWatcher 方法：
const queue: Array<Watcher> = []let has: { [key: number]: ?true } = {}let waiting = falselet flushing = false...export function queueWatcher (watcher: Watcher) { const id = watcher.id if (has[id] == null) { has[id] = true if (!flushing) { queue.push(watcher) } else { // if already flushing, splice the watcher based on its id // if already past its id, it will be run next immediately. let i = queue.length - 1 while (i > index && queue[i].id > watcher.id) { i-- } queue.splice(i + 1, 0, watcher) } // queue the flush if (!waiting) { waiting = true nextTick(flushSchedulerQueue) } }}這里面的 nextTick(flushSchedulerQueue) 中的 flushSchedulerQueue 函數其實就是 watcher 的視圖更新:
function flushSchedulerQueue () { flushing = true let watcher, id ... for (index = 0; index < queue.length; index++) { watcher = queue[index] id = watcher.id has[id] = null watcher.run() ... }}另外，關于 waiting 變量，這是很重要的一個標志位，它保證 flushSchedulerQueue 回調只允許被置入 callbacks 一次。 接下來我們來看看 nextTick 函數，在說 nexTick 之前，需要你對 Event Loop 、 microTask 、 macroTask 有一定的了解，Vue nextTick 也是主要用到了這些基礎原理。如果你還不了解，可以參考我的這篇文章 Event Loop 簡介 好了，下面我們來看一下他的實現：
export const nextTick = (function () { const callbacks = [] let pending = false let timerFunc function nextTickHandler () { pending = false const copies = callbacks.slice(0) callbacks.length = 0 for (let i = 0; i < copies.length; i++) { copies[i]() } } // An asynchronous deferring mechanism. // In pre 2.4, we used to use microtasks (Promise/MutationObserver) // but microtasks actually has too high a priority and fires in between // supposedly sequential events (e.g. #4521, #6690) or even between // bubbling of the same event (#6566). Technically setImmediate should be // the ideal choice, but it's not available everywhere; and the only polyfill // that consistently queues the callback after all DOM events triggered in the // same loop is by using MessageChannel. /* istanbul ignore if */ if (typeof setImmediate !== 'undefined' && isNative(setImmediate)) { timerFunc = () => { setImmediate(nextTickHandler) } } else if (typeof MessageChannel !== 'undefined' && ( isNative(MessageChannel) || // PhantomJS MessageChannel.toString() === '[object MessageChannelConstructor]' )) { const channel = new MessageChannel() const port = channel.port2 channel.port1.onmessage = nextTickHandler timerFunc = () => { port.postMessage(1) } } else /* istanbul ignore next */ if (typeof Promise !== 'undefined' && isNative(Promise)) { // use microtask in non-DOM environments, e.g. Weex const p = Promise.resolve() timerFunc = () => { p.then(nextTickHandler) } } else { // fallback to setTimeout timerFunc = () => { setTimeout(nextTickHandler, 0) } } return function queueNextTick (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 timerFunc() } // $flow-disable-line if (!cb && typeof Promise !== 'undefined') { return new Promise((resolve, reject) => { _resolve = resolve }) } }})()首先Vue通過 callback 數組來模擬事件隊列，事件隊里的事件，通過 nextTickHandler 方法來執行調用，而何事進行執行，是由 timerFunc 來決定的。我們來看一下 timeFunc 的定義：
if (typeof setImmediate !== 'undefined' && isNative(setImmediate)) { timerFunc = () => { setImmediate(nextTickHandler) } } else if (typeof MessageChannel !== 'undefined' && ( isNative(MessageChannel) || // PhantomJS MessageChannel.toString() === '[object MessageChannelConstructor]' )) { const channel = new MessageChannel() const port = channel.port2 channel.port1.onmessage = nextTickHandler timerFunc = () => { port.postMessage(1) } } else /* istanbul ignore next */ if (typeof Promise !== 'undefined' && isNative(Promise)) { // use microtask in non-DOM environments, e.g. Weex const p = Promise.resolve() timerFunc = () => { p.then(nextTickHandler) } } else { // fallback to setTimeout timerFunc = () => { setTimeout(nextTickHandler, 0) } }可以看出 timerFunc 的定義優先順序 macroTask --> microTask ，在沒有 Dom 的環境中，使用 microTask ，比如weex
setImmediate、MessageChannel VS setTimeout
我們是優先定義 setImmediate 、 MessageChannel 為什么要優先用他們創建macroTask而不是setTimeout？ HTML5中規定setTimeout的最小時間延遲是4ms，也就是說理想環境下異步回調最快也是4ms才能觸發。Vue使用這么多函數來模擬異步任務，其目的只有一個，就是讓回調異步且盡早調用。而MessageChannel 和 setImmediate 的延遲明顯是小于setTimeout的。
解決問題
有了這些基礎，我們再看一遍上面提到的問題。因為 Vue 的事件機制是通過事件隊列來調度執行，會等主進程執行空閑后進行調度，所以先回去等待所有的進程執行完成之后再去一次更新。這樣的性能優勢很明顯，比如：
現在有這樣的一種情況，mounted的時候test的值會被++循環執行1000次。 每次++時，都會根據響應式觸發 setter->Dep->Watcher->update->run 。 如果這時候沒有異步更新視圖，那么每次++都會直接操作DOM更新視圖，這是非常消耗性能的。 所以Vue實現了一個 queue 隊列，在下一個Tick（或者是當前Tick的微任務階段）的時候會統一執行 queue 中 Watcher 的run。同時，擁有相同id的Watcher不會被重復加入到該queue中去，所以不會執行1000次Watcher的run。最終更新視圖只會直接將test對應的DOM的0變成1000。 保證更新視圖操作DOM的動作是在當前棧執行完以后下一個Tick（或者是當前Tick的微任務階段）的時候調用，大大優化了性能。
有趣的問題
var vm = new Vue({ el: '#example', data: { msg: 'begin', }, mounted () { this.msg = 'end' console.log('1') setTimeout(() => { // macroTask console.log('3') }, 0) Promise.resolve().then(function () { //microTask console.log('promise!') }) this.$nextTick(function () { console.log('2') }) }})這個的執行順序想必大家都知道先后打?。?、promise、2、3。
后記
如果你對Vue源碼感興趣，可以來這里：更多好玩的Vue約定源碼解釋
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持武林網。
新聞熱點
疑難解答
