深入理解虚拟 DOM,它真的不快

大家好,我是桃翁,这里是前端桃园,一个有温度的前端公众号。


前两天发了一篇别再说 React 快了,要被打脸的,有些人一看到标题就开始喷了,有数据支撑吗?你的意思就是 diff 算法慢咯?等等等,对于这种人我也只能呵呵了,文章都没看,就开始喷,杠精怎么来的,就是这么来的。

这两天我在大漠老师的网站上看到这么一篇文章,感觉写得更好,所以转载过来,再次理解一下虚拟 DOM,这里给大漠老师的 w3cplus 打个广告,里面的文章都很好,希望能经常去逛逛。

正文:

使用过React的同学对于Virtual DOM并不陌生,作为React的重要核心概念,Virtual DOM凭借其高效的diff算法,让我们不用关心应用的性能问题,毫无顾忌地修改各种数据状态。在实际的开发中,我们并不需要关注Virtual DOM在一个框架中是如何运行的,但是理解Virtual DOM的实现原理却是非常有必要的,同时也有助于我们更加深入React。

前端应用状态管理

在日益复杂的前端应用中,状态管理是一个经常被提及的话题,从早期的刀耕火种时代到jQuery,再到现在流行的MVVM时代,状态管理的形式发生了翻天覆地的变化,我们再也不用维护茫茫多的事件回调、监听来更新视图,转而使用使用双向数据绑定,只需要维护相应的数据状态,就可以自动更新视图,极大提高开发效率。

但是,双向数据绑定也并不是唯一的办法,还有一个非常粗暴有效的方式:一旦数据发生变化,重新绘制整个视图,也就是重新设置一下innerHTML。这样的做法确实简单、粗暴、有效,但是如果只是因为局部一个小的数据发生变化而更新整个视图,性价比未免太低了,而且,像事件,获取焦点的输入框等,都需要重新处理。所以,对于小的应用或者说局部的小视图,这样处理完全是可以的,但是面对复杂的大型应用,这样的做法不可取。

说到这里,你会说这跟Virtual DOM有什么关系呢?其实Virtual DOM就是这么做的,只是在高效的diff算法计算下,避免对整棵DOM树进行变更,而是进行针对性的视图变更,将效率做到最优化。

什么是Virtual DOM

Virtual DOM的概念有很多解释,从我的理解来看,主要是三个方面,分别是:一个对象,两个前提,三个步骤。

一个对象指的是Virtual DOM是一个基本的JavaScript对象,也是整个Virtual DOM树的基本。

两个前提分别是JavaScript很快和直接操作DOM很慢,这是Virtual DOM得以实现的两个基本前提。得益于V8引擎的出现,让JavaScript可以高效地运行,在性能上有了极大的提高。直接操作DOM的低效和JavaScript的高效相对比,为Virtual DOM的产生提供了大前提。

三个步骤指的是Virtual DOM的三个重要步骤,分别是:生成Virtual DOM树、对比两棵树的差异、更新视图。这三个步骤的具体实现也是本文将简述的一大重点。

Virtual DOM三板斧

下面就将介绍Virtual DOM的三个步骤具体的含义以及实现思路。著作权归作者所有。

  1. 生成 Virtual DOM 树

DOM是前端工程师最常接触的内容之一,一个DOM节点包含了很多的内容,但是一个抽象出一个DOM节点却只需要三部分:节点类型,节点属性、子节点。所以围绕这三个部分,我们可以使用JavaScript简单地实现一棵DOM树,然后给节点实现渲染方法,就可以实现虚拟节点到真是DOM的转化。

  1. 对比两棵树的差异

比较两棵DOM树的差异是Virtual DOM算法最核心的部分,这也是我们常说的的 Virtual DOM的diff算法。在比较的过程中,我们只比较同级的节点,非同级的节点不在我们的比较范围内,这样既可以满足我们的需求,又可以简化算法实现。著作权归作者所有。

比较“树”的差异,首先是要对树进行遍历,常用的有两种遍历算法,分别是深度优先遍历和广度优先遍历,一般的diff算法中都采用的是深度优先遍历。对新旧两棵树进行一次深度优先的遍历,这样每个节点都会有一个唯一的标记。在遍历的时候,每遍历到一个节点就把该节点和新的树的同一个位置的节点进行对比,如果有差异的话就记录到一个对象里面。著作权归作者所有。 商业转载请联系作者获得授权,非商业转载请注明出处。

例如,上面的div和新的div有差异,当前的标记是0,那么:patches[0] = [{difference}, {difference}, …]。同理p是patches[1],ul是patches[3],以此类推。这样当遍历完整棵树的时候,就可以获得一个完整的差异对象。

在这个差异对象中记录了有改变的节点,每一个发生改变的内容也不尽相同,但也是有迹可循,常见的差异包括四种,分别是:

  • 替换节点
  • 增加/删除子节点
  • 修改节点属性
  • 改变文本内容

所以在记录差异的时候要根据不同的差异类型,记录不同的内容。

更新视图

在第二步得到整棵树的差异之后,就可以根据这些差异的不同类型,对DOM进行针对性的更新。与四种差异类型相对应的,是更新视图时具体的更新方法,分别是:

  • replaceChild()
  • appendChild()/removeChild()
  • setAttribute()/removeAttribute()
  • textContent

动手实现Virtual DOM

对原理有了一定的认识之后,自然是动手实现一番了,GitHub上有很多对Virtual DOM的实现,比如simple-virtual-dom(https://github.com/livoras/simple-virtual-dom/)、virtual-dom (https://github.com/Matt-Esch/virtual-dom)等,我也对其进行了一个基本的实现,比较简陋,传送门(https://github.com/y8n/simple-virtual-dom)。

进一步思考

Virtual DOM的原理和实现的说明已经结束了,但是对于Virtual DOM的思考远没有结束,Virtual DOM 对前端开发的影响难道就只是一堆算法吗?

  1. 性能对比

首先,先来看一下性能,在诸多的Virtual DOM实现中,都会强调算法的高效,那么在实际的使用中,Virtual DOM的性能到底如何呢?

上图是对一个简单的DOM树进行不同方式的操作,由左边的结构更新为右边的结构,通过原生操作、jQuery、Virtual DOM和React四种方式,在Chrome的timeline中得到的性能对比,在这个图中,我们并没有看出Virtual DOM或者React的优势,通过对比我们发现,原生的操作要比其他三种方式快,而其他三种方式就相差无几了。当然,这样一个简单测试并没有说明什么,测试的DOM结构简单,和我们平时面对的业务场景不是一个量级,代表不了什么,但是起码我们可以看到,这种情况下好像Virtual DOM并没有我们想象的性能优势。

在接下来的测试中我们增加测试量。上图分别是使用原生操作、Virtual DOM和React三种方式进行两类测试:插入10000个节点100次和修改3000个节点的属性100次。分别取这100次的耗时最大值、最小值和平均值。从图中我们可以看到明显的差异,Virtual DOM和React的差异可以理解,毕竟我们自己实现的Virtual DOM没有那么庞大,只是针对虚拟DOM而实现的,比React快一点可以理解,但是原生的操作比Virtual DOM和React都要快得多,这又是怎么一回事,好像和我们预想的不一样,回到最初,我们提到,Virtual DOM的产生前提之一就是直接操作DOM很慢,现在看来直接操作不但不慢,反而快了很多,这不得不让我产生了怀疑,是我对Virtual DOM的理解有误还是对DOM的理解有误呢?

再次审视Virtual DOM

框架存在的意义是什么?是提高性能?提高开发效率?亦或是其他用途,每个人对框架的理解不同,答案也不尽相同。但是不得不承认,存在框架的情况下,项目的可维护性有了极大的提高,而对于其他方面就要做出牺牲,比如性能。在上面的性能测试中,其实完全走入了一个误区,在测试中我们用到的原生的操作其实是“人为”地对操作进行优化之后的结果,而如果抛开人为优化的前提,最终的结果可能就不是这样了。Virtual DOM的优势不在于单次的操作,而是在大量、频繁的数据更新下,能够对视图进行合理、高效的更新。这一点是原生操作远远无法替代的。

到此为止,再次审视Virtual DOM,可以简单得出如下结论:

  • Virtual DOM 在牺牲部分性能的前提下,增加了可维护性,这也是很多框架的通性
  • 实现了对DOM的集中化操作,在数据改变时先对虚拟DOM进行修改,再反映到真实的DOM中,用最小的代价来更新DOM,提高效率
  • 打开了函数式UI编程的大门
  • 可以渲染到DOM以外的端,比如ReactNative

结语

本文对Virtual DOM有一个简单的介绍,包括实现的部分也很简单,甚至对列表的diff算法也偷工减料,跟多高级的特性也没有涉及,比如事件绑定、生命周期、JSX语法等,如果加上这些内容,就是一个小型版的React了。

本文旨在让大家了解并认识 Virtual DOM 的基本概念、组成和实现,同时对Virtual DOM更深层的意义有所了解,这样在以后用到相关的框架的时候也不会两眼一抹黑了,起码在性能优化上有点认识,比如列表要带上key这样基本的优化操作。

都看到这儿了,点个赞再走吧! 另外再说一句,当遇到颠覆自己认知的时候,不要总觉得你自己的是对的,很多时候你一直以为都是错的,从你最开始学这个的时候。这个时候我们不要做杠精,应该做一个探索者,好好看看别人的文章是否有道理,感觉还是不能说服自己就去网上查资料,再好好审视一下,别人为什么要这么说。 不要做杠精、不要做杠精、不要做杠精


原文链接:https://www.w3cplus.com/javascript/understand-the-Virtual-DOM.html

原文发布于微信公众号 - 前端桃园(betaoyuan)

原文发表时间:2018-11-23

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏九彩拼盘的叨叨叨

用 CSS 3 来做个平安果吧~

圣诞将至,我们就用 CSS 3 来做个平安果吧~ 愿所有程序猿和媛们都平安夜不加班~

933
来自专栏HT

HT全矢量化的图形组件设计

HT一直被客户称道的就是其全矢量化的设计特色,矢量相比传统图片好处太多了: 矢量可无级缩放,界面不失真不模糊 描述矢量的文本内容远比图片小得多 目...

2429
来自专栏MelonTeam专栏

小白看React Native

1.What is React Native ? 众所周知,产品的需求总是想快速的迭代。但是由于应用分发市场的审核机制(主要是iOS审核),使一些快速迭代的...

8938
来自专栏前端说吧

echarts - 特殊需求实现代码汇总之【饼图】篇

其实很简单,就是设置全局的color属性即可。color属性可以是一套数组,里边的样式以字符串格式设置。

1511
来自专栏张高兴的博客

使用 Babylon.js 在 HTML 页面加载 3D 对象

2185
来自专栏水击三千

radio与checkbox

最近一直在学习Javascript与asp.net MVC4,每天都在跟着书学习。这样总感觉自己看的很抽象,没有点实际的意义。而且,每次看的东西很容易忘记,所以...

2679
来自专栏数据小魔方

Xcelsius(水晶易表)系列7——多选择器交互用法

今天继续跟大家讲解水晶易表动态仪表盘的高级用法——多选择器交互用法。 关于选择器的用法,之前的几篇零零碎碎的讲了些,今天是专门讲解水晶易表中几种重要的选择器用法...

3376
来自专栏web前端教室

有空看看jQuery源码吧,看不懂也会有收获

jQuery是一个对新人很亲切的JS库,它的源码风格都比较接近自然语言,可以一边对照手册,一边查看jQuery源码。第一次看必然很吃力,不过没关系,这就是学习的...

1946
来自专栏菜鸟前端工程师

html+css学习笔记009-定位

1072
来自专栏python小白到大牛

用 Python 实现打飞机,让子弹飞吧!

安装好 pygame 在第一次使用 pygame 的时候,pyCharm 会自动 install pygame。

2163

扫码关注云+社区

领取腾讯云代金券