摘要：而和的延遲明顯是小于的。因為的事件機制是通過事件隊列來調度執(zhí)行，會等主進程執(zhí)行空閑后進行調度，所以先回去等待所有的進程執(zhí)行完成之后再去一次更新。因為首先觸發(fā)了，導致觸發(fā)了的，從而將更新操作進入的事件隊列。這種情況會導致順序成為了。

我們先來看一段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í)行我們猜測1000m后會依次打?。?、2、3。但是實際效果中，只會輸出一次：3。為什么會出現(xiàn)這樣的情況？我們來一探究竟。

我們定義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 = []
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()
    ...
  }
}

另外，關于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

我們是優(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í)行順序想必大家都知道先后打?。?、promise、2、3。

因為首先觸發(fā)了this.msg = "end"，導致觸發(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以內，而setTimeout有最低4ms的延遲，所以setImmediate比setTimeout(0)更早執(zhí)行回調函數(shù)。其次因為事件隊列里，優(yōu)先收入callback數(shù)組）所以會打印2，接著打印3

但是在不支持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收納的對象。

如果你對Vue源碼感興趣，可以來這里：

更多好玩的Vue約定源碼解釋

參考文章：

Vue.js 升級踩坑小記

【Vue源碼】Vue中DOM的異步更新策略以及nextTick機制