浅析Vue批量更新原理__Vue.js

粉丝福利 : 关注VUE中文社区公众号，回复视频领取粉丝福利

)

首先看这个例子中，连续3次触发了mutation，那么watch中的cb会被执行几次呢？

答案是一次。

那么为什么会是一次呢？本文会围绕着这个问题的解释来粗浅地讨论一下Vue中批量更新的原理。

首先要知道，msg这个key，是通过Object.defineProperty被监听了的，Vue通过这个api实现在key被set的时候（也就是this.msg = xxx这种操作），触发所有订阅了这个key的Watcher的update方法。

这里引入了一个Watcher的概念，那么这个Watcher是什么呢？

从语义上理解，Wathcer其实类似于一个key的观察者，当key被set的时候，Watcher会调用自身的update方法。

这样说会有点抽象，在这个具体例子中的话就是msg被set了不同的值，那么watch这个option产生的Watcher就会执行自己原型上的update方法，这个方法最终的目的是执行实例上的cb，即msg对应的console.log(‘监听到mutation’)的这个方法。

只需知道对msg这个key进行set操作的时候可以拿到key的所有Watcher就可以了，Watcher是怎么生成的，为什么set操作的时候可以拿到所有的Watcher，不在这篇文章的讨论范围。

问题的关键在Watcher执行的update方法，这个方法前面说过是为了执行cb，在这个例子中就是console.log(‘监听到mutation’)，但是首先思考一个问题：

我们可以监听到一个set引起的mutation就立即同步执行一次cb吗？

显然是不可以的。

举个例子：

for (let i = 0; i < 1000; i++) {
   this.msg = `循环了${i}次`;
}

假如对于这种操作，1000次里面每次Watcher都要响应执行一次update，那可能是有很大的性能开销的。像本文的这个例子中update其实就是一个console.log，但是如果cb是一个开销比较大的方法，那么就可能会引起性能问题了。

所以update操作一定是异步的。

虽然知道要通过异步来解决，但具体是如何解决的呢？Vue的做法是把调用cb放到了一个micro task或者macro task队列中，具体放到微任务队列还是宏任务队列要看当前的运行环境是否支持Promise、MutationObserver、setImmediate这几个相当于放入微任务队列的api，支持就会放在微任务队列，不支持则使用setTimeout这个api把调用cb放到宏任务队列里。

不管放到微任务队列还是宏任务队列，调用cb都会在所有的同步代码执行完毕后执行。这一点涉及到event loop的知识，因为总是先执行所有的同步代码，然后从微任务队列中按顺序执行，微任务队列空了才会从宏任务队列中取出一条执行。如果此时微任务队列还有任务，那么就会继续按照这个循环执行，这个就是event loop。

通俗地理解Vue的行为就是在监听到key的mutation之后key的Watcher都会触发update，想要调用自身的cb属性，但是Vue仅仅是答应会在未来的某个时刻执行Watcher的这个update请求也就是调用它的cb，并且在调用之前都不会再受理该Watcher的update的请求。

下面看看源码（P.S. 第一次看源码的话，vue-cli生成的项目，生效的源码就在node_modules/vue/dist/vue.runtime.esm.js）：

function queueWatcher (watcher) {
  var 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.
      var 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);
    }
  }
}

首先queueWatcher就是Watcher执行update方法的时候做的事情，我们注意到有三个flag，has[id]、flushing和waiting，我们主要通过探究这三个flag的意义来理解这段源码。

我们对msg进行了3次set操作，对应三次Watcher的update方法，对应三次queueWatcher，而这三次排队每次传的参数，都是同一个Watcher实例，所以第一次has[id]才为null，第一次置为true之后，后面的两次就直接结束了。其实通俗地解释就是，第一次触发mutation，到Vue这就会告诉你，已经加入到队列了，后面就会处理，同一个Watcher的其他mutation就不再接待了。

那么首次mutation其实会把Wathcer实例加入到queue队列里，然后在未来的某个时间，会遍历queue并调用所有Watcher实例的cb。

关于flushing这个变量，其实我们看这个if else，在if分支watcher会被放到队列末尾，而else分支其实会按照watcher的id放到queue的相应位置，queue中的所有watcher是按照Id升序排列的，而如果这个id的watcher已经被执行过了，那么就会被放到队列的下一项，下个就执行该watcher的cb。

其实可以看出来flushing就是为了保证queue中的所有watcher的顺序永远都是按id升序的，为什么要这么做呢？Vue源码里给了三点注释：

  // 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.

大致说的是为了保证父子组件按照顺序执行update、用户创建的wathcer（像这个例子中在watch这个option中监听msg就会创建一个user wathcer）在render watcher之前执行、在父组件的watcher run的时候销毁了子组件，那么子组件的watcher就不会被执行了。

这里我觉得知道queue中所有watcher是按照id升序排列的，而id是创建watcher时自增的就够了，具体为什么这么干以后遇到具体场景就理解了。

最后是waiting这个变量，这个变量很简单，就是保证完成一次对queue的遍历之前不会开启新的遍历。

OK，源码大致看过了，再回到示例代码过一遍流程：

首先三次set，三次mutation，三次Watcher的update，一次往queue中push watcher，一次加入把flushSchedulerQueue加入到task队列，一次遍历queue调用watcher的cb，即一次输出"监听到mutation"。