vue源码学习

Vue 变化侦测

Object 变化侦测

Vue 变化生命周期 使Object数据变得“可观测”
数据的每次读和写能够被我们看的见，即我们能够知道数据什么时候被读取了或数据什么时候被改写了，我们将其称为数据变的‘可观测’。

要将数据变的‘可观测’，我们就要借助前言中提到的Object.defineProperty方法了，在本文中，我们就使用这个方法使数据变得“可观测”。

首先，我们定义一个数据对象car：

let car = {
     
  'brand':'BMW',
  'price':3000
}

我们定义了这个car的品牌brand是BMW,价格price是3000。现在我们可以通过car.brand和car.price直接读写这个car对应的属性值。但是，当这个car的属性被读取或修改时，我们并不知情。那么应该如何做才能够让car主动告诉我们，它的属性被修改了呢？

接下来，我们使用Object.defineProperty()改写上面的例子：

let car = {
     }
let val = 3000
Object.defineProperty(car, 'price', {
     
  enumerable: true,
  configurable: true,
  get(){
     
    console.log('price属性被读取了')
    return val
  },
  set(newVal){
     
    console.log('price属性被修改了')
    val = newVal
  }
})

通过Object.defineProperty()方法给car定义了一个price属性，并把这个属性的读和写分别使用get()和set()进行拦截，每当该属性进行读或写操作的时候就会触发get()和set()。如下图：

可以看到，car已经可以主动告诉我们它的属性的读写情况了，这也意味着，这个car的数据对象已经是“可观测”的了。

为了把car的所有属性都变得可观测，我们可以编写如下代码：

// 源码位置：src/core/observer/index.js

/**
 * Observer类会通过递归的方式把一个对象的所有属性都转化成可观测对象
 */
export class Observer {
     
  constructor (value) {
     
    this.value = value
    // 给value新增一个__ob__属性，值为该value的Observer实例
    // 相当于为value打上标记，表示它已经被转化成响应式了，避免重复操作
    def(value,'__ob__',this)
    if (Array.isArray(value)) {
     
      // 当value为数组时的逻辑
      // ...
    } else {
     
      this.walk(value)
    }
  }

  walk (obj: Object) {
     
    const keys = Object.keys(obj)
    for (let i = 0; i < keys.length; i++) {
     
      defineReactive(obj, keys[i])
    }
  }
}
/**
 * 使一个对象转化成可观测对象
 * @param { Object } obj 对象
 * @param { String } key 对象的key
 * @param { Any } val 对象的某个key的值
 */
function defineReactive (obj,key,val) {
     
  // 如果只传了obj和key，那么val = obj[key]
  if (arguments.length === 2) {
     
    val = obj[key]
  }
  if(typeof val === 'object'){
     
      new Observer(val)
  }
  Object.defineProperty(obj, key, {
     
    enumerable: true,
    configurable: true,
    get(){
     
      console.log(`${
       key}属性被读取了`);
      return val;
    },
    set(newVal){
     
      if(val === newVal){
     
          return
      }
      console.log(`${
       key}属性被修改了`);
      val = newVal;
    }
  })
}

在上面的代码中，我们定义了observer类，它用来将一个正常的object转换成可观测的object。

并且给value新增一个__ob__属性，值为该value的Observer实例。这个操作相当于为value打上标记，表示它已经被转化成响应式了，避免重复操作

然后判断数据的类型，只有object类型的数据才会调用walk将每一个属性转换成getter/setter的形式来侦测变化。 最后，在defineReactive中当传入的属性值还是一个object时使用new observer（val）来递归子属性，这样我们就可以把obj中的所有属性（包括子属性）都转换成getter/seter的形式来侦测变化。 也就是说，只要我们将一个object传到observer中，那么这个object就会变成可观测的、响应式的object。

observer类位于源码的src/core/observer/index.js中。

那么现在，我们就可以这样定义car:

let car = new Observer({
     
  'brand':'BMW',
  'price':3000
})

这样，car的两个属性都变得可观测了。

依赖收集
什么是依赖收集？在上一章中，我们迈出了第一步：让object数据变的可观测。变的可观测以后，我们就能知道数据什么时候发生了变化，那么当数据发生变化时，我们去通知视图更新就好了。那么问题又来了，视图那么大，我们到底该通知谁去变化？总不能一个数据变化了，把整个视图全部更新一遍吧，这样显然是不合理的。此时，你肯定会想到，视图里谁用到了这个数据就更新谁呗。对！你想的没错，就是这样。

视图里谁用到了这个数据就更新谁，我们换个优雅说法：我们把"谁用到了这个数据"称为"谁依赖了这个数据",我们给每个数据都建一个依赖数组(因为一个数据可能被多处使用)，谁依赖了这个数据(即谁用到了这个数据)我们就把谁放入这个依赖数组中，那么当这个数据发生变化的时候，我们就去它对应的依赖数组中，把每个依赖都通知一遍，告诉他们：“你们依赖的数据变啦，你们该更新啦！”。这个过程就是依赖收集。

何时收集依赖？何时通知依赖更新？
明白了什么是依赖收集后，那么我们到底该在何时收集依赖？又该在何时通知依赖更新？

其实这个问题在上一小节中已经回答了，我们说过：谁用到了这个数据，那么当这个数据变化时就通知谁。所谓谁用到了这个数据，其实就是谁获取了这个数据，而可观测的数据被获取时会触发getter属性，那么我们就可以在getter中收集这个依赖。同样，当这个数据变化时会触发setter属性，那么我们就可以在setter中通知依赖更新。

总结一句话就是：在getter中收集依赖，在setter中通知依赖更新。

把依赖收集到哪里
明白了什么是依赖收集以及何时收集何时通知后，那么我们该把依赖收集到哪里？

我们给每个数据都建一个依赖数组，谁依赖了这个数据我们就把谁放入这个依赖数组中。单单用一个数组来存放依赖的话，功能好像有点欠缺并且代码过于耦合。我们应该将依赖数组的功能扩展一下，更好的做法是我们应该为每一个数据都建立一个依赖管理器，把这个数据所有的依赖都管理起来。OK，到这里，我们的依赖管理器Dep类应运而生，代码如下：

// 源码位置：src/core/observer/dep.js
export default class Dep {
     
  constructor () {
     
    this.subs = []
  }

  addSub (sub) {
     
    this.subs.push(sub)
  }
  // 删除一个依赖
  removeSub (sub) {
     
    remove(this.subs, sub)
  }
  // 添加一个依赖
  depend () {
     
    if (window.target) {
     
      this.addSub(window.target)
    }
  }
  // 通知所有依赖更新
  notify () {
     
    const subs = this.subs.slice()
    for (let i = 0, l = subs.length; i < l; i++) {
     
      subs[i].update()
    }
  }
}

/**
 * Remove an item from an array
 */
export function remove (arr, item) {
     
  if (arr.length) {
     
    const index = arr.indexOf(item)
    if (index > -1) {
     
      return arr.splice(index, 1)
    }
  }
}

在上面的依赖管理器Dep类中，我们先初始化了一个subs数组，用来存放依赖，并且定义了几个实例方法用来对依赖进行添加，删除，通知等操作。

有了依赖管理器后，我们就可以在getter中收集依赖，在setter中通知依赖更新了，代码如下：

function defineReactive (obj,key,val) {
     
  if (arguments.length === 2) {
     
    val = obj[key]
  }
  if(typeof val === 'object'){
     
    new Observer(val)
  }
  const dep = new Dep()  //实例化一个依赖管理器，生成一个依赖管理数组dep
  Object.defineProperty(obj, key, {
     
    enumerable: true,
    configurable: true,
    get(){
     
      dep.depend()    // 在getter中收集依赖
      return val;
    },
    set(newVal){
     
      if(val === newVal){
     
          return
      }
      val = newVal;
      dep.notify()   // 在setter中通知依赖更新
    }
  })
}

在上述代码中，我们在getter中调用了dep.depend()方法收集依赖，在setter中调用dep.notify()方法通知所有依赖更新。

依赖到底是谁
通过上一章节，我们明白了什么是依赖？何时收集依赖？以及收集的依赖存放到何处？那么我们收集的依赖到底是谁？

虽然我们一直在说”谁用到了这个数据谁就是依赖“，但是这仅仅是在口语层面上，那么反应在代码上该如何来描述这个”谁“呢？

其实在Vue中还实现了一个叫做Watcher的类，而Watcher类的实例就是我们上面所说的那个"谁"。换句话说就是：谁用到了数据，谁就是依赖，我们就为谁创建一个Watcher实例。在之后数据变化时，我们不直接去通知依赖更新，而是通知依赖对应的Watch实例，由Watcher实例去通知真正的视图。

Watcher类的具体实现如下：

export default class Watcher {
     
  constructor (vm,expOrFn,cb) {
     
    this.vm = vm;
    this.cb = cb;
    this.getter = parsePath(expOrFn)
    this.value = this.get()
  }
  get () {
     
    window.target = this;
    const vm = this.vm
    let value = this.getter.call(vm, vm)
    window.target = undefined;
    return value
  }
  update () {
     
    const oldValue = this.value
    this.value = this.get()
    this.cb.call(this.vm, this.value, oldValue)
  }
}

/**
 * Parse simple path.
 * 把一个形如'data.a.b.c'的字符串路径所表示的值，从真实的data对象中取出来
 * 例如：
 * data = {a:{b:{c:2}}}
 * parsePath('a.b.c')(data)  // 2
 */
const bailRE = /[^\w.$]/
export function parsePath (path) {
     
  if (bailRE.test(path)) {
     
    return
  }
  const segments = path.split('.')
  return function (obj) {
     
    for (let i = 0; i < segments.length; i++) {
     
      if (!obj) return
      obj = obj[segments[i]]
    }
    return obj
  }
}

谁用到了数据，谁就是依赖，我们就为谁创建一个Watcher实例，在创建Watcher实例的过程中会自动的把自己添加到这个数据对应的依赖管理器中，以后这个Watcher实例就代表这个依赖，当数据变化时，我们就通知Watcher实例，由Watcher实例再去通知真正的依赖。

那么，在创建Watcher实例的过程中它是如何的把自己添加到这个数据对应的依赖管理器中呢？

下面我们分析Watcher类的代码实现逻辑：

当实例化Watcher类时，会先执行其构造函数；
在构造函数中调用了this.get()实例方法；
在get()方法中，首先通过window.target = this把实例自身赋给了全局的一个唯一对象window.target上，然后通过let value = this.getter.call(vm, vm)获取一下被依赖的数据，获取被依赖数据的目的是触发该数据上面的getter，上文我们说过，在getter里会调用dep.depend()收集依赖，而在dep.depend()中取到挂载window.target上的值并将其存入依赖数组中，在get()方法最后将window.target释放掉。
而当数据变化时，会触发数据的setter，在setter中调用了dep.notify()方法，在dep.notify()方法中，遍历所有依赖(即watcher实例)，执行依赖的update()方法，也就是Watcher类中的update()实例方法，在update()方法中调用数据变化的更新回调函数，从而更新视图。
简单总结一下就是：Watcher先把自己设置到全局唯一的指定位置（window.target），然后读取数据。因为读取了数据，所以会触发这个数据的getter。接着，在getter中就会从全局唯一的那个位置读取当前正在读取数据的Watcher，并把这个watcher收集到Dep中去。收集好之后，当数据发生变化时，会向Dep中的每个Watcher发送通知。通过这样的方式，Watcher可以主动去订阅任意一个数据的变化。为了便于理解，我们画出了其关系流程图，如下图：

以上，就彻底完成了对Object数据的侦测，依赖收集，依赖的更新等所有操作。

不足之处
虽然我们通过Object.defineProperty方法实现了对object数据的可观测，但是这个方法仅仅只能观测到object数据的取值及设置值，当我们向object数据里添加一对新的key/value或删除一对已有的key/value时，它是无法观测到的，导致当我们对object数据添加或删除值时，无法通知依赖，无法驱动视图进行响应式更新。

当然，Vue也注意到了这一点，为了解决这一问题，Vue增加了两个全局API:Vue.set和Vue.delete，这两个API的实现原理将会在后面学习全局API的时候说到。

总结
首先，我们通过Object.defineProperty方法实现了对object数据的可观测，并且封装了Observer类，让我们能够方便的把object数据中的所有属性（包括子属性）都转换成getter/seter的形式来侦测变化。

接着，我们学习了什么是依赖收集？并且知道了在getter中收集依赖，在setter中通知依赖更新，以及封装了依赖管理器Dep，用于存储收集到的依赖。

最后，我们为每一个依赖都创建了一个Watcher实例，当数据发生变化时，通知Watcher实例，由Watcher实例去做真实的更新操作。

其整个流程大致如下：

Data通过observer转换成了getter/setter的形式来追踪变化。
当外界通过Watcher读取数据时，会触发getter从而将Watcher添加到依赖中。
当数据发生了变化时，会触发setter，从而向Dep中的依赖（即Watcher）发送通知。
Watcher接收到通知后，会向外界发送通知，变化通知到外界后可能会触发视图更新，也有可能触发用户的某个回调函数等。

Array变化侦测

  为什么Object数据和Array型数据会有两种不同的变化侦测方式？

这是因为对于Object数据我们使用的是JS提供的对象原型上的方法Object.defineProperty，而这个方法是对象原型上的，所以Array无法使用这个方法，所以我们需要对Array型数据设计一套另外的变化侦测机制。万变不离其宗，虽然对Array型数据设计了新的变化侦测机制，但是其根本思路还是不变的。那就是：还是在获取数据时收集依赖，数据变化时通知依赖更新。

 data() {
     
  return {
     
    arr:[1,2,3]
  }
 }

想想看，arr这个数据始终都存在于一个object数据对象中，而且我们也说了，谁用到了数据谁就是依赖，那么要用到arr这个数据，是不是得先从
object数据对象中获取一下arr数据，而从object数据对象中获取arr数据自然就会触发arr的getter，所以我们就可以在getter中收集依赖。

let arr = [1,2,3]
arr.push(4)
Array.prototype.newPush = function(val){
     
  console.log('arr被修改了')
  this.push(val)
}
arr.newPush(4)

在Vue中创建了一个数组方法拦截器，它拦截在数组实例与Array.prototype之间，在拦截器内重写了操作数组的一些方法，当数组实例使用操作数组方法时
其实使用的是拦截器中重写的方法，而不再使用Array.prototype上的原生方法

function defineReactive (obj,key,val) {
     
  let childOb = observe(val)
  Object.defineProperty(obj, key, {
     
    enumerable: true,
    configurable: true,
    get(){
     
      if (childOb) {
     
        childOb.dep.depend()
      }
      return val;
    },
    set(newVal){
     
      if(val === newVal){
     
        return
      }
      val = newVal;
      dep.notify()   // 在setter中通知依赖更新
    }
  })
}

尝试为value创建一个0bserver实例，如果创建成功，直接返回新创建的Observer实例。如果 Value 已经存在一个Observer实例，则直接返回它

如何通知依赖
到现在为止，依赖已经收集好了，并且也已经存放好了，那么我们该如何通知依赖呢？

其实不难，在前文说过，我们应该在拦截器里通知依赖，要想通知依赖，首先要能访问到依赖。要访问到依赖也不难，因为我们只要能访问到被转化成响应式的数据value即可，因为vaule上的__ob__就是其对应的Observer类实例，有了Observer类实例我们就能访问到它上面的依赖管理器，然后只需调用依赖管理器的dep.notify()方法，让它去通知依赖更新即可。源码如下：

methodsToPatch.forEach(function (method) {
     
  const original = arrayProto[method]
  def(arrayMethods, method, function mutator (...args) {
     
    const result = original.apply(this, args)
    const ob = this.__ob__
    // notify change
    ob.dep.notify()
    return result
  })
})

上面代码中，由于我们的拦截器是挂载到数组数据的原型上的，所以拦截器中的this就是数据value，拿到value上的Observer类实例，从而你就可以调用Observer类实例上面依赖管理器的dep.notify()方法，以达到通知依赖的目的。

OK，以上就基本完成了Array数据的变化侦测。

深度侦测
在前文所有讲的Array型数据的变化侦测都仅仅说的是数组自身变化的侦测，比如给数组新增一个元素或删除数组中一个元素，而在Vue中，不论是Object型数据还是Array型数据所实现的数据变化侦测都是深度侦测，所谓深度侦测就是不但要侦测数据自身的变化，还要侦测数据中所有子数据的变化。举个例子：

let arr = [
  {
     
    name:'NLRX'，
    age:'18'
  }
]

数组中包含了一个对象，如果该对象的某个属性发生了变化也应该被侦测到，这就是深度侦测。

这个实现起来比较简单，源码如下：

export class Observer {
     
  value: any;
  dep: Dep;

  constructor (value: any) {
     
    this.value = value
    this.dep = new Dep()
    def(value, '__ob__', this)
    if (Array.isArray(value)) {
     
      const augment = hasProto
        ? protoAugment
        : copyAugment
      augment(value, arrayMethods, arrayKeys)
      this.observeArray(value)   // 将数组中的所有元素都转化为可被侦测的响应式
    } else {
     
      this.walk(value)
    }
  }

  observeArray (items: Array<any>) {
     
    for (let i = 0, l = items.length; i < l; i++) {
     
      observe(items[i])
    }
  }
}

export function observe (value, asRootData){
     
  if (!isObject(value) || value instanceof VNode) {
     
    return
  }
  let ob
  if (hasOwn(value, '__ob__') && value.__ob__ instanceof Observer) {
     
    ob = value.__ob__
  } else {
     
    ob = new Observer(value)
  }
  return ob
}

在上面代码中，对于Array型数据，调用了observeArray()方法，该方法内部会遍历数组中的每一个元素，然后通过调用observe函数将每一个元素都转化成可侦测的响应式数据。

而对应object数据，在上一篇文章中我们已经在defineReactive函数中进行了递归操作。

数组新增元素的侦测
对于数组中已有的元素我们已经可以将其全部转化成可侦测的响应式数据了，但是如果向数组里新增一个元素的话，我们也需要将新增的这个元素转化成可侦测的响应式数据。

这个实现起来也很容易，我们只需拿到新增的这个元素，然后调用observe函数将其转化即可。我们知道，可以向数组内新增元素的方法有3个，分别是：push、unshift、splice。我们只需对这3中方法分别处理，拿到新增的元素，再将其转化即可。源码如下：

methodsToPatch.forEach(function (method) {
     
  // cache original method
  const original = arrayProto[method]
  def(arrayMethods, method, function mutator (...args) {
     
    const result = original.apply(this, args)
    const ob = this.__ob__
    let inserted
    switch (method) {
     
      case 'push':
      case 'unshift':
        inserted = args   // 如果是push或unshift方法，那么传入参数就是新增的元素
        break
      case 'splice':
        inserted = args.slice(2) // 如果是splice方法，那么传入参数列表中下标为2的就是新增的元素
        break
    }
    if (inserted) ob.observeArray(inserted) // 调用observe函数将新增的元素转化成响应式
    // notify change
    ob.dep.notify()
    return result
  })
})

在上面拦截器定义代码中，如果是push或unshift方法，那么传入参数就是新增的元素;如果是splice方法，那么传入参数列表中下标为2的就是新增的元素，拿到新增的元素后，就可以调用observe函数将新增的元素转化成响应式的了。

前文中我们说过，对于数组变化侦测是通过拦截器实现的，也就是说只要是通过数组原型上的方法对数组进行操作就都可以侦测到，但是别忘了，我们在日常开发中，还可以通过数组的下标来操作数据，如下：

let arr = [1,2,3]
arr[0] = 5;       // 通过数组下标修改数组中的数据
arr.length = 0    // 通过修改数组长度清空数组

而使用上述例子中的操作方式来修改数组是无法侦测到的。 同样，Vue也注意到了这个问题， 为了解决这一问题，Vue增加了两个全局API:Vue.set和Vue.delete，这两个API的实现原理将会在后面学习全局API的时候说到。

在本篇文章中，首先我们分析了对于Array型数据也在getter中进行依赖收集；其次我们发现，当数组数据被访问时我们轻而易举可以知道，但是被修改时我们却很难知道，为了解决这一问题，我们创建了数组方法拦截器，从而成功的将数组数据变的可观测。接着我们对数组的依赖收集及数据变化如何通知依赖进行了深入分析；最后我们发现Vue不但对数组自身进行了变化侦测，还对数组中的每一个元素以及新增的元素都进行了变化侦测，我们也分析了其实现原理。

以上就是对Array型数据的变化侦测分析。

Vue 虚拟dom

什么是虚拟dom

所谓虚拟DOM，就是用一个JS对象来描述一个DOM节点，像如下示例：

<

div class="a" id="b">我是内容</div>

{
     
  tag:'div',        // 元素标签
  attrs:{
                // 属性
    class:'a',
    id:'b'
  },
  text:'我是内容',  // 文本内容
  children:[]       // 子元素
}

我们把组成一个DOM节点的必要东西通过一个JS对象表示出来，那么这个JS对象就可以用来描述这个DOM节点，我们把这个JS对象就称为是这个真实DOM节点的虚拟DOM节点。

为什么要有虚拟DOM？

我们知道，Vue是数据驱动视图的，数据发生变化视图就要随之更新，在更新视图的时候难免要操作DOM,而操作真实DOM又是非常耗费性能的，这是因为浏览器的标准就把 DOM 设计的非常复杂，所以一个真正的 DOM 元素是非常庞大的，如下所示：

let div = document.createElement('div')
let str = ''
for (const key in div) {
     
  str += key + ''
}
console.log(str)

上图中我们打印一个简单的空div标签，就打印出这么多东西，更不用说复杂的、深嵌套的DOM节点了。由此可见，直接操作真实DOM是非常消耗性能的。

那么有没有什么解决方案呢？当然是有的。我们可以用JS的计算性能来换取操作DOM所消耗的性能。

既然我们逃不掉操作DOM这道坎,但是我们可以尽可能少的操作DOM。那如何在更新视图的时候尽可能少的操作DOM呢？最直观的思路就是我们不要盲目的去更新视图，而是通过对比数据变化前后的状态，计算出视图中哪些地方需要更新，只更新需要更新的地方，而不需要更新的地方则不需关心，这样我们就可以尽可能少的操作DOM了。这也就是上面所说的用JS的计算性能来换取操作DOM的性能。

我们可以用JS模拟出一个DOM节点，称之为虚拟DOM节点。当数据发生变化时，我们对比变化前后的虚拟DOM节点，通过DOM-Diff算法计算出需要更新的地方，然后去更新需要更新的视图。

这就是虚拟DOM产生的原因以及最大的用途。

vue中的虚拟dom

Vue中的虚拟DOM
前文我们介绍了虚拟DOM的概念以及为什么要有虚拟DOM，那么在Vue中虚拟DOM是怎么实现的呢？接下来，我们从源码出发，深入学习一下。

我们说了，虚拟DOM就是用JS来描述一个真实的DOM节点。而在Vue中就存在了一个VNode类，通过这个类，我们就可以实例化出不同类型的虚拟DOM节点，源码如下：

// 源码位置：src/core/vdom/vnode.js

export default class VNode {
     
  constructor (
    tag?: string,
    data?: VNodeData,
    children?: ?Array<VNode>,
    text?: string,
    elm?: Node,
    context?: Component,
    componentOptions?: VNodeComponentOptions,
    asyncFactory?: Function
  ) {
     
    this.tag = tag                                /*当前节点的标签名*/
    this.data = data        /*当前节点对应的对象，包含了具体的一些数据信息，是一个VNodeData类型，可以参考VNodeData类型中的数据信息*/
    this.children = children  /*当前节点的子节点，是一个数组*/
    this.text = text     /*当前节点的文本*/
    this.elm = elm       /*当前虚拟节点对应的真实dom节点*/
    this.ns = undefined            /*当前节点的名字空间*/
    this.context = context          /*当前组件节点对应的Vue实例*/
    this.fnContext = undefined       /*函数式组件对应的Vue实例*/
    this.fnOptions = undefined
    this.fnScopeId = undefined
    this.key = data && data.key           /*节点的key属性，被当作节点的标志，用以优化*/
    this.componentOptions = componentOptions   /*组件的option选项*/
    this.componentInstance = undefined       /*当前节点对应的组件的实例*/
    this.parent = undefined           /*当前节点的父节点*/
    this.raw = false         /*简而言之就是是否为原生HTML或只是普通文本，innerHTML的时候为true，textContent的时候为false*/
    this.isStatic = false         /*静态节点标志*/
    this.isRootInsert = true      /*是否作为跟节点插入*/
    this.isComment = false             /*是否为注释节点*/
    this.isCloned = false           /*是否为克隆节点*/
    this.isOnce = false                /*是否有v-once指令*/
    this.asyncFactory = asyncFactory
    this.asyncMeta = undefined
    this.isAsyncPlaceholder = false
  }

  get child (): Component | void {
     
    return this.componentInstance
  }
}

从上面的代码中可以看出：VNode类中包含了描述一个真实DOM节点所需要的一系列属性，如tag表示节点的标签名，text表示节点中包含的文本，children表示该节点包含的子节点等。通过属性之间不同的搭配，就可以描述出各种类型的真实DOM节点。

上一小节最后我们说了，通过属性之间不同的搭配，VNode类可以描述出各种类型的真实DOM节点。那么它都可以描述出哪些类型的节点呢？通过阅读源码，可以发现通过不同属性的搭配，可以描述出以下几种类型的节点。

注释节点
文本节点
元素节点
组件节点
函数式组件节点
克隆节点

接下来，我们就把这几种类型的节点描述方式从源码中一一对应起来。

注释节点描述起来相对就非常简单了，它只需两个属性就够了，源码如下：

// 创建注释节点
export const createEmptyVNode = (text: string = '') => {
     
  const node = new VNode()
  node.text = text
  node.isComment = true
  return node
}

从上面代码中可以看到，描述一个注释节点只需两个属性，分别是：text和isComment。其中text属性表示具体的注释信息，isComment是一个标志，用来标识一个节点是否是注释节点。

文本节点描述起来比注释节点更简单，因为它只需要一个属性，那就是text属性，用来表示具体的文本信息。源码如下：

// 创建文本节点
export function createTextVNode (val: string | number) {
     
  return new VNode(undefined, undefined, undefined, String(val))
}

克隆节点就是把一个已经存在的节点复制一份出来，它主要是为了做模板编译优化时使用，这个后面我们会说到。关于克隆节点的描述，源码如下：

// 创建克隆节点
export function cloneVNode (vnode: VNode): VNode {
     
  const cloned = new VNode(
    vnode.tag,
    vnode.data,
    vnode.children,
    vnode.text,
    vnode.elm,
    vnode.context,
    vnode.componentOptions,
    vnode.asyncFactory
  )
  cloned.ns = vnode.ns
  cloned.isStatic = vnode.isStatic
  cloned.key = vnode.key
  cloned.isComment = vnode.isComment
  cloned.fnContext = vnode.fnContext
  cloned.fnOptions = vnode.fnOptions
  cloned.fnScopeId = vnode.fnScopeId
  cloned.asyncMeta = vnode.asyncMeta
  cloned.isCloned = true
  return cloned
}

从上面代码中可以看到，克隆节点就是把已有节点的属性全部复制到新节点中，而现有节点和新克隆得到的节点之间唯一的不同就是克隆得到的节点isCloned为true。

相比之下，元素节点更贴近于我们通常看到的真实DOM节点，它有描述节点标签名词的tag属性，描述节点属性如class、attributes等的data属性，有描述包含的子节点信息的children属性等。由于元素节点所包含的情况相比而言比较复杂，源码中没有像前三种节点一样直接写死（当然也不可能写死），那就举个简单例子说明一下：

// 真实DOM节点
<div id='a'><span>难凉热血</span></div>

// VNode节点
{
     
  tag:'div',
  data:{
     },
  children:[
    {
     
      tag:'span',
      text:'难凉热血'
    }
  ]
}

我们可以看到，真实DOM节点中:div标签里面包含了一个span标签，而span标签里面有一段文本。反应到VNode节点上就如上所示:tag表示标签名，data表示标签的属性id等，children表示子节点数组。

组件节点除了有元素节点具有的属性之外，它还有两个特有的属性：

componentOptions :组件的option选项，如组件的props等
componentInstance :当前组件节点对应的Vue实例

函数式组件节点相较于组件节点，它又有两个特有的属性：

fnContext:函数式组件对应的Vue实例
fnOptions: 组件的option选项

以上就是VNode可以描述的多种节点类型，它们本质上都是VNode类的实例，只是在实例化的时候传入的属性参数不同而已。

说了这么多，那么VNode在Vue的整个虚拟DOM过程起了什么作用呢？

其实VNode的作用是相当大的。我们在视图渲染之前，把写好的template模板先编译成VNode并缓存下来，等到数据发生变化页面需要重新渲染的时候，我们把数据发生变化后生成的VNode与前一次缓存下来的VNode进行对比，找出差异，然后有差异的VNode对应的真实DOM节点就是需要重新渲染的节点，最后根据有差异的VNode创建出真实的DOM节点再插入到视图中，最终完成一次视图更新。

首先介绍了虚拟DOM的一些基本概念和为什么要有虚拟DOM，其实说白了就是以JS的计算性能来换取操作真实DOM所消耗的性能。接着从源码角度我们知道了在Vue中是通过VNode类来实例化出不同类型的虚拟DOM节点，并且学习了不同类型节点生成的属性的不同，所谓不同类型的节点其本质还是一样的，都是VNode类的实例，只是在实例化时传入的属性参数不同罢了。最后探究了VNode的作用，有了数据变化前后的VNode，我们才能进行后续的DOM-Diff找出差异，最终做到只更新有差异的视图，从而达到尽可能少的操作真实DOM的目的，以节省性能。

在介绍VNode的时候我们说了，VNode最大的用途就是在数据变化前后生成真实DOM对应的虚拟DOM节点，然后就可以对比新旧两份VNode，找出差异所在，然后更新有差异的DOM节点，最终达到以最少操作真实DOM更新视图的目的。而对比新旧两份VNode并找出差异的过程就是所谓的DOM-Diff过程。DOM-Diff算法是整个虚拟DOM的核心所在，那么接下来，我们就以源码出发，深入研究一下Vue中的DOM-Diff过程是怎样的。

在Vue中，把 DOM-Diff过程叫做patch过程。patch,意为“补丁”，即指对旧的VNode修补，打补丁从而得到新的VNode，非常形象哈。那不管叫什么，其本质都是把对比新旧两份VNode的过程。我们在下面研究patch过程的时候，一定把握住这样一个思想：所谓旧的VNode(即oldVNode)就是数据变化之前视图所对应的虚拟DOM节点，而新的VNode是数据变化之后将要渲染的新的视图所对应的虚拟DOM节点，所以我们要以生成的新的VNode为基准，对比旧的oldVNode，如果新的VNode上有的节点而旧的oldVNode上没有，那么就在旧的oldVNode上加上去；如果新的VNode上没有的节点而旧的oldVNode上有，那么就在旧的oldVNode上去掉；如果某些节点在新的VNode和旧的oldVNode上都有，那么就以新的VNode为准，更新旧的oldVNode，从而让新旧VNode相同。

可能你感觉有点绕，没关系，我们在说的通俗一点，你可以这样理解：假设你电脑上现在有一份旧的电子版文档，此时老板又给了你一份新的纸质板文档，并告诉你这两份文档内容大部分都是一样的，让你以新的纸质版文档为准，把纸质版文档做一份新的电子版文档发给老板。对于这个任务此时，你应该有两种解决方案：一种方案是不管它旧的文档内容是什么样的，统统删掉，然后对着新的纸质版文档一个字一个字的敲进去，这种方案就是不用费脑，就是受点累也能解决问题。而另外一种方案是以新的纸质版文档为基准，对比看旧的电子版文档跟新的纸质版文档有什么差异，如果某些部分在新的文档里有而旧的文档里没有，那就在旧的文档里面把这些部分加上；如果某些部分在新的文档里没有而旧的文档里有，那就在旧的文档里把这些部分删掉；如果某些部分在新旧文档里都有，那就对比看有没有需要更新的，最后在旧的文档里更新一下，最终达到把旧的文档变成跟手里纸质版文档一样，完美解决。

对比以上两种方案，显然你和Vue一样聪明，肯定会选择第二种方案。第二种方案里的旧的电子版文档对应就是已经渲染在视图上的oldVNode，新的纸质版文档对应的是将要渲染在视图上的新的VNode。总之一句话：以新的VNode为基准，改造旧的oldVNode使之成为跟新的VNode一样，这就是patch过程要干的事。

说了这么多，听起来感觉好像很复杂的样子，其实不然，我们仔细想想，整个patch无非就是干三件事：

创建节点：新的VNode中有而旧的oldVNode中没有，就在旧的oldVNode中创建。
删除节点：新的VNode中没有而旧的oldVNode中有，就从旧的oldVNode中删除。
更新节点：新的VNode和旧的oldVNode中都有，就以新的VNode为准，更新旧的oldVNode。
OK，到这里，你就对Vue中的patch过程理解了一半了，接下来，我们就逐个分析，看Vue对于以上三件事都是怎么做的。

在我们分析了，VNode类可以描述6种类型的节点，而实际上只有3种类型的节点能够被创建并插入到DOM中，它们分别是：元素节点、文本节点、注释节点。所以Vue在创建节点的时候会判断在新的VNode中有而旧的oldVNode中没有的这个节点是属于哪种类型的节点，从而调用不同的方法创建并插入到DOM中。

其实判断起来也不难，因为这三种类型的节点其特点非常明显，在源码中是怎么判断的：

// 源码位置: /src/core/vdom/patch.js
function createElm (vnode, parentElm, refElm) {
     
    const data = vnode.data
    const children = vnode.children
    const tag = vnode.tag
    if (isDef(tag)) {
     
      	vnode.elm = nodeOps.createElement(tag, vnode)   // 创建元素节点
        createChildren(vnode, children, insertedVnodeQueue) // 创建元素节点的子节点
        insert(parentElm, vnode.elm, refElm)       // 插入到DOM中
    } else if (isTrue(vnode.isComment)) {
     
      vnode.elm = nodeOps.createComment(vnode.text)  // 创建注释节点
      insert(parentElm, vnode.elm, refElm)           // 插入到DOM中
    } else {
     
      vnode.elm = nodeOps.createTextNode(vnode.text)  // 创建文本节点
      insert(parentElm, vnode.elm, refElm)           // 插入到DOM中
    }
  }

从上面代码中，我们可以看出：

判断是否为元素节点只需判断该VNode节点是否有tag标签即可。如果有tag属性即认为是元素节点，则调用createElement方法创建元素节点，通常元素节点还会有子节点，那就递归遍历创建所有子节点，将所有子节点创建好之后insert插入到当前元素节点里面，最后把当前元素节点插入到DOM中。

判断是否为注释节点，只需判断VNode的isComment属性是否为true即可，若为true则为注释节点，则调用createComment方法创建注释节点，再插入到DOM中。
如果既不是元素节点，也不是注释节点，那就认为是文本节点，则调用createTextNode方法创建文本节点，再插入到DOM中。
代码中的nodeOps是Vue为了跨平台兼容性，对所有节点操作进行了封装，例如nodeOps.createTextNode()在浏览器端等同于document.createTextNode()

以上就完成了创建节点的操作，其完整流程图如下：

如果某些节点再新的VNode中没有而在旧的oldVNode中有，那么就需要把这些节点从旧的oldVNode中删除。删除节点非常简单，只需在要删除节点的父元素上调用removeChild方法即可。源码如下：

function removeNode (el) {
     
    const parent = nodeOps.parentNode(el)  // 获取父节点
    if (isDef(parent)) {
     
      nodeOps.removeChild(parent, el)  // 调用父节点的removeChild方法
    }
  }

创建节点和删除节点都比较简单，而更新节点就相对较为复杂一点了，其实也不算多复杂，只要理清逻辑就能理解了。

更新节点就是当某些节点在新的VNode和旧的oldVNode中都有时，我们就需要细致比较一下，找出不一样的地方进行更新。

介绍更新节点之前，我们先介绍一个小的概念，就是什么是静态节点？我们看个例子：

<p>我是不会变化的文字</p>

上面这个节点里面只包含了纯文字，没有任何可变的变量，这也就是说，不管数据再怎么变化，只要这个节点第一次渲染了，那么它以后就永远不会发生变化，这是因为它不包含任何变量，所以数据发生任何变化都与它无关。我们把这种节点称之为静态节点。

OK，有了这个概念以后，我们开始更新节点。更新节点的时候我们需要对以下3种情况进行判断并分别处理：

如果VNode和oldVNode均为静态节点

我们说了，静态节点无论数据发生任何变化都与它无关，所以都为静态节点的话则直接跳过，无需处理。

如果VNode是文本节点

如果VNode是文本节点即表示这个节点内只包含纯文本，那么只需看oldVNode是否也是文本节点，如果是，那就比较两个文本是否不同，如果不同则把oldVNode里的文本改成跟VNode的文本一样。如果oldVNode不是文本节点，那么不论它是什么，直接调用setTextNode方法把它改成文本节点，并且文本内容跟VNode相同。

如果VNode是元素节点

如果VNode是元素节点，则又细分以下两种情况：

该节点包含子节点

如果新的节点内包含了子节点，那么此时要看旧的节点是否包含子节点，如果旧的节点里也包含了子节点，那就需要递归对比更新子节点；如果旧的节点里不包含子节点，那么这个旧节点有可能是空节点或者是文本节点，如果旧的节点是空节点就把新的节点里的子节点创建一份然后插入到旧的节点里面，如果旧的节点是文本节点，则把文本清空，然后把新的节点里的子节点创建一份然后插入到旧的节点里面。

该节点不包含子节点

如果该节点不包含子节点，同时它又不是文本节点，那就说明该节点是个空节点，那就好办了，不管旧节点之前里面都有啥，直接清空即可。

OK，处理完以上3种情况，更新节点就算基本完成了，接下来我们看下源码中具体是怎么实现的，源码如下：

// 更新节点
function patchVnode (oldVnode, vnode, insertedVnodeQueue, removeOnly) {
     
  // vnode与oldVnode是否完全一样？若是，退出程序
  if (oldVnode === vnode) {
     
    return
  }
  const elm = vnode.elm = oldVnode.elm

  // vnode与oldVnode是否都是静态节点？若是，退出程序
  if (isTrue(vnode.isStatic) &&
    isTrue(oldVnode.isStatic) &&
    vnode.key === oldVnode.key &&
    (isTrue(vnode.isCloned) || isTrue(vnode.isOnce))
  ) {
     
    return
  }

  const oldCh = oldVnode.children
  const ch = vnode.children
  // vnode有text属性？若没有：
  if (isUndef(vnode.text)) {
     
    // vnode的子节点与oldVnode的子节点是否都存在？
    if (isDef(oldCh) && isDef(ch)) {
     
      // 若都存在，判断子节点是否相同，不同则更新子节点
      if (oldCh !== ch) updateChildren(elm, oldCh, ch, insertedVnodeQueue, removeOnly)
    }
    // 若只有vnode的子节点存在
    else if (isDef(ch)) {
     
      /**
       * 判断oldVnode是否有文本？
       * 若没有，则把vnode的子节点添加到真实DOM中
       * 若有，则清空Dom中的文本，再把vnode的子节点添加到真实DOM中
       */
      if (isDef(oldVnode.text)) nodeOps.setTextContent(elm, '')
      addVnodes(elm, null, ch, 0, ch.length - 1, insertedVnodeQueue)
    }
    // 若只有oldnode的子节点存在
    else if (isDef(oldCh)) {
     
      // 清空DOM中的子节点
      removeVnodes(elm, oldCh, 0, oldCh.length - 1)
    }
    // 若vnode和oldnode都没有子节点，但是oldnode中有文本
    else if (isDef(oldVnode.text)) {
     
      // 清空oldnode文本
      nodeOps.setTextContent(elm, '')
    }
    // 上面两个判断一句话概括就是，如果vnode中既没有text，也没有子节点，那么对应的oldnode中有什么就清空什么
  }
  // 若有，vnode的text属性与oldVnode的text属性是否相同？
  else if (oldVnode.text !== vnode.text) {
     
    // 若不相同：则用vnode的text替换真实DOM的文本
    nodeOps.setTextContent(elm, vnode.text)
  }
}

上面代码里注释已经写得很清晰了，接下来我们画流程图来梳理一下整个过程，流程图如下：

通过对照着流程图以及代码，相信更新节点这部分逻辑你很容易就能理解了。

另外，你可能注意到了，如果新旧VNode里都包含了子节点，那么对于子节点的更新在代码里调用了updateChildren方法，而这个方法的逻辑到底是怎样的。

在我们介绍了Vue中的DOM-Diff算法：patch过程。我们先介绍了算法的整个思想流程，然后通过梳理算法思想，了解了整个patch过程干了三件事，分别是：创建节点，删除节点，更新节点。并且对每件事情都对照源码展开了细致的学习，画出了其逻辑流程图。另外对于更新节点中，如果新旧VNode里都包含了子节点，我们就需要细致的去更新子节点。

更新子节点

我们了解了Vue中的patch过程，即DOM-Diff算法。并且知道了在patch过程中基本会干三件事，分别是：创建节点，删除节点和更新节点。创建节点和删除节点都比较简单，而更新节点因为要处理各种可能出现的情况所以逻辑略微复杂一些，但是没关系，我们通过分析过程，对照源码，画逻辑流程图来帮助我们理解了其中的过程。最后我们还遗留了一个问题，那就是在更新节点过程中，新旧VNode可能都包含有子节点，对于子节点的对比更新会有额外的一些逻辑，那么在本篇文章中我们就来学习在Vue中是怎么对比更新子节点的。

当新的VNode与旧的oldVNode都是元素节点并且都包含子节点时，那么这两个节点的VNode实例上的children属性就是所包含的子节点数组。我们把新的VNode上的子节点数组记为newChildren，把旧的oldVNode上的子节点数组记为oldChildren，我们把newChildren里面的元素与oldChildren里的元素一一进行对比，对比两个子节点数组肯定是要通过循环，外层循环newChildren数组，内层循环oldChildren数组，每循环外层newChildren数组里的一个子节点，就去内层oldChildren数组里找看有没有与之相同的子节点，伪代码如下：

for (let i = 0; i < newChildren.length; i++) {
     
  const newChild = newChildren[i];
  for (let j = 0; j < oldChildren.length; j++) {
     
    const oldChild = oldChildren[j];
    if (newChild === oldChild) {
     
      // ...
    }
  }
}

那么以上这个过程将会存在以下四种情况：

创建子节点

如果newChildren里面的某个子节点在oldChildren里找不到与之相同的子节点，那么说明newChildren里面的这个子节点是之前没有的，是需要此次新增的节点，那么就创建子节点。

删除子节点

如果把newChildren里面的每一个子节点都循环完毕后，发现在oldChildren还有未处理的子节点，那就说明这些未处理的子节点是需要被废弃的，那么就将这些节点删除。

移动子节点

如果newChildren里面的某个子节点在oldChildren里找到了与之相同的子节点，但是所处的位置不同，这说明此次变化需要调整该子节点的位置，那就以newChildren里子节点的位置为基准，调整oldChildren里该节点的位置，使之与在newChildren里的位置相同。

更新节点

如果newChildren里面的某个子节点在oldChildren里找到了与之相同的子节点，并且所处的位置也相同，那么就更新oldChildren里该节点，使之与newChildren里的该节点相同。

OK，到这里，逻辑就相对清晰了，接下来我们只需分门别类的处理这四种情况就好了。

创建子节点

如果newChildren里面的某个子节点在oldChildren里找不到与之相同的子节点，那么说明newChildren里面的这个子节点是之前没有的，是需要此次新增的节点，那么我们就创建这个节点，创建好之后再把它插入到DOM中合适的位置。

创建节点这个很容易，我们在上一篇文章的第三章已经介绍过了，这里就不再赘述了。

那么创建好之后如何插入到DOM中的合适的位置呢？显然，把节点插入到DOM中是很容易的，找到合适的位置是关键。接下来我们分析一下如何找这个合适的位置。我们看下面这个图：

上图中左边是新的VNode，右边是旧的oldVNode，同时也是真实的DOM。这个图意思是当我们循环newChildren数组里面的子节点，前两个子节点都在oldChildren里找到了与之对应的子节点，那么我们将其处理，处理过后把它们标志为已处理，当循环到newChildren数组里第三个子节点时，发现在oldChildren里找不到与之对应的子节点，那么我们就需要创建这个节点，创建好之后我们发现这个节点本是newChildren数组里左起第三个子节点，那么我们就把创建好的节点插入到真实DOM里的第三个节点位置，也就是所有已处理节点之后，OK，此时我们拍手称快，所有已处理节点之后就是我们要找的合适的位置，但是真的是这样吗？我们再来看下面这个图：

假如我们按照上面的方法把第三个节点插入到所有已处理节点之后，此时如果第四个节点也在oldChildren里找不到与之对应的节点，也是需要创建的节点，那么当我们把第四个节点也按照上面的说的插入到已处理节点之后，发现怎么插入到第三个位置了，可明明这个节点在newChildren数组里是第四个啊！

这就是问题所在，其实，我们应该把新创建的节点插入到所有未处理节点之前，这样以来逻辑才正确。后面不管有多少个新增的节点，每一个都插入到所有未处理节点之前，位置才不会错。

所以，合适的位置是所有未处理节点之前，而并非所有已处理节点之后。

删除子节点
如果把newChildren里面的每一个子节点都循环一遍，能在oldChildren数组里找到的就处理它，找不到的就新增，直到把newChildren里面所有子节点都过一遍后，发现在oldChildren还存在未处理的子节点，那就说明这些未处理的子节点是需要被废弃的，那么就将这些节点删除。

删除节点这个也很容易，我们在上一篇文章的第四章已经介绍过了，这里就不再赘述了。

更新子节点
如果newChildren里面的某个子节点在oldChildren里找到了与之相同的子节点，并且所处的位置也相同，那么就更新oldChildren里该节点，使之与newChildren里的该节点相同。

关于更新节点，我们在上一篇文章的第五章已经介绍过了，这里就不再赘述了。

移动子节点
如果newChildren里面的某个子节点在oldChildren里找到了与之相同的子节点，但是所处的位置不同，这说明此次变化需要调整该子节点的位置，那就以newChildren里子节点的位置为基准，调整oldChildren里该节点的位置，使之与在newChildren里的位置相同。

同样，移动一个节点不难，关键在于该移动到哪，或者说关键在于移动到哪个位置，这个位置才是关键。我们看下图：

在上图中，绿色的两个节点是相同节点但是所处位置不同，即newChildren里面的第三个子节点与真实DOM即oldChildren里面的第四个子节点相同但是所处位置不同，按照上面所说的，我们应该以newChildren里子节点的位置为基准，调整oldChildren里该节点的位置，所以我们应该把真实DOM即oldChildren里面的第四个节点移动到第三个节点的位置，通过上图中的标注我们不难发现，所有未处理节点之前就是我们要移动的目的位置。如果此时你说那可不可以移动到所有已处理节点之后呢？那就又回到了更新节点时所遇到的那个问题了：如果前面有新增的节点呢？

回到源码
OK，以上就是更新子节点时所要考虑的所有情况了，分析完以后，我们回到源码里看看实际情况是不是我们分析的这样子的，源码如下：

// 源码位置： /src/core/vdom/patch.js

if (isUndef(idxInOld)) {
         // 如果在oldChildren里找不到当前循环的newChildren里的子节点
    // 新增节点并插入到合适位置
    createElm(newStartVnode, insertedVnodeQueue, parentElm, oldStartVnode.elm, false, newCh, newStartIdx)
} else {
     
    // 如果在oldChildren里找到了当前循环的newChildren里的子节点
    vnodeToMove = oldCh[idxInOld]
    // 如果两个节点相同
    if (sameVnode(vnodeToMove, newStartVnode)) {
     
        // 调用patchVnode更新节点
        patchVnode(vnodeToMove, newStartVnode, insertedVnodeQueue)
        oldCh[idxInOld] = undefined
        // canmove表示是否需要移动节点，如果为true表示需要移动，则移动节点，如果为false则不用移动
        canMove && nodeOps.insertBefore(parentElm, vnodeToMove.elm, oldStartVnode.elm)
    }
}

以上代码中，首先判断在oldChildren里能否找到当前循环的newChildren里的子节点，如果找不到，那就是新增节点并插入到合适位置；如果找到了，先对比两个节点是否相同，若相同则先调用patchVnode更新节点，更新完之后再看是否需要移动节点，注意，源码里在判断是否需要移动子节点时用了简写的方式，下面这两种写法是等价的：

canMove && nodeOps.insertBefore(parentElm, vnodeToMove.elm, oldStartVnode.elm)
// 等同于
if(canMove){
     
    nodeOps.insertBefore(parentElm, vnodeToMove.elm, oldStartVnode.elm)
}

我们看到，源码里的实现跟我们分析的是一样一样的。

优化更新子节点

我们分析了Vue在更新子节点时是外层循环newChildren数组，内层循环oldChildren数组，把newChildren数组里的每一个元素分别与oldChildren数组里的每一个元素匹配，根据不同情况作出创建子节点、删除子节点、更新子节点以及移动子节点的操作。并且我们对不同情况的不同操作都进行了深入分析，分析之后我们回到源码验证我们分析的正确性，发现我们的分析跟源码的实现是一致的。

最后，我们再思考一个问题：这样双层循环虽然能解决问题，但是如果节点数量很多，这样循环算法的时间复杂度会不会很高？有没有什么可以优化的办法？答案当然是有的，并且Vue也意识到了这点，也进行了优化，那么下面我们就来分析当节点数量很多时Vue是怎么优化算法的。

我们介绍了当新的VNode与旧的oldVNode都是元素节点并且都包含子节点时，Vue对子节点是

先外层循环newChildren数组，再内层循环oldChildren数组，每循环外层newChildren数组里的一个子节点，就去内层oldChildren数组里找看有没有与之相同的子节点，最后根据不同的情况作出不同的操作。

在上一篇文章的结尾我们也说了，这种方法虽然能够解决问题，但是还存在可优化的地方。比如当包含的子节点数量很多时，这样循环算法的时间复杂度就会变的很大，不利于性能提升。当然，Vue也意识到了这点，并对此也进行了优化，那么本篇文章，就来学习一下关于子节点更新的优化问题Vue是如何做的。

假如我们现有一份新的newChildren数组和旧的oldChildren数组，如下所示：

newChildren = ['新子节点1','新子节点2','新子节点3','新子节点4']
oldChildren = ['旧子节点1','旧子节点2','旧子节点3','旧子节点4']

如果按照优化之前的解决方案，那么我们接下来的操作应该是这样的：先循环newChildren数组，拿到第一个新子节点1，然后用第一个新子节点1去跟oldChildren数组里的旧子节点逐一对比，如果运气好一点，刚好oldChildren数组里的第一个旧子节点1与第一个新子节点1相同，那就皆大欢喜，直接处理，不用再往下循环了。那如果运气坏一点，直到循环到oldChildren数组里的第四个旧子节点4才与第一个新子节点1相同，那此时就会多循环了4次。我们不妨把情况再设想的极端一点，如果newChildren数组和oldChildren数组里前三个节点都没有变化，只是第四个节点发生了变化，那么我们就会循环16次，只有在第16次循环的时候才发现新节点4与旧节点4相同，进行更新，如下图所示：

上面例子中只有四个子节点，好像还看不出来有什么缺陷，但是当子节点数量很多的时候，算法的时间复杂度就会非常高，很不利于性能提升。

那么我们该怎么优化呢？其实我们可以这样想，我们不要按顺序去循环newChildren和oldChildren这两个数组，可以先比较这两个数组里特殊位置的子节点，比如：

先把newChildren数组里的所有未处理子节点的第一个子节点和oldChildren数组里所有未处理子节点的第一个子节点做比对，如果相同，那就直接进入更新节点的操作；
如果不同，再把newChildren数组里所有未处理子节点的最后一个子节点和oldChildren数组里所有未处理子节点的最后一个子节点做比对，如果相同，那就直接进入更新节点的操作；
如果不同，再把newChildren数组里所有未处理子节点的最后一个子节点和oldChildren数组里所有未处理子节点的第一个子节点做比对，如果相同，那就直接进入更新节点的操作，更新完后再将oldChildren数组里的该节点移动到与newChildren数组里节点相同的位置；
如果不同，再把newChildren数组里所有未处理子节点的第一个子节点和oldChildren数组里所有未处理子节点的最后一个子节点做比对，如果相同，那就直接进入更新节点的操作，更新完后再将oldChildren数组里的该节点移动到与newChildren数组里节点相同的位置；
最后四种情况都试完如果还不同，那就按照之前循环的方式来查找节点。
其过程如下图所示：

在上图中，我们把：

newChildren数组里的所有未处理子节点的第一个子节点称为：新前；
newChildren数组里的所有未处理子节点的最后一个子节点称为：新后；
oldChildren数组里的所有未处理子节点的第一个子节点称为：旧前；
oldChildren数组里的所有未处理子节点的最后一个子节点称为：旧后；
OK，有了以上概念以后，下面我们就来看看其具体是如何实施的。

新前与旧前
把newChildren数组里的所有未处理子节点的第一个子节点和oldChildren数组里所有未处理子节点的第一个子节点做比对，如果相同，那好极了，直接进入之前文章中说的更新节点的操作并且由于新前与旧前两个节点的位置也相同，无需进行节点移动操作；如果不同，没关系，再尝试后面三种情况。

新后与旧后
把newChildren数组里所有未处理子节点的最后一个子节点和oldChildren数组里所有未处理子节点的最后一个子节点做比对，如果相同，那就直接进入更新节点的操作并且由于新后与旧后两个节点的位置也相同，无需进行节点移动操作；如果不同，继续往后尝试。

新后与旧前
把newChildren数组里所有未处理子节点的最后一个子节点和oldChildren数组里所有未处理子节点的第一个子节点做比对，如果相同，那就直接进入更新节点的操作，更新完后再将oldChildren数组里的该节点移动到与newChildren数组里节点相同的位置；

此时，出现了移动节点的操作，移动节点最关键的地方在于找准要移动的位置。我们一再强调，更新节点要以新VNode为基准，然后操作旧的oldVNode，使之最后旧的oldVNode与新的VNode相同。那么现在的情况是：newChildren数组里的最后一个子节点与oldChildren数组里的第一个子节点相同，那么我们就应该在oldChildren数组里把第一个子节点移动到最后一个子节点的位置，如下图：

从图中不难看出，我们要把oldChildren数组里把第一个子节点移动到数组中所有未处理节点之后。

如果对比之后发现这两个节点仍不是同一个节点，那就继续尝试最后一种情况。

新前与旧后
把newChildren数组里所有未处理子节点的第一个子节点和oldChildren数组里所有未处理子节点的最后一个子节点做比对，如果相同，那就直接进入更新节点的操作，更新完后再将oldChildren数组里的该节点移动到与newChildren数组里节点相同的位置；

同样，这种情况的节点移动位置逻辑与“新后与旧前”的逻辑类似，那就是newChildren数组里的第一个子节点与oldChildren数组里的最后一个子节点相同，那么我们就应该在oldChildren数组里把最后一个子节点移动到第一个子节点的位置，如下图：

从图中不难看出，我们要把oldChildren数组里把最后一个子节点移动到数组中所有未处理节点之前。

OK，以上就是子节点对比更新优化策略种的4种情况，如果以上4种情况逐个试遍之后要是还没找到相同的节点，那就再通过之前的循环方式查找。

回到源码
思路分析完，逻辑理清之后，我们再回到源码里看看，验证一下源码实现的逻辑是否跟我们分析的一样。源码如下：

// 循环更新子节点
  function updateChildren (parentElm, oldCh, newCh, insertedVnodeQueue, removeOnly) {
     
    let oldStartIdx = 0               // oldChildren开始索引
    let oldEndIdx = oldCh.length - 1   // oldChildren结束索引
    let oldStartVnode = oldCh[0]        // oldChildren中所有未处理节点中的第一个
    let oldEndVnode = oldCh[oldEndIdx]   // oldChildren中所有未处理节点中的最后一个

    let newStartIdx = 0               // newChildren开始索引
    let newEndIdx = newCh.length - 1   // newChildren结束索引
    let newStartVnode = newCh[0]        // newChildren中所有未处理节点中的第一个
    let newEndVnode = newCh[newEndIdx]  // newChildren中所有未处理节点中的最后一个

    let oldKeyToIdx, idxInOld, vnodeToMove, refElm

    // removeOnly is a special flag used only by 
    // to ensure removed elements stay in correct relative positions
    // during leaving transitions
    const canMove = !removeOnly

    if (process.env.NODE_ENV !== 'production') {
     
      checkDuplicateKeys(newCh)
    }

    // 以"新前"、"新后"、"旧前"、"旧后"的方式开始比对节点
    while (oldStartIdx <= oldEndIdx && newStartIdx <= newEndIdx) {
     
      if (isUndef(oldStartVnode)) {
     
        oldStartVnode = oldCh[++oldStartIdx] // 如果oldStartVnode不存在，则直接跳过，比对下一个
      } else if (isUndef(oldEndVnode)) {
     
        oldEndVnode = oldCh[--oldEndIdx]
      } else if (sameVnode(oldStartVnode, newStartVnode)) {
     
        // 如果新前与旧前节点相同，就把两个节点进行patch更新
        patchVnode(oldStartVnode, newStartVnode, insertedVnodeQueue)
        oldStartVnode = oldCh[++oldStartIdx]
        newStartVnode = newCh[++newStartIdx]
      } else if (sameVnode(oldEndVnode, newEndVnode)) {
     
        // 如果新后与旧后节点相同，就把两个节点进行patch更新
        patchVnode(oldEndVnode, newEndVnode, insertedVnodeQueue)
        oldEndVnode = oldCh[--oldEndIdx]
        newEndVnode = newCh[--newEndIdx]
      } else if (sameVnode(oldStartVnode, newEndVnode)) {
      // Vnode moved right
        // 如果新后与旧前节点相同，先把两个节点进行patch更新，然后把旧前节点移动到oldChilren中所有未处理节点之后
        patchVnode(oldStartVnode, newEndVnode, insertedVnodeQueue)
        canMove && nodeOps.insertBefore(parentElm, oldStartVnode.elm, nodeOps.nextSibling(oldEndVnode.elm))
        oldStartVnode = oldCh[++oldStartIdx]
        newEndVnode = newCh[--newEndIdx]
      } else if (sameVnode(oldEndVnode, newStartVnode)) {
      // Vnode moved left
        // 如果新前与旧后节点相同，先把两个节点进行patch更新，然后把旧后节点移动到oldChilren中所有未处理节点之前
        patchVnode(oldEndVnode, newStartVnode, insertedVnodeQueue)
        canMove && nodeOps.insertBefore(parentElm, oldEndVnode.elm, oldStartVnode.elm)
        oldEndVnode = oldCh[--oldEndIdx]
        newStartVnode = newCh[++newStartIdx]
      } else {
     
        // 如果不属于以上四种情况，就进行常规的循环比对patch
        if (isUndef(oldKeyToIdx)) oldKeyToIdx = createKeyToOldIdx(oldCh, oldStartIdx, oldEndIdx)
        idxInOld = isDef(newStartVnode.key)
          ? oldKeyToIdx[newStartVnode.key]
          : findIdxInOld(newStartVnode, oldCh, oldStartIdx, oldEndIdx)
        // 如果在oldChildren里找不到当前循环的newChildren里的子节点
        if (isUndef(idxInOld)) {
      // New element
          // 新增节点并插入到合适位置
          createElm(newStartVnode, insertedVnodeQueue, parentElm, oldStartVnode.elm, false, newCh, newStartIdx)
        } else {
     
          // 如果在oldChildren里找到了当前循环的newChildren里的子节点
          vnodeToMove = oldCh[idxInOld]
          // 如果两个节点相同
          if (sameVnode(vnodeToMove, newStartVnode)) {
     
            // 调用patchVnode更新节点
            patchVnode(vnodeToMove, newStartVnode, insertedVnodeQueue)
            oldCh[idxInOld] = undefined
            // canmove表示是否需要移动节点，如果为true表示需要移动，则移动节点，如果为false则不用移动
            canMove && nodeOps.insertBefore(parentElm, vnodeToMove.elm, oldStartVnode.elm)
          } else {
     
            // same key but different element. treat as new element
            createElm(newStartVnode, insertedVnodeQueue, parentElm, oldStartVnode.elm, false, newCh, newStartIdx)
          }
        }
        newStartVnode = newCh[++newStartIdx]
      }
    }
    if (oldStartIdx > oldEndIdx) {
     
      /**
       * 如果oldChildren比newChildren先循环完毕，
       * 那么newChildren里面剩余的节点都是需要新增的节点，
       * 把[newStartIdx, newEndIdx]之间的所有节点都插入到DOM中
       */
      refElm = isUndef(newCh[newEndIdx + 1]) ? null : newCh[newEndIdx + 1].elm
      addVnodes(parentElm, refElm, newCh, newStartIdx, newEndIdx, insertedVnodeQueue)
    } else if (newStartIdx > newEndIdx) {
     
      /**
       * 如果newChildren比oldChildren先循环完毕，
       * 那么oldChildren里面剩余的节点都是需要删除的节点，
       * 把[oldStartIdx, oldEndIdx]之间的所有节点都删除
       */
      removeVnodes(parentElm, oldCh, oldStartIdx, oldEndIdx)
    }
  }

读源码之前，我们先有这样一个概念：那就是在我们前面所说的优化策略中，节点有可能是从前面对比，也有可能是从后面对比，对比成功就会进行更新处理，也就是说我们有可能处理第一个，也有可能处理最后一个，那么我们在循环的时候就不能简单从前往后或从后往前循环，而是要从两边向中间循环。

那么该如何从两边向中间循环呢？请看下图：

首先，我们先准备4个变量：

newStartIdx:newChildren数组里开始位置的下标；
newEndIdx:newChildren数组里结束位置的下标；
oldStartIdx:oldChildren数组里开始位置的下标；
oldEndIdx:oldChildren数组里结束位置的下标；
在循环的时候，每处理一个节点，就将下标向图中箭头所指的方向移动一个位置，开始位置所表示的节点被处理后，就向后移动一个位置；结束位置所表示的节点被处理后，就向前移动一个位置；由于我们的优化策略都是新旧节点两两更新的，所以一次更新将会移动两个节点。说的再直白一点就是：newStartIdx和oldStartIdx只能往后移动（只会加），newEndIdx和oldEndIdx只能往前移动（只会减）。

当开始位置大于结束位置时，表示所有节点都已经遍历过了。

OK，有了这个概念后，我们开始读源码：

如果oldStartVnode不存在，则直接跳过，将oldStartIdx加1，比对下一个

// 以"新前"、“新后”、“旧前”、"旧后"的方式开始比对节点
while (oldStartIdx <= oldEndIdx && newStartIdx <= newEndIdx) {
if (isUndef(oldStartVnode)) {
oldStartVnode = oldCh[++oldStartIdx]
}
}
如果oldEndVnode不存在，则直接跳过，将oldEndIdx减1，比对前一个

else if (isUndef(oldEndVnode)) {
oldEndVnode = oldCh[–oldEndIdx]
}
如果新前与旧前节点相同，就把两个节点进行patch更新，同时oldStartIdx和newStartIdx都加1，后移一个位置

else if (sameVnode(oldStartVnode, newStartVnode)) {
patchVnode(oldStartVnode, newStartVnode, insertedVnodeQueue)
oldStartVnode = oldCh[++oldStartIdx]
newStartVnode = newCh[++newStartIdx]
}
如果新后与旧后节点相同，就把两个节点进行patch更新，同时oldEndIdx和newEndIdx都减1，前移一个位置

else if (sameVnode(oldEndVnode, newEndVnode)) {
patchVnode(oldEndVnode, newEndVnode, insertedVnodeQueue)
oldEndVnode = oldCh[–oldEndIdx]
newEndVnode = newCh[–newEndIdx]
}
如果新后与旧前节点相同，先把两个节点进行patch更新，然后把旧前节点移动到oldChilren中所有未处理节点之后，最后把oldStartIdx加1，后移一个位置，newEndIdx减1，前移一个位置

else if (sameVnode(oldStartVnode, newEndVnode)) {
patchVnode(oldStartVnode, newEndVnode, insertedVnodeQueue)
canMove && nodeOps.insertBefore(parentElm, oldStartVnode.elm, nodeOps.nextSibling(oldEndVnode.elm))
oldStartVnode = oldCh[++oldStartIdx]
newEndVnode = newCh[–newEndIdx]
}
如果新前与旧后节点相同，先把两个节点进行patch更新，然后把旧后节点移动到oldChilren中所有未处理节点之前，最后把newStartIdx加1，后移一个位置，oldEndIdx减1，前移一个位置

else if (sameVnode(oldEndVnode, newStartVnode)) { // Vnode moved left
patchVnode(oldEndVnode, newStartVnode, insertedVnodeQueue)
canMove && nodeOps.insertBefore(parentElm, oldEndVnode.elm, oldStartVnode.elm)
oldEndVnode = oldCh[–oldEndIdx]
newStartVnode = newCh[++newStartIdx]
}
如果不属于以上四种情况，就进行常规的循环比对patch

如果在循环中，oldStartIdx大于oldEndIdx了，那就表示oldChildren比newChildren先循环完毕，那么newChildren里面剩余的节点都是需要新增的节点，把[newStartIdx, newEndIdx]之间的所有节点都插入到DOM中

if (oldStartIdx > oldEndIdx) {
refElm = isUndef(newCh[newEndIdx + 1]) ? null : newCh[newEndIdx + 1].elm
addVnodes(parentElm, refElm, newCh, newStartIdx, newEndIdx, insertedVnodeQueue)
}
如果在循环中，newStartIdx大于newEndIdx了，那就表示newChildren比oldChildren先循环完毕，那么oldChildren里面剩余的节点都是需要删除的节点，把[oldStartIdx, oldEndIdx]之间的所有节点都删除

else if (newStartIdx > newEndIdx) {
removeVnodes(parentElm, oldCh, oldStartIdx, oldEndIdx)
}
OK,处理完毕，可见源码中的处理逻辑跟我们之前分析的逻辑是一样的。

总结
我们介绍了Vue中子节点更新的优化策略，发现Vue为了避免双重循环数据量大时间复杂度升高带来的性能问题，而选择了从子节点数组中的4个特殊位置互相比对，分别是：新前与旧前，新后与旧后，新后与旧前，新前与旧后。对于每一种情况我们都通过图文的形式对其逻辑进行了分析。最后我们回到源码，通过阅读源码来验证我们分析的是否正确。幸运的是我们之前每一步的分析都在源码中找到了相应的实现，得以验证我们的分析没有错。以上就是Vue中的patch过程，即DOM-Diff算法所有内容了，到这里相信你再读这部分源码的时候就有比较清晰的思路了。

Vue 模板编译

什么是模板编译

你可以这么理解：把用户写的模板进行编译，就会产生VNode。

我们知道，在日常开发中，我们把写在标签中的类似于原生HTML的内容称之为模板。这时你可能会问了，为什么说是“类似于原生HTML的内容”而不是“就是HTML的内容”？因为我们在开发中，在标签中除了写一些原生HTML的标签，我们还会写一些变量插值，如，或者写一些Vue指令，如v-on、v-if等。而这些东西都是在原生HTML语法中不存在的，不被接受的。但是事实上我们确实这么写了，也被正确识别了，页面也正常显示了，这又是为什么呢？

这就归功于Vue的模板编译了，Vue会把用户在标签中写的类似于原生HTML的内容进行编译，把原生HTML的内容找出来，再把非原生HTML找出来，经过一系列的逻辑处理生成渲染函数，也就是render函数，而render函数会将模板内容生成对应的VNode，而VNode再经过前几篇文章介绍的patch过程从而得到将要渲染的视图中的VNode，最后根据VNode创建真实的DOM节点并插入到视图中， 最终完成视图的渲染更新。

而把用户在标签中写的类似于原生HTML的内容进行编译，把原生HTML的内容找出来，再把非原生HTML找出来，经过一系列的逻辑处理生成渲染函数，也就是render函数的这一段过程称之为模板编译过程。

所谓渲染流程，就是把用户写的类似于原生HTML的模板经过一系列处理最终反应到视图中称之为整个渲染流程。这个流程在上文中其实已经说到了，下面我们以流程图的形式宏观的了解一下，流程图如下：

从图中我们也可以看到，模板编译过程就是把用户写的模板经过一系列处理最终生成render函数的过程。

模板编译内部流程
那么模板编译内部是怎么把用户写的模板经过处理最终生成render函数的呢？这内部的过程是怎样的呢？

抽象语法树AST
我们知道，用户在标签中写的模板对Vue来说就是一堆字符串，那么如何解析这一堆字符串并且从中提取出元素的标签、属性、变量插值等有效信息呢？这就需要借助一个叫做抽象语法树的东西。

所谓抽象语法树，在计算机科学中，抽象语法树（AbstractSyntaxTree，AST），或简称语法树（Syntax tree），是源代码语法结构的一种抽象表示。它以树状的形式表现编程语言的语法结构，树上的每个节点都表示源代码中的一种结构。之所以说语法是“抽象”的，是因为这里的语法并不会表示出真实语法中出现的每个细节。比如，嵌套括号被隐含在树的结构中，并没有以节点的形式呈现；而类似于if-condition-then这样的条件跳转语句，可以使用带有两个分支的节点来表示。——来自百度百科

我就知道，这段话贴出来也是白贴，因为看了也看不懂，哈哈。那么我们就以最直观的例子来理解什么是抽象语法树。请看下图：

从图中我们可以看到，一个简单的HTML标签的代码被转换成了一个JS对象，而这个对象中的属性代表了这个标签中一些关键有效信息。如图中标识。 有兴趣的同学可以在这个网站在线转换试试：https://astexplorer.net/

具体流程
将一堆字符串模板解析成抽象语法树AST后，我们就可以对其进行各种操作处理了，处理完后用处理后的AST来生成render函数。其具体流程可大致分为三个阶段：

1.模板解析阶段：将一堆模板字符串用正则等方式解析成抽象语法树AST；
2.优化阶段：遍历AST，找出其中的静态节点，并打上标记；
3.代码生成阶段：将AST转换成渲染函数；
这三个阶段在源码中分别对应三个模块，下面给出三个模块的源代码在源码中的路径：

模板解析阶段——解析器——源码路径：src/compiler/parser/index.js;
优化阶段——优化器——源码路径：src/compiler/optimizer.js;
代码生成阶段——代码生成器——源码路径：src/compiler/codegen/index.js; 其对应的源码如下：

// 源码位置: /src/complier/index.js

export const createCompiler = createCompilerCreator(function baseCompile (
  template: string,
  options: CompilerOptions
): CompiledResult {
     
  // 模板解析阶段：用正则等方式解析 template 模板中的指令、class、style等数据，形成AST
  const ast = parse(template.trim(), options)
  if (options.optimize !== false) {
     
    // 优化阶段：遍历AST，找出其中的静态节点，并打上标记；
    optimize(ast, options)
  }
  // 代码生成阶段：将AST转换成渲染函数；
  const code = generate(ast, options)
  return {
     
    ast,
    render: code.render,
    staticRenderFns: code.staticRenderFns
  }
})

可以看到 baseCompile 的代码非常的简短主要核心代码。

const ast =parse(template.trim(), options):parse 会用正则等方式解析 template 模板中的指令、class、style等数据，形成AST。
optimize(ast, options): optimize 的主要作用是标记静态节点，这是 Vue 在编译过程中的一处优化，挡在进行patch 的过程中， DOM-Diff 算法会直接跳过静态节点，从而减少了比较的过程，优化了 patch 的性能。
const code =generate(ast, options): 将 AST 转化成 render函数字符串的过程，得到结果是 render函数 的字符串以及 staticRenderFns 字符串。
最终 baseCompile 的返回值

{
     
 	ast: ast,
 	render: code.render,
 	staticRenderFns: code.staticRenderFns
 }

最终返回了抽象语法树( ast )，渲染函数( render )，静态渲染函数( staticRenderFns )，且render 的值为code.render，staticRenderFns 的值为code.staticRenderFns，也就是说通过 generate处理 ast之后得到的返回值 code 是一个对象。

下面再给出模板编译内部具体流程图，便于理解。流程图如下：

首先引出了为什么会有模板编译，因为有了模板编译，才有了虚拟DOM，才有了后续的视图更新。接着介绍了什么是模板编译，以及介绍了把用户所写的模板经过层层处理直到最终渲染的视图中这个整体的渲染流程；最后介绍了模板编译过程中所需要使用的抽象语法树的概念以及分析了模板编译的具体实施流程，其流程大致分为三个阶段，分别是模板解析阶段、优化阶段和代码生成阶段。那么接下来会把这三个阶段逐一进行分析介绍。

模板解析阶段（整体运行流程、HTML解析、文本解析）

在模板解析阶段主要做的工作是把用户在标签内写的模板使用正则等方式解析成抽象语法树（AST）。而这一阶段在源码中对应解析器（parser）模块。

解析器，顾名思义，就是把用户所写的模板根据一定的解析规则解析出有效的信息，最后用这些信息形成AST。我们知道在模板内，除了有常规的HTML标签外，用户还会一些文本信息以及在文本信息中包含过滤器。而这些不同的内容在解析起来肯定需要不同的解析规则，所以解析器不可能只有一个，它应该除了有解析常规HTML的HTML解析器，还应该有解析文本的文本解析器以及解析文本中如果包含过滤器的过滤器解析器。

另外，文本信息和标签属性信息却又是存在于HTML标签之内的，所以在解析整个模板的时候它的流程应该是这样子的：HTML解析器是主线，先用HTML解析器进行解析整个模板，在解析过程中如果碰到文本内容，那就调用文本解析器来解析文本，如果碰到文本中包含过滤器那就调用过滤器解析器来解析。如下图所示：

解析器的源码位于/src/complier/parser文件夹下，其主线代码如下：

// 代码位置：/src/complier/parser/index.js

/**
 * Convert HTML string to AST.
 */
export function parse(template, options) {
     
   // ...
  parseHTML(template, {
     
    warn,
    expectHTML: options.expectHTML,
    isUnaryTag: options.isUnaryTag,
    canBeLeftOpenTag: options.canBeLeftOpenTag,
    shouldDecodeNewlines: options.shouldDecodeNewlines,
    shouldDecodeNewlinesForHref: options.shouldDecodeNewlinesForHref,
    shouldKeepComment: options.comments,
    start (tag, attrs, unary) {
     

    },
    end () {
     

    },
    chars (text: string) {
     

    },
    comment (text: string) {
     

    }
  })
  return root
}

从上面代码中可以看到，parse 函数就是解析器的主函数，在parse 函数内调用了parseHTML 函数对模板字符串进行解析，在parseHTML 函数解析模板字符串的过程中，如果遇到文本信息，就会调用文本解析器parseText函数进行文本解析；如果遇到文本中包含过滤器，就会调用过滤器解析器parseFilters函数进行解析。

模板解析的整体运行流程，模板解析其实就是根据被解析内容的特点使用正则等方式将有效信息解析提取出来，根据解析内容的不同分为HTML解析器，文本解析器和过滤器解析器。而文本信息与过滤器信息又存在于HTML标签中，所以在解析器主线函数parse中先调用HTML解析器parseHTML 函数对模板字符串进行解析，如果在解析过程中遇到文本或过滤器信息则再调用相应的解析器进行解析，最终完成对整个模板字符串的解析。

了解了模板解析阶段的整体运行流程后，接下来，我们就对流程中所涉及到的三种解析器分别深入分析，逐个击破。

在三个不同的解析器中最主要的当属HTML解析器，为什么这么说呢？因为HTML解析器主要负责解析出模板字符串中有哪些内容，然后根据不同的内容才能调用其他的解析器以及做相应的处理。那么本篇文章就来介绍一下HTML解析器是如何解析出模板字符串中包含的不同的内容的。

HTML解析器内部运行流程

在源码中，HTML解析器就是parseHTML函数，在模板解析主线函数parse中调用了该函数，并传入两个参数，代码如下：

// 代码位置：/src/complier/parser/index.js

/**
 * Convert HTML string to AST.
 * 将HTML模板字符串转化为AST
 */
export function parse(template, options) {
     
   // ...
  parseHTML(template, {
     
    warn,
    expectHTML: options.expectHTML,
    isUnaryTag: options.isUnaryTag,
    canBeLeftOpenTag: options.canBeLeftOpenTag,
    shouldDecodeNewlines: options.shouldDecodeNewlines,
    shouldDecodeNewlinesForHref: options.shouldDecodeNewlinesForHref,
    shouldKeepComment: options.comments,
    // 当解析到开始标签时，调用该函数
    start (tag, attrs, unary) {
     

    },
    // 当解析到结束标签时，调用该函数
    end () {
     

    },
    // 当解析到文本时，调用该函数
    chars (text) {
     

    },
    // 当解析到注释时，调用该函数
    comment (text) {
     

    }
  })
  return root
}

从代码中我们可以看到，调用parseHTML函数时为其传入的两个参数分别是：

template:待转换的模板字符串；
options:转换时所需的选项；
第一个参数是待转换的模板字符串，无需多言；重点看第二个参数，第二个参数提供了一些解析HTML模板时的一些参数，同时还定义了4个钩子函数。这4个钩子函数有什么作用呢？我们说了模板编译阶段主线函数parse会将HTML模板字符串转化成AST，而parseHTML是用来解析模板字符串的，把模板字符串中不同的内容出来之后，那么谁来把提取出来的内容生成对应的AST呢？答案就是这4个钩子函数。

把这4个钩子函数作为参数传给解析器parseHTML，当解析器解析出不同的内容时调用不同的钩子函数从而生成不同的AST。

当解析到开始标签时调用start函数生成元素类型的AST节点，代码如下；

// 当解析到标签的开始位置时，触发start
start (tag, attrs, unary) {
     
	let element = createASTElement(tag, attrs, currentParent)
}

export function createASTElement (tag,attrs,parent) {
     
  return {
     
    type: 1,
    tag,
    attrsList: attrs,
    attrsMap: makeAttrsMap(attrs),
    parent,
    children: []
  }
}

从上面代码中我们可以看到，start函数接收三个参数，分别是标签名tag、标签属性attrs、标签是否自闭合unary。当调用该钩子函数时，内部会调用createASTElement函数来创建元素类型的AST节点

当解析到结束标签时调用end函数；

当解析到文本时调用chars函数生成文本类型的AST节点；

// 当解析到标签的文本时，触发chars
chars (text) {
     
	if(text是带变量的动态文本){
     
    let element = {
     
      type: 2,
      expression: res.expression,
      tokens: res.tokens,
      text
    }
  } else {
     
    let element = {
     
      type: 3,
      text
    }
  }
}

当解析到标签的文本时，触发chars钩子函数，在该钩子函数内部，首先会判断文本是不是一个带变量的动态文本，如“hello ”。如果是动态文本，则创建动态文本类型的AST节点；如果不是动态文本，则创建纯静态文本类型的AST节点。

当解析到注释时调用comment函数生成注释类型的AST节点；

// 当解析到标签的注释时，触发comment
comment (text: string) {
     
  let element = {
     
    type: 3,
    text,
    isComment: true
  }
}

当解析到标签的注释时，触发comment钩子函数，该钩子函数会创建一个注释类型的AST节点。

一边解析不同的内容一边调用对应的钩子函数生成对应的AST节点，最终完成将整个模板字符串转化成AST,这就是HTML解析器所要做的工作。

如何解析不同的内容
要从模板字符串中解析出不同的内容，那首先要知道模板字符串中都会包含哪些内容。那么通常我们所写的模板字符串中都会包含哪些内容呢？经过整理，通常模板内会包含如下内容：

文本，例如“难凉热血”
HTML注释，例如<!-- 我是注释 -->
条件注释，例如<!-- [if !IE]> -->我是注释<!--< ![endif] -->
DOCTYPE，例如<!DOCTYPE html>
开始标签，例如<div>
结束标签，例如</div>

这几种内容都有其各自独有的特点，也就是说我们要根据不同内容所具有的不同的的特点通过编写不同的正则表达式将这些内容从模板字符串中一一解析出来，然后再把不同的内容做不同的处理。

下面，我们就来分别看一下HTML解析器是如何从模板字符串中将以上不同种类的内容进行解析出来。

解析HTML注释
解析注释比较简单，我们知道HTML注释是以 结尾，这两者中间的内容就是注释内容，那么我们只需用正则判断待解析的模板字符串html是否以 ，如果找到了，OK，注释就被解析出来了。代码如下：

const comment = /^
if (comment.test(html)) {
     
  // 若为注释，则继续查找是否存在'-->'
  const commentEnd = html.indexOf('-->')

  if (commentEnd >= 0) {
     
    // 若存在 '-->',继续判断options中是否保留注释
    if (options.shouldKeepComment) {
     
      // 若保留注释，则把注释截取出来传给options.comment，创建注释类型的AST节点
      options.comment(html.substring(4, commentEnd))
    }
    // 若不保留注释，则将游标移动到'-->'之后，继续向后解析
    advance(commentEnd + 3)
    continue
  }
}

在上面代码中，如果模板字符串html符合注释开始的正则，那么就继续向后查找是否存在–>，若存在，则把html从第4位（" 处，截取得到的内容就是注释的真实内容，然后调用4个钩子函数中的comment函数，将真实的注释内容传进去，创建注释类型的AST节点。

上面代码中有一处值得注意的地方，那就是我们平常在模板中可以在标签上配置comments选项来决定在渲染模板时是否保留注释，对应到上面代码中就是options.shouldKeepComment,如果用户配置了comments选项为true，则shouldKeepComment为true，则创建注释类型的AST节点，如不保留注释，则将游标移动到’–>'之后，继续向后解析。

advance函数是用来移动解析游标的，解析完一部分就把游标向后移动一部分，确保不会重复解析，其代码如下：

function advance (n) {
     
  index += n   // index为解析游标
  html = html.substring(n)
}

为了更加直观地说明 advance 的作用，请看下图：

调用 advance 函数：

advance(3)

得到结果：

从图中可以看到，解析游标index最开始在模板字符串的位置0处，当调用了advance(3)之后，解析游标到了位置3处，每次解析完一段内容就将游标向后移动一段，接着再从解析游标往后解析，这样就保证了解析过的内容不会被重复解析。

解析条件注释
解析条件注释也比较简单，其原理跟解析注释相同，都是先用正则判断是否是以条件注释特有的开头标识开始，然后寻找其特有的结束标识，若找到，则说明是条件注释，将其截取出来即可，由于条件注释不存在于真正的DOM树中，所以不需要调用钩子函数创建AST节点。代码如下：

/

/ 解析是否是条件注释
const conditionalComment = /^
if (conditionalComment.test(html)) {
     
  // 若为条件注释，则继续查找是否存在']>'
  const conditionalEnd = html.indexOf(']>')

  if (conditionalEnd >= 0) {
     
    // 若存在 ']>',则从原本的html字符串中把条件注释截掉，
    // 把剩下的内容重新赋给html，继续向后匹配
    advance(conditionalEnd + 2)
    continue
  }
}

解析DOCTYPE
解析DOCTYPE的原理同解析条件注释完全相同，此处不再赘述，代码如下：

const doctype = /^]+>/i
// 解析是否是DOCTYPE
const doctypeMatch = html.match(doctype)
if (doctypeMatch) {
     
  advance(doctypeMatch[0].length)
  continue
}

解析开始标签
相较于前三种内容的解析，解析开始标签会稍微复杂一点，但是万变不离其宗，它的原理还是相通的，都是使用正则去匹配提取。

首先使用开始标签的正则去匹配模板字符串，看模板字符串是否具有开始标签的特征，如下：

/**
 * 匹配开始标签的正则
 */
const ncname = '[a-zA-Z_][\\w\\-\\.]*'
const qnameCapture = `((?:${
       ncname}\\:)?${
       ncname})`
const startTagOpen = new RegExp(`^<${
       qnameCapture}`)

const start = html.match(startTagOpen)
if (start) {
     
  const match = {
     
    tagName: start[1],
    attrs: [],
    start: index
  }
}

// 以开始标签开始的模板：
'
'.match(startTagOpen)  => [','div',index:0,input:'
']
// 以结束标签开始的模板：
'

'.match(startTagOpen) => null // 以文本开始的模板： '我是文本

'.match(startTagOpen) => null

在上面代码中，我们用不同类型的内容去匹配开始标签的正则，发现只有

的字符串可以正确匹配，并且返回一个数组。

在前文中我们说到，当解析到开始标签时，会调用4个钩子函数中的start函数，而start函数需要传递3个参数，分别是标签名tag、标签属性attrs、标签是否自闭合unary。标签名通过正则匹配的结果就可以拿到，即上面代码中的start[1]，而标签属性attrs以及标签是否自闭合unary需要进一步解析。

解析标签属性

我们知道，标签属性一般是写在开始标签的标签名之后的，如下：

<div class="a" id="b"></div>

另外，我们在上面匹配是否是开始标签的正则中已经可以拿到开始标签的标签名，即上面代码中的start[0]，那么我们可以将这一部分先从模板字符串中截掉，则剩下的部分如下：

class=“a” id=“b”>
那么我们只需用剩下的这部分去匹配标签属性的正则，就可以将标签属性提取出来了，如下：

const attribute = /^\s*([^\s"'<>\/=]+)(?:\s*(=)\s*(?:"([^"]*)"+|'([^']*)'+|([^\s"'=<>`]+)))?/
let html = 'class="a" id="b">

' let attr = html.match(attribute) console.log(attr) // ["class="a"", "class", "=", "a", undefined, undefined, index: 0, input: "class="a" id="b">

", groups: undefined]

可以看到，第一个标签属性class="a"已经被拿到了。另外，标签属性有可能有多个也有可能没有，如果没有的话那好办，匹配标签属性的正则就会匹配失败，标签属性就为空数组；而如果标签属性有多个的话，那就需要循环匹配了，匹配出第一个标签属性后，就把该属性截掉，用剩下的字符串继续匹配，直到不再满足正则为止，代码如下：

const attribute = /^\s*([^\s"'<>\/=]+)(?:\s*(=)\s*(?:"([^"]*)"+|'([^']*)'+|([^\s"'=<>`]+)))?/
const startTagClose = /^\s*(\/?)>/
const match = {
     
 tagName: start[1],
 attrs: [],
 start: index
}
while (!(end = html.match(startTagClose)) && (attr = html.match(attribute))) {
     
 advance(attr[0].length)
 match.attrs.push(attr)
}

在上面代码的while循环中，如果剩下的字符串不符合开始标签的结束特征（startTagClose）并且符合标签属性的特征的话，那就说明还有未提取出的标签属性，那就进入循环，继续提取，直到把所有标签属性都提取完毕。

所谓不符合开始标签的结束特征是指当前剩下的字符串不是以开始标签结束符开头的，我们知道一个开始标签的结束符有可能是一个>（非自闭合标签），也有可能是/>（自闭合标签），如果剩下的字符串（如>）以开始标签的结束符开头，那么就表示标签属性已经被提取完毕了。

解析标签是否是自闭合

在HTML中，有自闭合标签（如）也有非自闭合标签（如

），这两种类型的标签在创建AST节点是处理方式是有区别的，所以我们需要解析出当前标签是否是自闭合标签。

解析的方式很简单，我们知道，经过标签属性提取之后，那么剩下的字符串无非就两种，如下：

<!--非自闭合标签-->
></div>

或

<!--自闭合标签-->
/>

所以我们可以用剩下的字符串去匹配开始标签结束符正则，如下：

const startTagClose = /^\s*(\/?)>/
let end = html.match(startTagClose)
'>

'.match(startTagClose) // [">", "", index: 0, input: ">