VuenextTick機制

背景

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

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

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

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

queueWatcher

我們定義watch監(jiān)聽msg，實際上會被Vue這樣調用vm.$watch(keyOrFn, handler, options)。$watch是我們初始化的時候，為vm綁定的一個函數(shù)，用于創(chuàng)建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，也就是當觸發(fā)update更新的時候，會去執(zhí)行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函數(shù)其實就是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函數(shù)，在說nexTick之前，需要你對Event Loop、microTask、macroTask有一定的了解，Vue nextTick 也是主要用到了這些基礎原理。如果你還不了解，可以參考我的這篇文章Event Loop 簡介 好了，下面我們來看一下他的實現(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?<?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數(shù)組來模擬事件隊列，事件隊里的事件，通過nextTickHandler方法來執(zhí)行調用，而何事進行執(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)
?}
?}
復制代碼

可以看出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的最小時間延遲是4ms，也就是說理想環(huán)境下異步回調最快也是4ms才能觸發(fā)。Vue使用這么多函數(shù)來模擬異步任務，其目的只有一個，就是讓回調異步且盡早調用。而MessageChannel 和 setImmediate 的延遲明顯是小于setTimeout的。

解決問題

有了這些基礎，我們再看一遍上面提到的問題。因為Vue的事件機制是通過事件隊列來調度執(zhí)行，會等主進程執(zhí)行空閑后進行調度，所以先回去等待所有的進程執(zhí)行完成之后再去一次更新。這樣的性能優(yōu)勢很明顯，比如：

現(xiàn)在有這樣的一種情況，mounted的時候test的值會被++循環(huán)執(zhí)行1000次。 每次++時，都會根據(jù)響應式觸發(fā)setter->Dep->Watcher->update->run。 如果這時候沒有異步更新視圖，那么每次++都會直接操作DOM更新視圖，這是非常消耗性能的。 所以Vue實現(xiàn)了一個queue隊列，在下一個Tick（或者是當前Tick的微任務階段）的時候會統(tǒng)一執(zhí)行queue中Watcher的run。同時，擁有相同id的Watcher不會被重復加入到該queue中去，所以不會執(zhí)行1000次Watcher的run。最終更新視圖只會直接將test對應的DOM的0變成1000。 保證更新視圖操作DOM的動作是在當前棧執(zhí)行完以后下一個Tick（或者是當前Tick的微任務階段）的時候調用，大大優(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')
?})
?}
})
復制代碼

這個的執(zhí)行順序想必大家都知道先后打印：1、promise、2、3。

  1. 因為首先觸發(fā)了this.msg = 'end'，導致觸發(fā)了watcher的update，從而將更新操作callback push進入vue的事件隊列。

  2. this.$nextTick也為事件隊列push進入了新的一個callback函數(shù)，他們都是通過setImmediate --> MessageChannel --> Promise --> setTimeout來定義timeFunc。而Promise.resolve().then則是microTask，所以會先去打印promise。

  3. 在支持MessageChannel和setImmediate的情況下，他們的執(zhí)行順序是優(yōu)先于setTimeout的（在IE11/Edge中，setImmediate延遲可以在1ms以內，而setTimeout有最低4ms的延遲，所以setImmediate比setTimeout(0)更早執(zhí)行回調函數(shù)。其次因為事件隊列里，優(yōu)先收入callback數(shù)組）所以會打印2，接著打印3

  4. 但是在不支持MessageChannel和setImmediate的情況下，又會通過Promise定義timeFunc,也是老版本Vue 2.4 之前的版本會優(yōu)先執(zhí)行promise。這種情況會導致順序成為了：1、2、promise、3。因為this.msg必定先會觸發(fā)dom更新函數(shù)，dom更新函數(shù)會先被callback收納進入異步時間隊列，其次才定義Promise.resolve().then(function () { console.log('promise!')})這樣的microTask，接著定義$nextTick又會被callback收納。我們知道隊列滿足先進先出的原則，所以優(yōu)先去執(zhí)行callback收納的對象。

當前名稱：VuenextTick機制
本文鏈接：http://bm7419.com/article46/igcchg.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供電子商務、定制網(wǎng)站、外貿(mào)建站、標簽優(yōu)化、網(wǎng)頁設計公司、手機網(wǎng)站建設

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)

外貿(mào)網(wǎng)站制作