深入理解VuenextTick機制

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

成都創(chuàng)新互聯(lián)是網(wǎng)站建設(shè)技術(shù)企業(yè)，為成都企業(yè)提供專業(yè)的成都網(wǎng)站設(shè)計、做網(wǎng)站，網(wǎng)站設(shè)計，網(wǎng)站制作，網(wǎng)站改版等技術(shù)服務(wù)。擁有十載豐富建站經(jīng)驗和眾多成功案例，為您定制適合企業(yè)的網(wǎng)站。十載品質(zhì)，值得信賴！

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

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

queueWatcher

我們定義 watch 監(jiān)聽 msg ，實際上會被Vue這樣調(diào)用 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)
  }
 }
...

初始設(shè)定 this.deep = this.user = this.lazy = this.sync = false ，也就是當(dāng)觸發(fā) update 更新的時候，會去執(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ù)其實就是 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 變量，這是很重要的一個標(biāo)志位，它保證 flushSchedulerQueue 回調(diào)只允許被置入 callbacks 一次。接下來我們來看看 nextTick 函數(shù)，在說 nexTick 之前，需要你對 Event Loop 、 microTask 、 macroTask 有一定的了解，Vue nextTick 也是主要用到了這些基礎(chǔ)原理。如果你還不了解，可以參考我的這篇文章 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í)行調(diào)用，而何事進行執(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)境下異步回調(diào)最快也是4ms才能觸發(fā)。Vue使用這么多函數(shù)來模擬異步任務(wù)，其目的只有一個，就是讓回調(diào)異步且盡早調(diào)用。而MessageChannel 和 setImmediate 的延遲明顯是小于setTimeout的。

解決問題

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

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

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

因為首先觸發(fā)了 this.msg = 'end' ，導(dǎo)致觸發(fā)了 watcher 的 update ，從而將更新操作callback push進入vue的事件隊列。
this.$nextTick 也為事件隊列push進入了新的一個callback函數(shù)，他們都是通過 setImmediate --> MessageChannel --> Promise --> setTimeout 來定義 timeFunc 。而 Promise.resolve().then 則是microTask，所以會先去打印promise。
在支持 MessageChannel 和 setImmediate 的情況下，他們的執(zhí)行順序是優(yōu)先于 setTimeout 的（在IE11/Edge中，setImmediate延遲可以在1ms以內(nèi)，而setTimeout有最低4ms的延遲，所以setImmediate比setTimeout(0)更早執(zhí)行回調(diào)函數(shù)。其次因為事件隊列里，優(yōu)先收入callback數(shù)組）所以會打印2，接著打印3
但是在不支持 MessageChannel 和 setImmediate 的情況下，又會通過 Promise 定義 timeFunc ,也是老版本Vue 2.4 之前的版本會優(yōu)先執(zhí)行 promise 。這種情況會導(dǎo)致順序成為了：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收納的對象。

后記

如果你對Vue源碼感興趣，可以來這里：更多好玩的Vue約定源碼解釋

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持創(chuàng)新互聯(lián)。

標(biāo)題名稱：深入理解VuenextTick機制
網(wǎng)頁地址：http://www.chinadenli.net/article18/peecgp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供虛擬主機、軟件開發(fā)、自適應(yīng)網(wǎng)站、網(wǎng)站設(shè)計公司、動態(tài)網(wǎng)站、網(wǎng)站改版

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

猜你還喜歡下面的內(nèi)容

欧美一区二区三区老妇人-欧美做爰猛烈大尺度电-99久久夜色精品国产亚洲a-亚洲福利视频一区二区

深入理解VuenextTick機制