Vue你不得不知道的异步更新机制和nextTick原理

前言

异步更新是 Vue 核心实现之一，在整体流程中充当着 watcher 更新的调度者这一角色。大部分 watcher 更新都会经过它的处理，在适当时机让更新有序的执行。而 nextTick 作为异步更新的核心，也是需要学习的重点。

本文你能学习到：

• 异步更新的作用
• nextTick原理
• 异步更新流程

JS运行机制

在理解异步更新前，需要对JS运行机制有些了解，如果你已经知道这些知识，可以选择跳过这部分内容。

JS 执行是单线程的，它是基于事件循环的。事件循环大致分为以下几个步骤：

1. 所有同步任务都在主线程上执行，形成一个执行栈（execution context stack）。
2. 主线程之外，还存在一个"任务队列"（task queue）。只要异步任务有了运行结果，就在"任务队列"之中放置一个事件。
3. 一旦"执行栈"中的所有同步任务执行完毕，系统就会读取"任务队列"，看看里面有哪些事件。那些对应的异步任务，于是结束等待状态，进入执行栈，开始执行。
4. 主线程不断重复上面的第三步。

“任务队列”中的任务(task)被分为两类，分别是宏任务(macro task)和微任务(micro task)

宏任务：在一次新的事件循环的过程中，遇到宏任务时，宏任务将被加入任务队列，但需要等到下一次事件循环才会执行。常见的宏任务有 setTimeout、setImmediate、requestAnimationFrame

微任务：当前事件循环的任务队列为空时，微任务队列中的任务就会被依次执行。在执行过程中，如果遇到微任务，微任务被加入到当前事件循环的微任务队列中。简单来说，只要有微任务就会继续执行，而不是放到下一个事件循环才执行。常见的微任务有 MutationObserver、Promise.then

总的来说，在事件循环中，微任务会先于宏任务执行。而在微任务执行完后会进入浏览器更新渲染阶段，所以在更新渲染前使用微任务会比宏任务快一些。

关于事件循环和浏览器渲染可以看下 晨曦时梦见兮 大佬的文章 《深入解析你不知道的 EventLoop 和浏览器渲染、帧动画、空闲回调（动图演示）》

为什么需要异步更新

既然异步更新是核心之一，首先要知道它的作用是什么，解决了什么问题。

先来看一个很常见的场景：

created(){
    this.id = 10
    this.list = []
    this.info = {}
}

总所周知， Vue 基于数据驱动视图，数据更改会触发 setter 函数，通知 watcher 进行更新。如果像上面的情况，是不是代表需要更新3次，而且在实际开发中的更新可不止那么少。更新过程是需要经过繁杂的操作，例如模板编译、dom diff，频繁进行更新的性能当然很差。

Vue 作为一个优秀的框架，当然不会那么“直男”，来多少就照单全收。 Vue 内部实际是将 watcher 加入到一个 queue 数组中，最后再触发 queue 中所有 watcher 的 run 方法来更新。并且加入 queue 的过程中还会对 watcher 进行去重操作，因为在一个 vue 实例中 data 内定义的数据都是存储同一个 “渲染 watcher ”，所以以上场景中数据即使更新了3次，最终也只会执行一次更新页面的逻辑。

为了达到这种效果， Vue 使用异步更新，等待所有数据同步修改完成后，再去执行更新逻辑。

nextTick 原理

异步更新内部是最重要的就是 nextTick 方法，它负责将异步任务加入队列和执行异步任务。 Vue 也将它暴露出来提供给用户使用。在数据修改完成后，立即获取相关DOM还没那么快更新，使用 nextTick 便可以解决这一问题。

认识 nextTick

官方文档对它的描述：

在下次 DOM 更新循环结束之后执行延迟回调。在修改数据之后立即使用这个方法，获取更新后的 DOM。

// 修改数据
vm.msg = 'Hello'
// DOM 还没有更新
Vue.nextTick(function () {
  // DOM 更新了
})

// 作为一个 Promise 使用 (2.1.0 起新增，详见接下来的提示)
Vue.nextTick()
  .then(function () {
    // DOM 更新了
  })

nextTick 使用方法有回调和Promise两种，以上是通过构造函数调用的形式，更常见的是在实例调用 this.$nextTick 。它们都是同一个方法。

内部实现

在 Vue 源码 2.5+ 后， nextTick 的实现单独有一个 JS 文件来维护它，它的源码并不复杂，代码实现不过100行，稍微花点时间就能啃下来。源码位置在 src/core/util/next-tick.js ，接下来我们来看一下它的实现，先从入口函数开始：

export function nextTick (cb?: Function, ctx?: Object) {
  let _resolve
  // 1
  callbacks.push(() => {
    if (cb) {
      try {
        cb.call(ctx)
      } catch (e) {
        handleError(e, ctx, 'nextTick')
      }
    } else if (_resolve) {
      _resolve(ctx)
    }
  })
  // 2
  if (!pending) {
    pending = true
    timerFunc()
  }
  // $flow-disable-line
  // 3
  if (!cb && typeof Promise !== 'undefined') {
    return new Promise(resolve => {
      _resolve = resolve
    })
  }
}

1. cb 即传入的回调，它被 push 进一个 callbacks 数组，等待调用。
2. pending 的作用就是一个锁，防止后续的 nextTick 重复执行 timerFunc 。 timerFunc 内部创建会一个微任务或宏任务，等待所有的 nextTick 同步执行完成后，再去执行 callbacks 内的回调。
3. 如果没有传入回调，用户可能使用的是 Promise 形式，返回一个 Promise ， _resolve 被调用时进入到 then 。

继续往下走看看 timerFunc 的实现：

// Here we have async deferring wrappers using microtasks.
// In 2.5 we used (macro) tasks (in combination with microtasks).
// However, it has subtle problems when state is changed right before repaint
// (e.g. #6813, out-in transitions).
// Also, using (macro) tasks in event handler would cause some weird behaviors
// that cannot be circumvented (e.g. #7109, #7153, #7546, #7834, #8109).
// So we now use microtasks everywhere, again.
// A major drawback of this tradeoff is that there are some scenarios
// where microtasks have too high a priority and fire in between supposedly
// sequential events (e.g. #4521, #6690, which have workarounds)
// or even between bubbling of the same event (#6566).
let timerFunc

// The nextTick behavior leverages the microtask queue, which can be accessed
// via either native Promise.then or MutationObserver.
// MutationObserver has wider support, however it is seriously bugged in
// UIWebView in iOS >= 9.3.3 when triggered in touch event handlers. It
// completely stops working after triggering a few times... so, if native
// Promise is available, we will use it:
/* istanbul ignore next, $flow-disable-line */
if (typeof Promise !== 'undefined' && isNative(Promise)) {
  const p = Promise.resolve()
  timerFunc = () => {
    p.then(flushCallbacks)
    // In problematic UIWebViews, Promise.then doesn't completely break, but
    // it can get stuck in a weird state where callbacks are pushed into the
    // microtask queue but the queue isn't being flushed, until the browser
    // needs to do some other work, e.g. handle a timer. Therefore we can
    // "force" the microtask queue to be flushed by adding an empty timer.
    if (isIOS) setTimeout(noop)
  }
  isUsingMicroTask = true
} else if (!isIE && typeof MutationObserver !== 'undefined' && (
  isNative(MutationObserver) ||
  // PhantomJS and iOS 7.x
  MutationObserver.toString() === '[object MutationObserverConstructor]'
)) {
  // Use MutationObserver where native Promise is not available,
  // e.g. PhantomJS, iOS7, Android 4.4
  // (#6466 MutationObserver is unreliable in IE11)
  let counter = 1
  const observer = new MutationObserver(flushCallbacks)
  const textNode = document.createTextNode(String(counter))
  observer.observe(textNode, {
    characterData: true
  })
  timerFunc = () => {
    counter = (counter + 1) % 2
    textNode.data = String(counter)
  }
  isUsingMicroTask = true
} else if (typeof setImmediate !== 'undefined' && isNative(setImmediate)) {
  // Fallback to setImmediate.
  // Technically it leverages the (macro) task queue,
  // but it is still a better choice than setTimeout.
  timerFunc = () => {
    setImmediate(flushCallbacks)
  }
} else {
  // Fallback to setTimeout.
  timerFunc = () => {
    setTimeout(flushCallbacks, 0)
  }
}

上面的代码并不复杂，主要通过一些兼容判断来创建合适的 timerFunc ，最优先肯定是微任务，其次再到宏任务。优先级为 promise.then > MutationObserver > setImmediate > setTimeout 。（源码中的英文说明也很重要，它们能帮助我们理解设计的意义）

我们会发现无论哪种情况创建的 timerFunc ，最终都会执行一个 flushCallbacks 的函数。

const callbacks = []
let pending = false

function flushCallbacks () {
  pending = false
  const copies = callbacks.slice(0)
  callbacks.length = 0
  for (let i = 0; i < copies.length; i++) {
    copies[i]()
  }
}

flushCallbacks 里做的事情 so easy，它负责执行 callbacks 里的回调。

好了， nextTick 的源码就那么多，现在已经知道它的实现，下面再结合异步更新流程，让我们对它更充分的理解吧。

异步更新流程

数据被改变时，触发 watcher.update

// 源码位置：src/core/observer/watcher.js
update () {
  /* istanbul ignore else */
  if (this.lazy) {
    this.dirty = true
  } else if (this.sync) {
    this.run()
  } else {
    queueWatcher(this) // this 为当前的实例 watcher
  }
}

调用 queueWatcher ，将 watcher 加入队列

// 源码位置：src/core/observer/scheduler.js
const queue = []
let has = {}
let waiting = false
let flushing = false
let index = 0

export function queueWatcher (watcher: Watcher) {
  const id = watcher.id
  // 1
  if (has[id] == null) {
    has[id] = true
    // 2
    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
    // 3
    if (!waiting) {
      waiting = true
      nextTick(flushSchedulerQueue)
    }
  }
}

1. 每个 watcher 都有自己的 id ，当 has 没有记录到对应的 watcher ，即第一次进入逻辑，否则是重复的 watcher , 则不会进入。这一步就是实现 watcher 去重的点。
2. 将 watcher 加入到队列中，等待执行
3. waiting 的作用是防止 nextTick 重复执行

flushSchedulerQueue 作为回调传入 nextTick 异步执行。

function flushSchedulerQueue () {
  currentFlushTimestamp = getNow()
  flushing = true
  let watcher, id

  // Sort queue before flush.
  // This ensures that:
  // 1. Components are updated from parent to child. (because parent is always
  //    created before the child)
  // 2. A component's user watchers are run before its render watcher (because
  //    user watchers are created before the render watcher)
  // 3. If a component is destroyed during a parent component's watcher run,
  //    its watchers can be skipped.
  queue.sort((a, b) => a.id - b.id)

  // do not cache length because more watchers might be pushed
  // as we run existing watchers
  for (index = 0; index < queue.length; index++) {
    watcher = queue[index]
    if (watcher.before) {
      watcher.before()
    }
    id = watcher.id
    has[id] = null
    watcher.run()
  }

  // keep copies of post queues before resetting state
  const activatedQueue = activatedChildren.slice()
  const updatedQueue = queue.slice()

  resetSchedulerState()

  // call component updated and activated hooks
  callActivatedHooks(activatedQueue)
  callUpdatedHooks(updatedQueue)
}

flushSchedulerQueue 内将刚刚加入 queue 的 watcher 逐个 run 更新。 resetSchedulerState 重置状态，等待下一轮的异步更新。

function resetSchedulerState () {
  index = queue.length = activatedChildren.length = 0
  has = {}
  if (process.env.NODE_ENV !== 'production') {
    circular = {}
  }
  waiting = flushing = false
}

要注意此时 flushSchedulerQueue 还未执行，它只是作为回调传入而已。因为用户可能也会调用 nextTick 方法。这种情况下， callbacks 里的内容为 ["flushSchedulerQueue", "用户的nextTick回调"]，当所有同步任务执行完成，才开始执行 callbacks 里面的回调。

由此可见，最先执行的是页面更新的逻辑，其次再到用户的 nextTick 回调执行。这也是为什么我们能在 nextTick 中获取到更新后DOM的原因。

总结

异步更新机制使用微任务或宏任务，基于事件循环运行，在 Vue 中对性能起着至关重要的作用，它对重复冗余的 watcher 进行过滤。而 nextTick 根据不同的环境，使用优先级最高的异步任务。这样做的好处是等待所有的状态同步更新完毕后，再一次性渲染页面。用户创建的 nextTick 运行页面更新之后，因此能够获取更新后的DOM。