前言

--以下所有代码来自Vue 2.6.11 版本

--以下的vm都代指vue实例

--文章中讲的 依赖收集 和 派发更新 未涉及到 组件化 的内容，仅限于 根Vue

--这篇文章需配合前面几篇文章食用，请多开几个窗口看源码

贴源码

前面简单梳理了Dep 和 Watcher 之间的关系，这篇文章讲一讲 $mount 挂载，篇幅可能略长。

第一篇文章中简单的梳理过 new Vue 的一个大致流程，也说过了 $mount 方法定义的位置，以及它为什么会定义在两个地方（如果忘了回头看看）

下面再次贴出定义 $mount 的源码，它们在浏览器中实际的运行顺序也是这样的，第一段代码正常定义 $mount ，第二段代码先缓存已经定义好的 $mount，然后再定义一个自己的 mount 方法，也就是比原本的 mount 方法多了一段编译的逻辑（编译的代码有点多，讲的话还得单独拎出来），编译的目的就是生成 render （渲染函数），这个渲染函数在Vue文档里有说明，在平时开发中，我们基本数是使用vue-cli搭建的项目进行开发，vue-loader 已经把编译的事情给做了，所以生产环境的代码中都不会默认是不会有这段编译代码。

定义于 src/platforms/web/runtime/index.js
Vue.prototype.$mount = function (
  el?: string | Element,
  hydrating?: boolean
): Component {
  el = el && inBrowser ? query(el) : undefined
  return mountComponent(this, el, hydrating)
}

定义于 src/platforms/web/entry-runtime-with-compiler.js
const mount = Vue.prototype.$mount
Vue.prototype.$mount = function (
  el?: string | Element,
  hydrating?: boolean
): Component {
  el = el && query(el)
...................
................代码省略 模板编译流程

  return mount.call(this, el, hydrating)
}

总之，最后还是会走到原本的 mount 方法，然后就是 mountComponent 方法，它是定义在这里面的

src/core/instance/lifecycle.js（代码在下方）

省掉一些不太重要的代码和注释，剩下的逻辑发生在 beforeMount 和 mounted 这两个钩子函数之间，熟悉Vue的人都知道，在Vue的整个生命周期中，想要访问到真实的 dom 节点，必须在 mounted 执行时和执行后。

依赖收集

接下来认真了，要紧跟着源码走

1：callHook --- beforeMount

2：updateComponent 函数赋值，那个vm._update也是定义在 src/core/instance/lifecycle.js 中的，它就是 patch 发生的地方，也就是 vnode（没错，就是那个被大家传的很牛皮的虚拟dom） 映射成真实 dom 的地方，具体的细节就先略过了，patch的整个流程挺复杂的.....

3：接下来就是重点了，这里面实例化了一个Watcher，这个watcher就是这个 vm 中唯一的一个 render-watcher（这里就不贴Watcher的源码了，多开个窗口看源码）

4：进入构造函数的逻辑，省略......走到 this.cb = cb，这里的 cb 是个空函数

5：继续省略.....，走到第二个 if 逻辑，this.getter 会被赋值一个 function ，这个function就是外面传进来的 updateComponent 方法

5：继续省略.....，走到最后 this.value = this.lazy ? undefined : this.get()，这里的 this.lazy 是false，除了computed（计算属性）会设置为 true，其他的watcher都是false

6：进入 get 方法，划重点，pushTarget(this)，前面介绍 Dep 的时候简单提过这个方法，它和 Dep 定义在同一个文件中，执行方法当前的这个 render-watcher会压栈，然后 Dep.target 这个静态变量，会赋值为当前的 render-watcher。包括后面会讲的 computed 和 watch，它们都会通过这种压栈的方式来达到 依赖收集 的目的

7：然后走到  value = this.getter.call(vm, vm) 这里，（call方法的作用就不说了，不懂就去查）这里会执行 this.getter方法，前面说过，this.getter就是外部传进来的那个 updateComponent 方法

8：此时回到 mountComponent  代码中，看到 updateComponent 被赋值那个地方，它在watcher中被执行了

9：vm._render （src/core/instance/render.js）是一个实例方法（这里不细说），它执行的过程中会生成 vnode，而生成vnode的过程中就会就会发生 依赖收集 ，想要获取 data/props 中的值，就会触发 defintReactive 中的 get 逻辑

10：回过头打开 defineReactive 的源码查看，看到 Object.defineProperty 的get逻辑，第一步求值 value ，注意此时的 Dep.target 就是上面赋值的 render-watcher

11：进入 if 逻辑，执行dep.depend，打开 Dep 源码进到方法中去，走到 addDep（this），addDep方法中可以先忽略掉 newDeps那些操作，（那是Vue为了优化所做的一些事情，下面讲到派发更新的时候再回顾这里）。然后走完 dep.addSub(this) 的逻辑，至此，Dep 和 Watcher正式建立联系，也代表 vm 中 data/props 的数据和render-watcher（视图）建立了依赖关系

12：最后，假设代码没报错，get 方法正常走到 finally，this.deep 默认是false，这里的render-watcher也不需要 deep 为 true（后面讲watch的时候应该能用上），然后就是 popTarget 出栈，它和上面所讲的 pushTarget 是成对操作，有压栈就得有出栈，不然依赖收集就会乱套

13：接着 cleanupDeps ，它是干嘛的？清除依赖，这里是初次 依赖收集 ，暂时没用，下面说完 派发更新 后再单独说说这个方法。

14：get 逻辑走完，new Watcher 完毕，接着执行 mounted 钩子（此处的mounted仅仅只是 root-vm 的钩子，至于组件的mounted在其他的地方，已经先于 root-vm 的mounted执行了），整个 new Vue 的工作正式走完。

export function mountComponent (
  vm: Component,
  el: ?Element,
  hydrating?: boolean
): Component {
  vm.$el = el
  .....代码省略
  callHook(vm, 'beforeMount')

  let updateComponent
  /* istanbul ignore if */
  if (process.env.NODE_ENV !== 'production' && config.performance && mark) {
    updateComponent = () => {
      ......  埋点操作
      vm._update(vnode, hydrating)
      ....... 埋点操作 
    }
  } else {
    updateComponent = () => {
      vm._update(vm._render(), hydrating)
    }
  }
  new Watcher(vm, updateComponent, noop, {
    before () {
      if (vm._isMounted && !vm._isDestroyed) {
        callHook(vm, 'beforeUpdate')
      }
    }
  }, true /* isRenderWatcher */)
  hydrating = false
  if (vm.$vnode == null) {
    vm._isMounted = true
    callHook(vm, 'mounted')
  }
  return vm
}

派发更新

上面已经梳理完整个 依赖收集 的过程，接下来就是 派发更新 的过程。

我们回头看着 defineReactive 代码中 Object.defineProperty的set逻辑，假设 我们的 $mount 过程已经走完了，视图已经生成完毕，页面已经展示出来,并且代码逻辑如下所示：

1：点击按钮触发事件，改变 this.name

<template>
  <div>
     <button @click='onClick'>change</button>
     <span>{{name}}</span>
  </div>
</template>
<script>
  export default {
    data(){
      return {
        name:'123'
      }
    },
    methods:{
      onClick(){
        this.name = new Date().getTime()+'';
      }
    }
  }
</script>

2：打开 defineReactive 的代码，看到 Object.defineProperty的set逻辑，前面的 依赖收集已经建立好了 view 和 data 的依赖，这时候修改this.name就会触发 set 逻辑

3：首先，求值得到 value，然后 newVal（新值） 和 value（旧值）比较，如果两个值相等就不往下走了，也就不会触发视图改变

4：如果新旧值不一样，就接着走，customSetter 方法，这个东西为了在开发环境下为了防止用户修改 props 中的值，传入的警告方法，就只是警告而已，生产环境就直接忽略掉

5：然后，val（旧值）被正式修改掉，接着 observe 方法，最后触发 notify （通知），通知谁呢？通知依赖当前 value 的 watcher

6：查看 Dep 的源码，notify中会遍历 watcher 数组，挨个执行 update 方法

7：查看 Watcher 的update方法，有三段逻辑，第一个是给 computed（计算属性）用的，此处略过；第二个是同步更新视图，this.sync一般都为 false ，仔细想想，如果 data 数据更新过于频繁，视图也会频繁的更新，影响性能就不好了

8： queueWatcher 这里就不深入查看了，简单了解一下，这个方法是在搜集render-watcher，放入到一个队列中，再将队列中watcher的视图更新操作全部放到下一个事件循环中进行（它和Vue常常使用的 $nextTick 有关，涉及到 EventLoop 知识点，不懂就去查阅），这个过程中做了一些优化处理，就是去重（通过每个watcher都有 且唯一的 watcher.id），每个render-watcher可以同时监听很多个 Dep ，当多个 Dep 触发 notify 通知了同一个 render-watcher，如果不做去重，就会搜集到很多重复的watcher，到时候视图渲染也会出现无用的重复渲染工作

9：总之，正常情况下最后会去执行render-watcher的 run 方法。打开Watcher源码，进入 run 方法

this.active 默认是为 true，虽然它也会有为false的时候，不过这里咱就不讨论了。然后顺利执行 get 逻辑，这里是新的一轮 依赖收集 ，里面就是我们已经熟悉过，render过程以及压栈出栈操作。接着下面一段 if 逻辑这里是进不去的，那和 watch 的深度依赖有关

10：至此，派发更新 的操作走到这里就完了，get 逻辑完成后视图就已经渲染完毕了

cleanupDeps

上面的 依赖收集 的过程中我们注意到这个方法，它的代码虽然不多，但却是Vue的在细节上的优化。平时开发中经常会遇到这样的情况，代码如下：

<template>
    <div class="hello">
        <button @click="isShow=!isShow">change</button>
        <div v-if="isShow">
            {{person1}}
        </div>
        <div v-else>
            {{person2}}
        </div>
    </div>
</template>
<script>
new Vue({
    el:'#app',
    data:{
        person1: 'Tifa',
        person2: 'Cloud',
        isShow: true
    }
})
</script>

通过 v-if 渲染不同的视图，初始化的情况下，person1 会和 render-watcher 建立依赖，person2 不会，因为 isShow 为true，在执行 render 函数的时候，v-else 那块儿逻辑是不会进去的，也就无法触发 defineReactive 的 get 逻辑，由于是第一次收集依赖，此时的 cleanupDeps 是没啥作用的，render-watcher中的那些newDeps newDepIds depIds deps 都是空的，清不清除依赖都一样。

但是，当点击按钮的时候，isShow被修改然后触发 set 逻辑，也就是 派发更新，最后会走到 render-watcher 的 get 方法，开始新的一轮 依赖收集，这一轮在收集的时候，person2 就可以顺利的和 render-watcher 建立依赖；此时，新的一轮依赖收集完毕（进入Watcher源码查看 addDep中是如何收集的），newDeps 和 newDepIds 都有 person2 的dep记录，deps 和 depIds中还保留着 person1 的dep记录。

进入 cleanupDeps 方法中，while 逻辑首先会清除掉当前 render-watcher 中所有的旧依赖关系，也就是和 person1 之间建立的依赖，在这里被清除掉了；当然，也不是无脑清除，会先判断 newDepIds 中有没有，有就不清除了，毕竟这玩意儿（newDepIds）是新一轮 依赖收集建立的最新的依赖，不能删除。

接着下面的那段代码就是一个互换的操作了，deps/depIds 和 newDeps/newDepIds 互换，然后清空 newDeps/newDepIds 的数据，这样deps/depIds就保存着最新的依赖关系，这个时候 person1 就已经和 render-watcher没有关系了，现在不管我们在代码中如何花式修改 this.person1 ，都不会触发 render-watcher 的视图更新。这是一个很棒的优化，避免了很多无效的 视图更新 操作。

总结

以上，再结合前面几篇文章，就完整的走通了响应式原理的流程，后面会讲的 组件化 computed watch  它们的整个流程其实和这里是差不多的。

现在回过头看看这里的最后一张图片，整个流程就比较清晰了。