为什么需要虚拟DOM？

Posted 2021-04-13 前端路人甲

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了为什么需要虚拟DOM？相关的知识，希望对你有一定的参考价值。

https://blog.csdn.net/qq_41694291/article/details/108306019

真实DOM操作的性能问题

在虚拟DOM出现之前，前端开发者最常用的方式是用jQuery直接操作真实DOM，像下面这样：

<body> <div id="root"></div> <script> $('#root').text('这是一段文本'); // 或者这种原生的方式 // var root = document.querySelector('#root'); // root.textContent = '这是一段文本';</script></body>

在本例中，jQuery只是提供了一层对原生DOM操作的封装。我们可以简单手写一个$实现：

function $ (selector) { this.nodeList = document.querySelectorAll(selector); return this;}
$.prototype.text = function (textContent) { this.nodeList.forEach(node => { node.textContent = textContent; }); return this;}

通过这个简单的封装我们可以发现，jQuery的主要工作是提供对原生DOM操作的统一实现（另外还有对原生js的增强，如ajax、动画等）。换句话说，使用jQuery，本质上还是在直接操作真实DOM。

那么直接操作真实DOM有什么问题呢？

这就要从浏览器内核的构成说起了。我们以webkit内核为例，它大致包含以下模块（图片来自网络）：

首先来看左侧的深色区域，它是webkit内核的WebCore层。该区域左下角的html模块代表HTML引擎，作用是解析HTML文档。当浏览器下载了一个HTML文档后，它负责将该文档解析成DOM树，也就是由一个个标签节点构成的文档树。最终解析出来的DOM树将交由它右侧的DOM模块负责管理，而这个DOM树就是我们平常所说的真实DOM。

在深色区域的右侧紧邻着的是javascriptCore，即webkit默认的JavaScript引擎（在Chrome和chromium中它被替换为了V8），它负责执行JavaScript代码。

我们知道，JavaScript具备操作DOM树的能力。但是从浏览器内核的结构可以看到，DOM树由DOM模块负责管理，在浏览器内核中单独占有一块内存，而这块内存与JavaScript引擎所管理的内存并无直接关系。换句话说，JavaScript引擎不能直接操作真实DOM树。

为了给JavaScript提供操作DOM树的能力，浏览器在全局对象window上为JavaScript封装了一个document对象，然后在该对象上提供了大量的DOM操作接口，这些接口都是用C++实现的。如：

在浏览器控制台查看document.getElementById，可以看到它的函数体是{ [native code] }，这表示它是一个用C++编写的函数，因此无法查看具体实现。当我们在调用这个函数时，JavaScript引擎并没有直接与DOM模块交互，而是由浏览器来操作DOM模块，随后再把操作结果返回给JavaScript引擎。这种借助父级模块实现两个同级模块交互的通信方式非常常见。

正是由于JavaScript需要借助浏览器提供的DOM接口才能操作真实DOM，所以操作真实DOM的代价往往是比较大的（这其中还涉及C++与JavaScript数据结构的转换问题）。再加上修改DOM经常导致页面重绘，所以一般来说，DOM操作越多，网页的性能就越差。我们以一个简单的图例来理解这个过程：

有人可能会问，既然DOM操作的代价如此之大，为什么不由JavaScript引擎来管理DOM呢？不要忘了，世界上第一款浏览器诞生于1990年，那时候就已经出现了DOM的原始概念，而JavaScript则直到1995年才诞生。换句话说，DOM的出现早于JavaScript。因此，如果要由JavaScript来管理DOM，那就意味着浏览器内核必须重构。而让浏览器开发者为了一个早期被称为“玩具语言”的JavaScript重构浏览器内核显然是不可能的。不过随着JavaScript的发展，由JavaScript引擎直接管理DOM的构想已经被提上了chromium的计划列表（目前只是定为长期计划，要真正实现还需要相当长的时间）。

所以，截止到目前，如何有效地减少对真实DOM的操作，仍然是前端性能优化的一个关键点。虚拟DOM就是目前较为流行的一个解决方案。

虚拟DOM的作用

显然，JavaScript无法直接操作DOM是带来上述性能问题的根源之一（其他原因包括，真实DOM树的体积非常庞大，而且操作它会导致页面重绘）。那么能不能在JavaScript内存中，以js对象的形式也描述一棵DOM树呢？当然可以，这就是我们所说的虚拟DOM树。

可以看到，虚拟DOM并不能消除原生的DOM操作，你仍然需要通过浏览器提供的DOM接口来操作真实DOM树，才能使页面发生改变。虚拟DOM的设计似乎是多此一举。

但是虚拟DOM带来了一个重要的优势，那就是我们可以在完全不访问真实DOM的情况下，掌握DOM的结构，这为框架自动优化DOM操作提供了可能。举例来说，如果我们本打算手动进行三次真实DOM操作，而框架在分析了虚拟DOM的结构后，把这三次DOM操作简化成了一次，这不就带来了性能上的提升吗？再甚者，如果连这一次DOM操作都可以由框架自动完成（自动更新的前提是我们要定义视图和数据的绑定关系），而我们只需要负责处理数据，那么虚拟DOM的价值体现得就更明显了。

React就是这么使用虚拟DOM的。

当我们使用jsx语法定义一个模板时，React会用它生成一个由JavaScript描述的虚拟DOM树，并将其保存在JavaScript内存中。这个虚拟DOM树还保留了我们在模板中定义的数据和视图的绑定关系，这为React自动根据数据变化更新视图提供了可能。随后当数据发生变化时，React重新生成一个虚拟DOM树，通过对比两个虚拟DOM树的差异，React就可以知道该如何高效地更新视图。接着它就会调用原生的DOM接口，去更新真实DOM。过程大致如下：

对于开发者而言，虚拟DOM的实现是透明的，它只是框架自动高效更新DOM的一种内部解决方案。开发者需要按照框架给定的语法定义数据和视图的绑定关系，随后就只需要关心数据变化（即业务逻辑）即可。

当然了，虚拟DOM并不是解决DOM操作性能问题的唯一解决方案，Vue的响应式系统也是一种重要的解决方案。从某种程度上来说，Vue依靠响应式系统可以实现“精确定点更新”，即直接定位到哪个DOM节点需要更新，而不需要经过虚拟DOM的比对，不过“精确定点更新”的内存代价偏大，因此目前Vue采用了响应式系统和虚拟DOM结合的方式，本文暂不详述。

最后我们来看一下Vue中虚拟DOM树的结构，实际上它就是一个js对象而已，我们以下面的模板为例：

<template> <div id="app"> <ul> <li v-for=“item in items”> itemid: {{ item.id }} </li> </ul> </div></template>

对应的虚拟DOM：

总结

要理解为什么需要虚拟DOM，必须弄清楚JavaScript引擎和DOM模块之间的关系，并体会由这种关系导致的DOM操作的性能问题。虚拟DOM设计的核心就是用高效的js操作，来减少低性能的DOM操作，以此来提升网页性能。

从一定程度上来说，是浏览器的架构问题催生了虚拟DOM，而这个架构问题几乎需要重构浏览器内核才能解决，所以目前虚拟DOM仍广为流行。如果未来的某一天，真实DOM被迁移到JavaScript内存中，虚拟DOM的价值实际上也就不存在了。

更多前端分享，请关注：

前端路人甲