背景
我們先來看一段Vue的執行程式碼：
export default {
data () {
return {
msg: 0
}
},
mounted () {
this.msg = 1
this.msg = 2
this.msg = 3
},
watch: {
msg () {
console.log(this.msg)
}
}
}
複製程式碼這段指令碼執行我們猜測會依次列印：1、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 = false
let 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')
})
}
})
複製程式碼這個的執行順序想必大家都知道先後列印：1、promise、2、3。
-
因為首先觸發了
this.msg = 'end'，導致觸發了watcher的update，從而將更新操作callback push進入vue的事件佇列。 -
this.$nextTick也為事件佇列push進入了新的一個callback函式，他們都是通過setImmediate-->MessageChannel-->Promise-->setTimeout來定義timeFunc。而Promise.resolve().then則是microTask，所以會先去列印promise。 -
在支援
MessageChannel和setImmediate的情況下，他們的執行順序是優先於setTimeout的（在IE11/Edge中，setImmediate延遲可以在1ms以內，而setTimeout有最低4ms的延遲，所以setImmediate比setTimeout(0)更早執行回撥函式。其次因為事件佇列裡，優先收入callback陣列）所以會列印2，接著列印3 -
但是在不支援
MessageChannel和setImmediate的情況下，又會通過Promise定義timeFunc,也是老版本Vue 2.4 之前的版本會優先執行promise。這種情況會導致順序成為了：1、2、promise、3。因為this.msg必定先會觸發dom更新函式，dom更新函式會先被callback收納進入非同步時間佇列，其次才定義Promise.resolve().then(function () { console.log('promise!')})這樣的microTask，接著定義$nextTick又會被callback收納。我們知道佇列滿足先進先出的原則，所以優先去執行callback收納的物件。
後記
如果你對Vue原始碼感興趣，可以來這裡：
參考文章：