背景

創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比湖州網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式湖州網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋湖州地區(qū)。費(fèi)用合理售后完善，10余年實(shí)體公司更值得信賴。

我們先來看一段Vue的執(zhí)行代碼：

export?default?{?data?()?{?return?{
?msg:?0
?}
?},
?mounted?()?{?this.msg?=?1
?this.msg?=?2
?this.msg?=?3
?},
?watch:?{
?msg?()?{
?console.log(this.msg)
?}
?}
}
復(fù)制代碼

這段腳本執(zhí)行我們猜測(cè)會(huì)依次打印：1、2、3。但是實(shí)際效果中，只會(huì)輸出一次：3。為什么會(huì)出現(xiàn)這樣的情況？我們來一探究竟。

queueWatcher

我們定義watch監(jiān)聽msg，實(shí)際上會(huì)被Vue這樣調(diào)用vm.$watch(keyOrFn, handler, options)。$watch是我們初始化的時(shí)候，為vm綁定的一個(gè)函數(shù)，用于創(chuàng)建Watcher對(duì)象。那么我們看看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)
?}
?}
...
復(fù)制代碼

初始設(shè)定this.deep = this.user = this.lazy = this.sync = false，也就是當(dāng)觸發(fā)update更新的時(shí)候，會(huì)去執(zhí)行queueWatcher方法：

const?queue:?Array?=?[]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)
?}
?}
}
復(fù)制代碼

這里面的nextTick(flushSchedulerQueue)中的flushSchedulerQueue函數(shù)其實(shí)就是watcher的視圖更新:

function?flushSchedulerQueue?()?{
?flushing?=?true
?let?watcher,?id
?...?for?(index?=?0;?index?
另外，關(guān)于waiting變量，這是很重要的一個(gè)標(biāo)志位，它保證flushSchedulerQueue回調(diào)只允許被置入callbacks一次。 接下來我們來看看nextTick函數(shù)，在說nexTick之前，需要你對(duì)Event Loop、microTask、macroTask有一定的了解，Vue nextTick 也是主要用到了這些基礎(chǔ)原理。如果你還不了解，可以參考我的這篇文章Event Loop 簡(jiǎn)介 好了，下面我們來看一下他的實(shí)現(xiàn)：
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??{
?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
?})
?}
?}
})()
復(fù)制代碼
首先Vue通過callback數(shù)組來模擬事件隊(duì)列，事件隊(duì)里的事件，通過nextTickHandler方法來執(zhí)行調(diào)用，而何事進(jìn)行執(zhí)行，是由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)
?}
?}
復(fù)制代碼
可以看出timerFunc的定義優(yōu)先順序macroTask --> microTask，在沒有Dom的環(huán)境中，使用microTask，比如weex
setImmediate、MessageChannel VS setTimeout
我們是優(yōu)先定義setImmediate、MessageChannel為什么要優(yōu)先用他們創(chuàng)建macroTask而不是setTimeout？ HTML5中規(guī)定setTimeout的最小時(shí)間延遲是4ms，也就是說理想環(huán)境下異步回調(diào)最快也是4ms才能觸發(fā)。Vue使用這么多函數(shù)來模擬異步任務(wù)，其目的只有一個(gè)，就是讓回調(diào)異步且盡早調(diào)用。而MessageChannel 和 setImmediate 的延遲明顯是小于setTimeout的。
解決問題
有了這些基礎(chǔ)，我們?cè)倏匆槐樯厦嫣岬降膯栴}。因?yàn)閂ue的事件機(jī)制是通過事件隊(duì)列來調(diào)度執(zhí)行，會(huì)等主進(jìn)程執(zhí)行空閑后進(jìn)行調(diào)度，所以先回去等待所有的進(jìn)程執(zhí)行完成之后再去一次更新。這樣的性能優(yōu)勢(shì)很明顯，比如：
現(xiàn)在有這樣的一種情況，mounted的時(shí)候test的值會(huì)被++循環(huán)執(zhí)行1000次。 每次++時(shí)，都會(huì)根據(jù)響應(yīng)式觸發(fā)setter->Dep->Watcher->update->run。 如果這時(shí)候沒有異步更新視圖，那么每次++都會(huì)直接操作DOM更新視圖，這是非常消耗性能的。 所以Vue實(shí)現(xiàn)了一個(gè)queue隊(duì)列，在下一個(gè)Tick（或者是當(dāng)前Tick的微任務(wù)階段）的時(shí)候會(huì)統(tǒng)一執(zhí)行queue中Watcher的run。同時(shí)，擁有相同id的Watcher不會(huì)被重復(fù)加入到該queue中去，所以不會(huì)執(zhí)行1000次Watcher的run。最終更新視圖只會(huì)直接將test對(duì)應(yīng)的DOM的0變成1000。 保證更新視圖操作DOM的動(dòng)作是在當(dāng)前棧執(zhí)行完以后下一個(gè)Tick（或者是當(dāng)前Tick的微任務(wù)階段）的時(shí)候調(diào)用，大大優(yōu)化了性能。
有趣的問題
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')
?})
?}
})
復(fù)制代碼
這個(gè)的執(zhí)行順序想必大家都知道先后打印：1、promise、2、3。
因?yàn)槭紫扔|發(fā)了this.msg = 'end'，導(dǎo)致觸發(fā)了watcher的update，從而將更新操作callback push進(jìn)入vue的事件隊(duì)列。
this.$nextTick也為事件隊(duì)列push進(jìn)入了新的一個(gè)callback函數(shù)，他們都是通過setImmediate --> MessageChannel --> Promise --> setTimeout來定義timeFunc。而Promise.resolve().then則是microTask，所以會(huì)先去打印promise。
在支持MessageChannel和setImmediate的情況下，他們的執(zhí)行順序是優(yōu)先于setTimeout的（在IE11/Edge中，setImmediate延遲可以在1ms以內(nèi)，而setTimeout有最低4ms的延遲，所以setImmediate比setTimeout(0)更早執(zhí)行回調(diào)函數(shù)。其次因?yàn)槭录?duì)列里，優(yōu)先收入callback數(shù)組）所以會(huì)打印2，接著打印3
但是在不支持MessageChannel和setImmediate的情況下，又會(huì)通過Promise定義timeFunc,也是老版本Vue 2.4 之前的版本會(huì)優(yōu)先執(zhí)行promise。這種情況會(huì)導(dǎo)致順序成為了：1、2、promise、3。因?yàn)閠his.msg必定先會(huì)觸發(fā)dom更新函數(shù)，dom更新函數(shù)會(huì)先被callback收納進(jìn)入異步時(shí)間隊(duì)列，其次才定義Promise.resolve().then(function () { console.log('promise!')})這樣的microTask，接著定義$nextTick又會(huì)被callback收納。我們知道隊(duì)列滿足先進(jìn)先出的原則，所以優(yōu)先去執(zhí)行callback收納的對(duì)象。
            
            
                        

            本文標(biāo)題：VuenextTick機(jī)制            

            分享URL：http://weahome.cn/article/igcchg.html