Vue源码解析：虚拟dom详解

冷不防 2022-11-04 13:23 273阅读 0赞

一句话：vue的虚拟dom是将多次dom操作保存在一个js对象（虚拟dom对象）中，然后用这个js对象一次性的去更新dom操作，这样就避免了很多无效的计算

#### 一、DOM和其解析流程？ ####

创建DOM树——创建StyleRules——创建Render树——布局Layout——绘制Painting

*  第一步，用HTML分析器，分析HTML元素，构建一颗DOM树(标记化和树构建)。
 *  第二步，用CSS分析器，分析CSS文件和元素上的inline样式，生成页面的样式表。
 *  第三步，将DOM树和样式表，关联起来，构建一颗Render树(这一过程又称为Attachment)。每个DOM节点都有attach方法，接受样式信息，返回一个render对象(又名renderer)。这些render对象最终会被构建成一颗Render树。
 *  第四步，有了Render树，浏览器开始布局，为每个Render树上的节点确定一个在显示屏上出现的精确坐标。
 *  第五步，Render树和节点显示坐标都有了，就调用每个节点paint方法，把它们绘制出来。

#### 1.webkit渲染引擎工作流程 ####

![webkit渲染引擎工作流程][webkit]

### 2、DOM树的构建是文档加载完成开始的？ ###

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

#### 3、Render树是DOM树和CSSOM树构建完毕才开始构建的吗？ ####

不是，交叉进行：这三个过程（Render树、DOM树、CSSOM树）在实际进行的时候又不是完全独立，而是会有交叉。会造成一边加载，一遍解析，一遍渲染的工作现象

#### 4、为什么原生js操作或者jquery操作的dom消耗很大？ ####

a、【更新dom都会从头到尾更新】：用原生JS或JQ操作DOM时，浏览器会从构建DOM树开始从头到尾执行一遍流程。  
b、【有多次dom操作会操作dom更新多次】：在一次操作中，我需要更新10个DOM节点，浏览器收到第一个DOM请求后并不知道还有9次更新操作，因此会马上执行流程，最终执行10次。  
c、【dom更新会导致前一次计算的结果无效】：例如，第一次计算完，紧接着下一个DOM更新请求，这个节点的坐标值就变了，前一次计算为无用功。

#### 5、为什么需要虚拟DOM，它有什么好处？ ####

【将这10次dom更新的diff内容保存到本地一个JS对象中】：若一次操作中有10次更新DOM的动作，虚拟DOM不会立即操作DOM，而是将这10次更新的diff内容保存到本地一个JS对象中，最终将这个JS对象一次性attch到DOM树上，再进行后续操作，避免大量无谓的计算量。

#### 6、用JS对象模拟DOM节点的好处是什么？ ####

页面的更新可以先全部反映在JS对象(虚拟DOM)上，操作内存中的JS对象的速度显然要更快，等更新完成后，再将最终的JS对象映射成真实的DOM，交由浏览器去绘制。

##### 7. CSS的解析 #####

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

#### 二、实现虚拟DOM ####

例如一个真实的DOM节点。  
![真实DOM][DOM]  
我们用JS来模拟DOM节点实现虚拟DOM  
![虚拟DOM][DOM 1]  
其中的Element方法具体怎么实现的呢？  
![Element方法实现][Element]  
第一个参数是节点名（如div），第二个参数是节点的属性（如class），第三个参数是子节点（如ul的li）。除了这三个参数会被保存在对象上外，还保存了key和count。其相当于形成了虚拟DOM树。

![虚拟DOM树][DOM 2]  
有了JS对象后，最终还需要将其映射成真实DOM  
![虚拟DOM对象映射成真实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。此时不会触发节点卸载和装载，而是节点更新。  
![查找不同属性方法][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDQzMzQ5OQ_size_16_color_FFFFFF_t_70]  
3、文本变了，文本对也是一个Text Node，也比较简单，直接修改文字内容就行了，我们将这个过程称之为TEXT。

4、移动／增加／删除 子节点，我们将这个过程称之为REORDER。看一个例子，在A、B、C、D、E五个节点的B和C中的BC两个节点中间加入一个F节点。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDQzMzQ5OQ_size_16_color_FFFFFF_t_70 1]

例子  
我们简单粗暴的做法是遍历每一个新虚拟DOM的节点，与旧虚拟DOM对比相应节点对比，在旧DOM中是否存在，不同就卸载原来的按上新的。这样会对F后边每一个节点进行操作。卸载C，装载F，卸载D，装载C，卸载E，装载D，装载E。效率太低。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDQzMzQ5OQ_size_16_color_FFFFFF_t_70 2]  
粗暴做法  
如果我们在JSX里为数组或枚举型元素增加上key后，它能够根据key，直接找到具体位置进行操作，效率比较高。常见的最小编辑距离问题，可以用Levenshtein Distance算法来实现，时间复杂度是O(M\*N)，但通常我们只要一些简单的移动就能满足需要，降低精确性，将时间复杂度降低到O(max(M,N))即可。  
![最终Diff出来的结果][Diff]

#### 映射成真实DOM ####

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

![根据Diff更新DOM][Diff_DOM 1]  
我们会有两个虚拟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里，这就是框架的价值，程序员才能专注于写业务代码。

仅做学习记录，参考文章：[https://www.jianshu.com/p/af0b398602bc][https_www.jianshu.com_p_af0b398602bc]

[webkit]: /images/20221023/25012610dc374467b527d0cb91ab05cc.png
[DOM]: /images/20221023/f823d7021d9446e9b746b711f99cdef7.png
[DOM 1]: /images/20221023/0269483f51bb4e0cb2a8675df5908b1c.png
[Element]: /images/20221023/617907117a7b49e5b8b151f552d142c6.png
[DOM 2]: /images/20221023/95798694fb254d668e0d4ed1336a1898.png
[DOM_DOM]: /images/20221023/22dbd48e33cb4839a5d7166b31e9d60b.png
[old Tree]: /images/20221023/307d819f15c44f76b3a0cff6efa6a3e7.png
[new Tree]: /images/20221023/2a5bd8451fa340b1ae05e712e2b22158.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDQzMzQ5OQ_size_16_color_FFFFFF_t_70]: /images/20221023/7b28e501113345babc9c5ae1836e7dad.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDQzMzQ5OQ_size_16_color_FFFFFF_t_70 1]: /images/20221023/aaf0b6dbec5a4f4b8995f7a2c8b62323.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDQzMzQ5OQ_size_16_color_FFFFFF_t_70 2]: /images/20221023/7e320b2e8c6a4120b91244374fb59ae2.png
[Diff]: /images/20221023/137574fde18949b98b38cf159d3f734a.png
[Diff_DOM]: /images/20221023/19a015d65ec24193ad7636257cc29fb7.png
[Diff_DOM 1]: /images/20221023/6ecdbeceace343fe972455dab1f1da6c.png
[https_www.jianshu.com_p_af0b398602bc]: https://www.jianshu.com/p/af0b398602bc