Vue nextTick 机制

背景

咱们先来看一段Vue的执行代码:vue

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

这段脚本执行咱们猜想会依次打印:一、二、3。可是实际效果中,只会输出一次:3。为何会出现这样的状况?咱们来一探究竟。git

queueWatcher

咱们定义watch监听msg,实际上会被Vue这样调用vm.$watch(keyOrFn, handler, options)$watch是咱们初始化的时候,为vm绑定的一个函数,用于建立Watcher对象。那么咱们看看Watcher中是如何处理handler的:github

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,也就是当触发update更新的时候,会去执行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函数其实就是watcher的视图更新:promise

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函数,在说nexTick以前,须要你对Event LoopmicroTaskmacroTask有必定的了解,Vue nextTick 也是主要用到了这些基础原理。若是你还不了解,能够参考个人这篇文章Event Loop 简介 好了,下面咱们来看一下他的实现:weex

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数组来模拟事件队列,事件队里的事件,经过nextTickHandler方法来执行调用,而何事进行执行,是由timerFunc来决定的。咱们来看一下timeFunc的定义:dom

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的定义优先顺序macroTask --> microTask,在没有Dom的环境中,使用microTask,好比weex异步

setImmediate、MessageChannel VS setTimeout

咱们是优先定义setImmediateMessageChannel为何要优先用他们建立macroTask而不是setTimeout? HTML5中规定setTimeout的最小时间延迟是4ms,也就是说理想环境下异步回调最快也是4ms才能触发。Vue使用这么多函数来模拟异步任务,其目的只有一个,就是让回调异步且尽早调用。而MessageChannel 和 setImmediate 的延迟明显是小于setTimeout的。async

解决问题

有了这些基础,咱们再看一遍上面提到的问题。由于Vue的事件机制是经过事件队列来调度执行,会等主进程执行空闲后进行调度,因此先回去等待全部的进程执行完成以后再去一次更新。这样的性能优点很明显,好比:ide

如今有这样的一种状况,mounted的时候test的值会被++循环执行1000次。 每次++时,都会根据响应式触发setter->Dep->Watcher->update->run。 若是这时候没有异步更新视图,那么每次++都会直接操做DOM更新视图,这是很是消耗性能的。 因此Vue实现了一个queue队列,在下一个Tick(或者是当前Tick的微任务阶段)的时候会统一执行queueWatcher的run。同时,拥有相同id的Watcher不会被重复加入到该queue中去,因此不会执行1000次Watcher的run。最终更新视图只会直接将test对应的DOM的0变成1000。 保证更新视图操做DOM的动做是在当前栈执行完之后下一个Tick(或者是当前Tick的微任务阶段)的时候调用,大大优化了性能。

有趣的问题

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')
      })
  }
})
复制代码

这个的执行顺序想必你们都知道前后打印:一、promise、二、3。

  1. 由于首先触发了this.msg = 'end',致使触发了watcherupdate,从而将更新操做callback push进入vue的事件队列。

  2. this.$nextTick也为事件队列push进入了新的一个callback函数,他们都是经过setImmediate --> MessageChannel --> Promise --> setTimeout来定义timeFunc。而Promise.resolve().then则是microTask,因此会先去打印promise。

  3. 在支持MessageChannelsetImmediate的状况下,他们的执行顺序是优先于setTimeout的(在IE11/Edge中,setImmediate延迟能够在1ms之内,而setTimeout有最低4ms的延迟,因此setImmediate比setTimeout(0)更早执行回调函数。其次由于事件队列里,优先收入callback数组)因此会打印2,接着打印3

  4. 可是在不支持MessageChannelsetImmediate的状况下,又会经过Promise定义timeFunc,也是老版本Vue 2.4 以前的版本会优先执行promise。这种状况会致使顺序成为了:一、二、promise、3。由于this.msg一定先会触发dom更新函数,dom更新函数会先被callback收纳进入异步时间队列,其次才定义Promise.resolve().then(function () { console.log('promise!')})这样的microTask,接着定义$nextTick又会被callback收纳。咱们知道队列知足先进先出的原则,因此优先去执行callback收纳的对象。

后记

若是你对Vue源码感兴趣,能够来这里:

更多好玩的Vue约定源码解释

参考文章:

Vue.js 升级踩坑小记

【Vue源码】Vue中DOM的异步更新策略以及nextTick机制

相关文章
相关标签/搜索