为什么需要虚拟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的价值实际上也就不存在了。
更多前端分享,请关注:
前端路人甲