深入理解Vue nextTick 機(jī)制
我們先來看一段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í)行我們猜測(cè)1000m后會(huì)依次打?。?、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)
}
}
...
初始設(shè)定 this.deep = this.user = this.lazy = this.sync = false ,也就是當(dāng)觸發(fā) update 更新的時(shí)候,會(huì)去執(zhí)行 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 函數(shù)其實(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()
...
}
}
另外,關(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 < 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ù)組來模擬事件隊(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)
}
}
可以看出 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)?Vue 的事件機(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')
})
}
})
這個(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ì)象。
后記
如果你對(duì)Vue源碼感興趣,可以來這里:更多好玩的Vue約定源碼解釋
以上就是本文的全部?jī)?nèi)容,希望對(duì)大家的學(xué)習(xí)有所幫助,也希望大家多多支持腳本之家。
相關(guān)文章
Vue實(shí)現(xiàn)兩種路由權(quán)限控制方式
路由權(quán)限控制常用于后臺(tái)管理系統(tǒng)中,對(duì)不同業(yè)務(wù)人員能夠訪問的頁面進(jìn)行一個(gè)權(quán)限的限制。本文主要介紹了兩種Vue 路由權(quán)限控制,具有一定的參考價(jià)值,感興趣的可以了解一下2021-10-10
vue實(shí)現(xiàn)元素拖動(dòng)并互換位置的實(shí)現(xiàn)代碼
在使用Vue的場(chǎng)景下,需要實(shí)現(xiàn)對(duì)元素進(jìn)行拖動(dòng)交換位置,接下來通過本文給大家介紹vue實(shí)現(xiàn)元素拖動(dòng)并互換位置的實(shí)現(xiàn)代碼,需要的朋友可以參考下2023-09-09
vue3點(diǎn)擊出現(xiàn)彈窗后背景變暗且不可操作的實(shí)現(xiàn)代碼
這篇文章主要介紹了vue3點(diǎn)擊出現(xiàn)彈窗后背景變暗且不可操作的實(shí)現(xiàn)代碼,本文通過實(shí)例代碼圖文相結(jié)合給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2022-08-08
Vue電商網(wǎng)站首頁內(nèi)容吸頂功能實(shí)現(xiàn)過程
電商網(wǎng)站的首頁內(nèi)容會(huì)比較多,頁面比較長,為了能讓用戶在滾動(dòng)瀏覽內(nèi)容的過程中都能夠快速的切換到其它分類。需要分類導(dǎo)航一直可見,所以需要一個(gè)吸頂導(dǎo)航的效果。目標(biāo):完成頭部組件吸頂效果的實(shí)現(xiàn)2023-04-04

