vue虚拟dom 以及diff 算法

一、真实DOM和其解析流程？

浏览器渲染引擎工作流程都差不多，大致分为5步，创建DOM树——创建StyleRules——创建Render树——布局Layout——绘制Painting

第一步，用HTML分析器，分析HTML元素，构建一颗DOM树(标记化和树构建)。

第二步，用CSS分析器，分析CSS文件和元素上的inline样式，生成页面的样式表。

第三步，将DOM树和样式表，关联起来，构建一颗Render树(这一过程又称为Attachment)。每个DOM节点都有attach方法，接受样式信息，返回一个render对象(又名renderer)。这些render对象最终会被构建成一颗Render树。

第四步，有了Render树，浏览器开始布局，为每个Render树上的节点确定一个在显示屏上出现的精确坐标。

第五步，Render树和节点显示坐标都有了，就调用每个节点paint方法，把它们绘制出来。

DOM树的构建是文档加载完成开始的？构建DOM数是一个渐进过程，为达到更好用户体验，渲染引擎会尽快将内容显示在屏幕上。它不必等到整个HTML文档解析完毕之后才开始构建render数和布局。

Render树是DOM树和CSSOM树构建完毕才开始构建的吗？这三个过程在实际进行的时候又不是完全独立，而是会有交叉。会造成一边加载，一遍解析，一遍渲染的工作现象。

CSS的解析是从右往左逆向解析的(从DOM树的下－上解析比上－下解析效率高)，嵌套标签越多，解析越慢。

webkit渲染引擎工作流程

二、JS操作真实DOM的代价！

用我们传统的开发模式，原生JS或JQ操作DOM时，浏览器会从构建DOM树开始从头到尾执行一遍流程。在一次操作中，我需要更新10个DOM节点，浏览器收到第一个DOM请求后并不知道还有9次更新操作，因此会马上执行流程，最终执行10次。例如，第一次计算完，紧接着下一个DOM更新请求，这个节点的坐标值就变了，前一次计算为无用功。计算DOM节点坐标值等都是白白浪费的性能。即使计算机硬件一直在迭代更新，操作DOM的代价仍旧是昂贵的，频繁操作还是会出现页面卡顿，影响用户体验。

三、为什么需要虚拟DOM，它有什么好处?

Web界面由DOM树(树的意思是数据结构)来构建，当其中一部分发生变化时，其实就是对应某个DOM节点发生了变化，

虚拟DOM就是为了解决浏览器性能问题而被设计出来的。如前，若一次操作中有10次更新DOM的动作，虚拟DOM不会立即操作DOM，而是将这10次更新的diff内容保存到本地一个JS对象中，最终将这个JS对象一次性attch到DOM树上，再进行后续操作，避免大量无谓的计算量。所以，用JS对象模拟DOM节点的好处是，页面的更新可以先全部反映在JS对象(虚拟DOM)上，操作内存中的JS对象的速度显然要更快，等更新完成后，再将最终的JS对象映射成真实的DOM，交由浏览器去绘制。

四、实现虚拟DOM

例如一个真实的DOM节点。

真实DOM

我们用JS来模拟DOM节点实现虚拟DOM。

虚拟DOM

其中的Element方法具体怎么实现的呢？

Element方法实现

第一个参数是节点名（如div），第二个参数是节点的属性（如class），第三个参数是子节点（如ul的li）。除了这三个参数会被保存在对象上外，还保存了key和count。其相当于形成了虚拟DOM树。

虚拟DOM树

有了JS对象后，最终还需要将其映射成真实DOM

虚拟DOM对象映射成真实DOM

我们已经完成了创建虚拟DOM并将其映射成真实DOM，这样所有的更新都可以先反应到虚拟DOM上，如何反应？需要用到Diff算法。

两棵树如果完全比较时间复杂度是O(n^3)，但参照《深入浅出React和Redux》一书中的介绍，React的Diff算法的时间复杂度是O(n)。要实现这么低的时间复杂度，意味着只能平层的比较两棵树的节点，放弃了深度遍历。这样做，似乎牺牲掉了一定的精确性来换取速度，但考虑到现实中前端页面通常也不会跨层移动DOM元素，这样做是最优的。

深度优先遍历，记录差异

。。。。

Diff操作

在实际代码中，会对新旧两棵树进行一个深度的遍历，每个节点都会有一个标记。每遍历到一个节点就把该节点和新的树进行对比，如果有差异就记录到一个对象中。

下面我们创建一棵新树，用于和之前的树进行比较，来看看Diff算法是怎么操作的。

old Tree

new Tree

平层Diff，只有以下4种情况：

1、节点类型变了，例如下图中的P变成了H3。我们将这个过程称之为REPLACE。直接将旧节点卸载并装载新节点。旧节点包括下面的子节点都将被卸载，如果新节点和旧节点仅仅是类型不同，但下面的所有子节点都一样时，这样做效率不高。但为了避免O(n^3)的时间复杂度，这样是值得的。这也提醒了开发者，应该避免无谓的节点类型的变化，例如运行时将div变成p没有意义。

2、节点类型一样，仅仅属性或属性值变了。我们将这个过程称之为PROPS。此时不会触发节点卸载和装载，而是节点更新。

查找不同属性方法

3、文本变了，文本对也是一个Text Node，也比较简单，直接修改文字内容就行了，我们将这个过程称之为TEXT。

4、移动／增加／删除子节点，我们将这个过程称之为REORDER。看一个例子，在A、B、C、D、E五个节点的B和C中的BC两个节点中间加入一个F节点。

例子

我们简单粗暴的做法是遍历每一个新虚拟DOM的节点，与旧虚拟DOM对比相应节点对比，在旧DOM中是否存在，不同就卸载原来的按上新的。这样会对F后边每一个节点进行操作。卸载C，装载F，卸载D，装载C，卸载E，装载D，装载E。效率太低。

粗暴做法

如果我们在JSX里为数组或枚举型元素增加上key后，它能够根据key，直接找到具体位置进行操作，效率比较高。常见的最小编辑距离问题，可以用Levenshtein Distance算法来实现，时间复杂度是O(M*N)，但通常我们只要一些简单的移动就能满足需要，降低精确性，将时间复杂度降低到O(max(M,N))即可。

最终Diff出来的结果

映射成真实DOM

虚拟DOM有了，Diff也有了，现在就可以将Diff应用到真实DOM上了。深度遍历DOM将Diff的内容更新进去。

根据Diff更新DOM

我们会有两个虚拟DOM(js对象，new/old进行比较diff)，用户交互我们操作数据变化new虚拟DOM，old虚拟DOM会映射成实际DOM(js对象生成的DOM文档)通过DOM fragment操作给浏览器渲染。当修改new虚拟DOM，会把newDOM和oldDOM通过diff算法比较，得出diff结果数据表(用4种变换情况表示)。再把diff结果表通过DOM fragment更新到浏览器DOM中。

虚拟DOM的存在的意义？vdom 的真正意义是为了实现跨平台，服务端渲染，以及提供一个性能还算不错 Dom 更新策略。vdom 让整个 mvvm 框架灵活了起来

Diff算法只是为了虚拟DOM比较替换效率更高，通过Diff算法得到diff算法结果数据表(需要进行哪些操作记录表)。原本要操作的DOM在vue这边还是要操作的，只不过用到了js的DOM fragment来操作dom（统一计算出所有变化后统一更新一次DOM）进行浏览器DOM一次性更新。其实DOM fragment我们不用平时发开也能用，但是这样程序员写业务代码就用把DOM操作放到fragment里，这就是框架的价值，程序员才能专注于写业务代码。

=======================

先说一下为什么会有虚拟dom比较这一阶段，我们知道了Vue是数据驱动视图（数据的变化将引起视图的变化），但你发现某个数据改变时，视图是局部刷新而不是整个重新渲染，如何精准的找到数据对应的视图并进行更新呢？那就需要拿到数据改变前后的dom结构，找到差异点并进行更新！

虚拟dom实质上是针对真实dom提炼出的简单对象。就像一个简单的div包含200多个属性，但真正需要的可能只有tagName，所以对真实dom直接操作将大大影响性能！
图片描述

简化后的虚拟节点（vnode）大致包含以下属性：

{
  tag: 'div',       // 标签名
  data: {},         // 属性数据，包括class、style、event、props、attrs等
  children: [],     // 子节点数组，也是vnode结构
  text: undefined,  // 文本
  elm: undefined,   // 真实dom
  key: undefined    // 节点标识
}

虚拟dom的比较，就是找出新节点（vnode）和旧节点（oldVnode）之间的差异，然后对差异进行打补丁（patch）。大致流程如下

整个过程还是比较简单的，新旧节点如果不相似，直接根据新节点创建dom；如果相似，先是对data比较，包括class、style、event、props、attrs等，有不同就调用对应的update函数，然后是对子节点的比较，子节点的比较用到了diff算法，这应该是这篇文章的重点和难点吧。

值得注意的是，在Children Compare 过程中，如果找到了相似的childVnode，那它们将递归进入新的打补丁过程。

源码解析

这次的源码解析写简洁一点，写太多发现自己都不愿意看 (┬＿┬)

开始

先来看patch()函数：

function patch (oldVnode, vnode) {
  var elm, parent;
  if (sameVnode(oldVnode, vnode)) {
    // 相似就去打补丁（增删改）
    patchVnode(oldVnode, vnode);
  } else {
    // 不相似就整个覆盖
    elm = oldVnode.elm;
    parent = api.parentNode(elm);
    createElm(vnode);
    if (parent !== null) {
      api.insertBefore(parent, vnode.elm, api.nextSibling(elm));
      removeVnodes(parent, [oldVnode], 0, 0);
    }
  }
  return vnode.elm;
}

patch()函数接收新旧vnode两个参数，传入的这两个参数有个很大的区别：oldVnode的elm指向真实dom，而vnode的elm为undefined...但经过patch()方法后，vnode的elm也将指向这个（更新过的）真实dom。

判断新旧vnode是否相似的sameVnode()方法很简单，就是比较tag和key是否一致。

function sameVnode (a, b) {
  return a.key === b.key && a.tag === b.tag;
}

打补丁

对于新旧vnode不一致的处理方法很简单，就是根据vnode创建真实dom，代替oldVnode中的elm插入DOM文档。

对于新旧vnode一致的处理，就是我们前面经常说到的打补丁了。具体什么是打补丁？看看patchVnode()方法就知道了：

function patchVnode (oldVnode, vnode) {
  // 新节点引用旧节点的dom
  let elm = vnode.elm = oldVnode.elm;
  const oldCh = oldVnode.children;
  const ch = vnode.children;

  // 调用update钩子
  if (vnode.data) {
    updateAttrs(oldVnode, vnode);
    updateClass(oldVnode, vnode);
    updateEventListeners(oldVnode, vnode);
    updateProps(oldVnode, vnode);
    updateStyle(oldVnode, vnode);
  }

  // 判断是否为文本节点
  if (vnode.text == undefined) {
    if (isDef(oldCh) && isDef(ch)) {
      if (oldCh !== ch) updateChildren(elm, oldCh, ch, insertedVnodeQueue)
    } else if (isDef(ch)) {
      if (isDef(oldVnode.text)) api.setTextContent(elm, '')
      addVnodes(elm, null, ch, 0, ch.length - 1, insertedVnodeQueue)
    } else if (isDef(oldCh)) {
      removeVnodes(elm, oldCh, 0, oldCh.length - 1)
    } else if (isDef(oldVnode.text)) {
      api.setTextContent(elm, '')
    }
  } else if (oldVnode.text !== vnode.text) {
    api.setTextContent(elm, vnode.text)
  }
}

打补丁其实就是调用各种updateXXX()函数，更新真实dom的各个属性。每个的update函数都类似，就拿updateAttrs()举例看看：

function updateAttrs (oldVnode, vnode) {
  let key, cur, old
  const elm = vnode.elm
  const oldAttrs = oldVnode.data.attrs || {}
  const attrs = vnode.data.attrs || {}

  // 更新/添加属性
  for (key in attrs) {
    cur = attrs[key]
    old = oldAttrs[key]
    if (old !== cur) {
      if (booleanAttrsDict[key] && cur == null) {
        elm.removeAttribute(key)
      } else {
        elm.setAttribute(key, cur)
      }
    }
  }
  // 删除新节点不存在的属性
  for (key in oldAttrs) {
    if (!(key in attrs)) {
      elm.removeAttribute(key)
    }
  }
}

属性（Attribute）的更新函数的大致思路就是：

遍历vnode属性，如果和oldVnode不一样就调用setAttribute()修改；
遍历oldVnode属性，如果不在vnode属性中就调用removeAttribute()删除。

你会发现里面有个booleanAttrsDict[key]的判断，是用于判断在不在布尔类型属性字典中。

['allowfullscreen', 'async', 'autofocus', 'autoplay', 'checked', 'compact', 'controls', 'declare', ......]
eg: <video autoplay></video>，想关闭自动播放，需要移除该属性。

所有数据比较完后，就到子节点的比较了。先判断当前vnode是否为文本节点，如果是文本节点就不用考虑子节点的比较；若是元素节点，就需要分三种情况考虑：

新旧节点都有children，那就进入子节点的比较（diff算法）；
新节点有children，旧节点没有，那就循环创建dom节点；
新节点没有children，旧节点有，那就循环删除dom节点。

后面两种情况都比较简单，我们直接对第一种情况，子节点的比较进行分析。

diff算法

子节点比较这部分代码比较多，先说说原理后面再贴代码。先看一张子节点比较的图：

图中的oldCh和newCh分别表示新旧子节点数组，它们都有自己的头尾指针oldStartIdx，oldEndIdx，newStartIdx，newEndIdx，数组里面存储的是vnode，为了容易理解就用a,b,c,d等代替，它们表示不同类型标签（div,span,p）的vnode对象。

子节点的比较实质上就是循环进行头尾节点比较。循环结束的标志就是：旧子节点数组或新子节点数组遍历完，（即 oldStartIdx > oldEndIdx || newStartIdx > newEndIdx）。大概看一下循环流程：

第一步头头比较。若相似，旧头新头指针后移（即 oldStartIdx++ && newStartIdx++），真实dom不变，进入下一次循环；不相似，进入第二步。
第二步尾尾比较。若相似，旧尾新尾指针前移（即 oldEndIdx-- && newEndIdx--），真实dom不变，进入下一次循环；不相似，进入第三步。
第三步头尾比较。若相似，旧头指针后移，新尾指针前移（即 oldStartIdx++ && newEndIdx--），未确认dom序列中的头移到尾，进入下一次循环；不相似，进入第四步。
第四步尾头比较。若相似，旧尾指针前移，新头指针后移（即 oldEndIdx-- && newStartIdx++），未确认dom序列中的尾移到头，进入下一次循环；不相似，进入第五步。
第五步若节点有key且在旧子节点数组中找到sameVnode（tag和key都一致），则将其dom移动到当前真实dom序列的头部，新头指针后移（即 newStartIdx++）；否则，vnode对应的dom（vnode[newStartIdx].elm）插入当前真实dom序列的头部，新头指针后移（即 newStartIdx++）。

先看看没有key的情况，放个动图看得更清楚些！
图片描述
相信看完图片有更好的理解到diff算法的精髓，整个过程还是比较简单的。上图中一共进入了6次循环，涉及了每一种情况，逐个叙述一下：

第一次是头头相似（都是a），dom不改变，新旧头指针均后移。a节点确认后，真实dom序列为：a,b,c,d,e,f，未确认dom序列为：b,c,d,e,f；
第二次是尾尾相似（都是f），dom不改变，新旧尾指针均前移。f节点确认后，真实dom序列为：a,b,c,d,e,f，未确认dom序列为：b,c,d,e；
第三次是头尾相似（都是b），当前剩余真实dom序列中的头移到尾，旧头指针后移，新尾指针前移。b节点确认后，真实dom序列为：a,c,d,e,b,f，未确认dom序列为：c,d,e；
第四次是尾头相似（都是e），当前剩余真实dom序列中的尾移到头，旧尾指针前移，新头指针后移。e节点确认后，真实dom序列为：a,e,c,d,b,f，未确认dom序列为：c,d；
第五次是均不相似，直接插入到未确认dom序列头部。g节点插入后，真实dom序列为：a,e,g,c,d,b,f，未确认dom序列为：c,d；
第六次是均不相似，直接插入到未确认dom序列头部。h节点插入后，真实dom序列为：a,e,g,h,c,d,b,f，未确认dom序列为：c,d；

但结束循环后，有两种情况需要考虑：

新的字节点数组（newCh）被遍历完（newStartIdx > newEndIdx）。那就需要把多余的旧dom（oldStartIdx -> oldEndIdx）都删除，上述例子中就是c,d；
新的字节点数组（oldCh）被遍历完（oldStartIdx > oldEndIdx）。那就需要把多余的新dom（newStartIdx -> newEndIdx）都添加。

上面说了这么多都是没有key的情况，说添加了:key可以优化v-for的性能，到底是怎么回事呢？因为v-for大部分情况下生成的都是相同tag的标签，如果没有key标识，那么相当于每次头头比较都能成功。你想想如果你往v-for绑定的数组头部push数据，那么整个dom将全部刷新一遍（如果数组每项内容都不一样），那加了key会有什么帮助呢？这边引用一张图：

有key的情况，其实就是多了一步匹配查找的过程。也就是上面循环流程中的第五步，会尝试去旧子节点数组中找到与当前新子节点相似的节点，减少dom的操作！

有兴趣的可以看看代码：

function updateChildren (parentElm, oldCh, newCh) {
  let oldStartIdx = 0
  let newStartIdx = 0
  let oldEndIdx = oldCh.length - 1
  let oldStartVnode = oldCh[0]
  let oldEndVnode = oldCh[oldEndIdx]
  let newEndIdx = newCh.length - 1
  let newStartVnode = newCh[0]
  let newEndVnode = newCh[newEndIdx]
  let oldKeyToIdx, idxInOld, elmToMove, before

  while (oldStartIdx <= oldEndIdx && newStartIdx <= newEndIdx) {
    if (isUndef(oldStartVnode)) {
      oldStartVnode = oldCh[++oldStartIdx] // 未定义表示被移动过
    } else if (isUndef(oldEndVnode)) {
      oldEndVnode = oldCh[--oldEndIdx]
    } else if (sameVnode(oldStartVnode, newStartVnode)) { // 头头相似
      patchVnode(oldStartVnode, newStartVnode)
      oldStartVnode = oldCh[++oldStartIdx]
      newStartVnode = newCh[++newStartIdx]
    } else if (sameVnode(oldEndVnode, newEndVnode)) { // 尾尾相似
      patchVnode(oldEndVnode, newEndVnode)
      oldEndVnode = oldCh[--oldEndIdx]
      newEndVnode = newCh[--newEndIdx]
    } else if (sameVnode(oldStartVnode, newEndVnode)) { // 头尾相似

posted @ 2020-03-04 21:13 DAVENEE 阅读(1672) 评论(0) 编辑收藏举报

刷新页面返回顶部

DAVENEE