理清Vue响应式系统中的Watcher和Dep的关系

理清Vue响应式系统中的Watcher

[TOC]

引言

在这里我先提出两个问题（文章末尾会进行解答）：

• 在Vue的数据响应系统中，Dep和Watcher各自分担什么任务？
• Vue的数据响应系统的核心是Object.defineproperty必定是最好的吗？有什么弊端和漏洞吗？

1、什么是响应系统中的Watcher，它的做用是什么？

响应系统中的Watcher即这个系统的观察者，它是响应系统中观察者模式的载体，当响应系统中的数据发生改变的时候，它可以知道而且执行相应的函数以达到某种业务逻辑的目的。打个比方，若是你是一个商家，要寄一批货分别给不一样的客户，那么watcher就是一个个快递员，发出的动做就是数据发生改变。你只须要负责寄出去这个动做就好了，如何找到、送到客户则是watcher的事情。

每一个watcher和数据之间的关系要么是1对1，要么是多对多关系（这与watcher的类型有关），watcher和业务逻辑只有1对1关系。

2、Watcher的类型

在Vue源码中是没有体现出Watcher的类型的，我在这里给Watcher添加类型是为了更好地理解Watcher这个对象。Watcher在普通的业务逻辑上能够分为如下三类：

• 普通的Watcher：与数据1对1关系。
• lazy型Watcher：与数据1对1关系，可是它是一个惰性求值的观察者，怎么体现呢？对它进行赋值是不会改变它的值，只有当获取它的值的时候，才会更新最新版的数据（在Vue中体现为computed方法，通常求值是经过方法来求值的）。
• render型Watcher：与数据是1对多（不考虑传参进子组件）的关系，在一个组件中，渲染函数观察者必定是最后生成的，因此执行观察者队列的时候，渲染函数观察者在一个组件中是最后执行的。

在这里多嘴一下lazy型的观察者是怎么回事吧。lazy型观察者在Vue中表现为computed属性，通常这个属性是一个函数，如下是一个例子：

computed: {
  // getCount最后处理成一个属性，而后这个方法被存储在Watcher的某个属性中
  getCount() {
    return this.a + this.b;
  }
}
复制代码

lazy观察者里面有一个dirty属性，也就是一个开关做用，只有它为true的时候使用getCount的getter方法的时候，才会进行调用这个函数。

若是lazy观察者所引用的数据（a或者b属性）发生改变后，会将这个放到观察者队列中，而后执行这个观察者的时候把dirty赋值为true（表明下次访问getter方法的时候会执行一遍lazy的求值方法（求值后会将dirty赋值为false））。等到下一次须要获取这个数据的时候才进行求值，因此它叫作惰性求值。这种方式可以节省没必要要执行函数的开支。

3、Watcher和Dep的关系

看过Vue源码的defineReactive这个方法，就会发现一个被观察的对象里面每一个属性会有一个Dep依赖筐来存放全部观察它的Watcher。而defineReactive方法只有初始化每一个属性的dep却并无建立观察者（要分清初始化和建立观察者是分开这个事实）。那么这个Dep如何添加观察者呢？Vue使用了全局变量，这个变量叫作Dep.target，它是一个Watcher类型的变量，来将Watcher和Dep进行互相绑定。数据的绑定用图来表示的话以下：

咱们能够明确如下区别：

• $watch方法定义的观察者，若是不设定immediate属性，那么是不会进行调用的，而computed和render是会进行调用方法的。
• 数据的Dep的subs数组存放这个数据所绑定的观察者对象，观察者对象的deps数组中存放着与这个观察者有关的数据Dep。因此数据的Dep与Watcher实际上是多对多关系
• $watch和computed观察者是在created生命钩子函数前就建立完毕而且绑定的，而render观察者是在mounted以前建立并绑定的，因此同一个组件中，render观察者的id会大于其余观察者（id是在后面执行队列里面升序排序的时候的依据）。 换句话说，在同一个组件的观察者中，当数据发生改变的时候，渲染函数观察者必定是最后执行的。 这个很好理解，其余观察者中不免会对数据进行修改，若是渲染函数观察者先执行了，而后其余观察者对数据进行改变的话，那么没办法将数据准确呈如今页面上，致使数据不一致性。

4、讲一下观察者执行队列机制

Vue是如何实现性能优化的呢？最显著的两个点：

• 观察者设定执行队列，批量执行。
• diff算法减小渲染开支。

第二个不在这里面讲解，咱们看一下第一个是怎么回事？

这个队列的长度是怎么定量的呢？

• 最大长度是100，源码摆在那里。

• 以一个事件循环时间段为搜集时间。（什么是事件循环？能够看一下本博客系统的其余优秀文章）

它的流程是以下的：

• 未执行时候：若是有更改过数据，那么就将对应的观察者直接推动队列中（执行的时候会进行根据id升序排序后执行）
• 在执行中的时候，若是有新的观察者进来了（观察者中更改数据，而后这个数据又绑定观察者），按照序号升序来进行排序。

5、解答前面的问题

1. Dep是负责存放数据所绑定全部的观察者的对象的容器，只要数据发生改变，就会经过这个Dep来通知全部观察者进行修改数据。（每一个数据都有独一无二的Dep）。而Watcher更偏向于一个动做，也就是规定的业务逻辑或者渲染函数，是一个执行者。
2. 在ES5是很轻便的，很好的。可是在ES6出现后，它就必定不是最好的，由于ES6有一个Proxy代理来统一进行处理。（ES6使用代理实现Vue数据响应系统（TypeScript））
   • 弊端：若是一个数据有1000个属性，那么就要给这1000个属性使用Object.defineProperty，这样在初始化页面的时候会形成卡顿。若是用代理的话，那么只须要执行一次就能够了。
   • 漏洞：若是咱们拿到了vm实例，那么用户是能够在运行的时候经过修改对象属性的描述符（descriptor）来进行修改它，会形成系统的不肯定性。这是由于响应系统的模式致使必须将数据的描述符的configuration设为true，因此在运行的时候可以对它进行修改。

这个问答是我我的阅读完代码后的解答，若是有什么回答错的请指正。