Virtual DOM 真的比操作原生 DOM 快吗?

1. 原生 DOM 操作 vs. 通过框架封装操作。

这是一个性能 vs. 可维护性的取舍。框架的意义在于为你掩盖底层的 DOM 操作,让你用更声明式的方式来描述你的目的,从而让你的代码更容易维护。没有任何框架可以比纯手动的优化 DOM 操作更快,因为框架的 DOM 操作层需要应对任何上层 API 可能产生的操作,它的实现必须是普适的。针对任何一个 benchmark,我都可以写出比任何框架更快的手动优化,但是那有什么意义呢?在构建一个实际应用的时候,你难道为每一个地方都去做手动优化吗?出于可维护性的考虑,这显然不可能。框架给你的保证是,你在不需要手动优化的情况下,我依然可以给你提供过得去的性能。

2. 对 React 的 Virtual DOM 的误解。

React 从来没有说过 “React 比原生操作 DOM 快”。React 的基本思维模式是每次有变动就整个重新渲染整个应用。如果没有 Virtual DOM,简单来想就是直接重置 innerHTML。很多人都没有意识到,在一个大型列表所有数据都变了的情况下,重置 innerHTML 其实是一个还算合理的操作... 真正的问题是在 “全部重新渲染” 的思维模式下,即使只有一行数据变了,它也需要重置整个 innerHTML,这时候显然就有大量的浪费。

我们可以比较一下 innerHTML vs. Virtual DOM 的重绘性能消耗:

  • innerHTML: render html string O(template size) + 重新创建所有 DOM 元素 O(DOM size)
  • Virtual DOM: render Virtual DOM + diff O(template size) + 必要的 DOM 更新 O(DOM change)

Virtual DOM render + diff 显然比渲染 html 字符串要慢,但是!它依然是纯 js 层面的计算,比起后面的 DOM 操作来说,依然便宜了太多。可以看到,innerHTML 的总计算量不管是 js 计算还是 DOM 操作都是和整个界面的大小相关,但 Virtual DOM 的计算量里面,只有 js 计算和界面大小相关,DOM 操作是和数据的变动量相关的。前面说了,和 DOM 操作比起来,js 计算是极其便宜的。这才是为什么要有 Virtual DOM:它保证了 1)不管你的数据变化多少,每次重绘的性能都可以接受;2) 你依然可以用类似 innerHTML 的思路去写你的应用。

3. MVVM vs. Virtual DOM

相比起 React,其他 MVVM 系框架比如 Angular, Knockout 以及 Vue、Avalon 采用的都是数据绑定:通过 Directive/Binding 对象,观察数据变化并保留对实际 DOM 元素的引用,当有数据变化时进行对应的操作。MVVM 的变化检查是数据层面的,而 React 的检查是 DOM 结构层面的。MVVM 的性能也根据变动检测的实现原理有所不同:Angular 的脏检查使得任何变动都有固定的
O(watcher count) 的代价;Knockout/Vue/Avalon 都采用了依赖收集,在 js 和 DOM 层面都是 O(change):

  • 脏检查:scope digest O(watcher count) + 必要 DOM 更新 O(DOM change)
  • 依赖收集:重新收集依赖 O(data change) + 必要 DOM 更新 O(DOM change)可以看到,Angular 最不效率的地方在于任何小变动都有的和 watcher 数量相关的性能代价。但是!当所有数据都变了的时候,Angular 其实并不吃亏。依赖收集在初始化和数据变化的时候都需要重新收集依赖,这个代价在小量更新的时候几乎可以忽略,但在数据量庞大的时候也会产生一定的消耗。

MVVM 渲染列表的时候,由于每一行都有自己的数据作用域,所以通常都是每一行有一个对应的 ViewModel 实例,或者是一个稍微轻量一些的利用原型继承的 "scope" 对象,但也有一定的代价。所以,MVVM 列表渲染的初始化几乎一定比 React 慢,因为创建 ViewModel / scope 实例比起 Virtual DOM 来说要昂贵很多。这里所有 MVVM 实现的一个共同问题就是在列表渲染的数据源变动时,尤其是当数据是全新的对象时,如何有效地复用已经创建的 ViewModel 实例和 DOM 元素。假如没有任何复用方面的优化,由于数据是 “全新” 的,MVVM 实际上需要销毁之前的所有实例,重新创建所有实例,最后再进行一次渲染!这就是为什么题目里链接的 angular/knockout 实现都相对比较慢。相比之下,React 的变动检查由于是 DOM 结构层面的,即使是全新的数据,只要最后渲染结果没变,那么就不需要做无用功。

Angular 和 Vue 都提供了列表重绘的优化机制,也就是 “提示” 框架如何有效地复用实例和 DOM 元素。比如数据库里的同一个对象,在两次前端 API 调用里面会成为不同的对象,但是它们依然有一样的 uid。这时候你就可以提示 track by uid 来让 Angular 知道,这两个对象其实是同一份数据。那么原来这份数据对应的实例和 DOM 元素都可以复用,只需要更新变动了的部分。或者,你也可以直接 track by $index 来进行 “原地复用”:直接根据在数组里的位置进行复用。在题目给出的例子里,如果 angular 实现加上 track by $index 的话,后续重绘是不会比 React 慢多少的。甚至在 dbmonster 测试中,Angular 和 Vue 用了 track by $index 以后都比 React 快: dbmon (注意 Angular 默认版本无优化,优化过的在下面)

顺道说一句,React 渲染列表的时候也需要提供 key 这个特殊 prop,本质上和 track-by 是一回事。

4. 性能比较也要看场合

在比较性能的时候,要分清楚初始渲染、小量数据更新、大量数据更新这些不同的场合。Virtual DOM、脏检查 MVVM、数据收集 MVVM 在不同场合各有不同的表现和不同的优化需求。Virtual DOM 为了提升小量数据更新时的性能,也需要针对性的优化,比如 shouldComponentUpdate 或是 immutable data。

  • 初始渲染:Virtual DOM > 脏检查 >= 依赖收集
  • 小量数据更新:依赖收集 >> Virtual DOM + 优化 > 脏检查(无法优化) > Virtual DOM 无优化
  • 大量数据更新:脏检查 + 优化 >= 依赖收集 + 优化 > Virtual DOM(无法/无需优化)>> MVVM 无优化

不要天真地以为 Virtual DOM 就是快,diff 不是免费的,batching 么 MVVM 也能做,而且最终 patch 的时候还不是要用原生 API。在我看来 Virtual DOM 真正的价值从来都不是性能,而是它 1) 为函数式的 UI 编程方式打开了大门;2) 可以渲染到 DOM 以外的 backend,比如 ReactNative。

5. 总结

以上这些比较,更多的是对于框架开发研究者提供一些参考。主流的框架 + 合理的优化,足以应对绝大部分应用的性能需求。如果是对性能有极致需求的特殊情况,其实应该牺牲一些可维护性采取手动优化:比如 Atom 编辑器在文件渲染的实现上放弃了 React 而采用了自己实现的 tile-based rendering;又比如在移动端需要 DOM-pooling 的虚拟滚动,不需要考虑顺序变化,可以绕过框架的内置实现自己搞一个。

原文地址:https://www.cnblogs.com/yandongSS/p/11478902.html

时间: 2024-10-28 14:57:11

Virtual DOM 真的比操作原生 DOM 快吗?的相关文章

Vue 操作原生Dom refs

获取原生DOM 给标签或组件 添加ref属性 <div ref='alex'></div> <p ref='a'></p> <Home ref='b'></Home> this.$refs.alex // 获取原生的Dom对象 this.$refs.b // 获取的是组件的实例化对象 refs属性集合 console.log(this.$refs.input); // 获取原生DOM // 返回值 <input type=&qu

PHP原生DOM对象操作XML&#39;代码&#39;

对于操作XML类型文件,PHP内置有一套DOM对象可以进行处理.对XML的操作,从创建.添加到修改.删除都可以使用DOM对象中的函数来进行. 创建 创建一个新的XML文件,并且写入一些数据到这个XML文件中. /* * 创建xml文件 */ $info = array( array('obj' => 'power','info' => 'power is shutdown'), array('obj' => 'memcache','info' => 'memcache used t

Jquery的dom操作与原生dom的转换

本片文章包含了 jquery常见dom操作. q与原生dom对象的区别与转换 伪数组对象的知识 如有错误,烦请指正. 增 以下方法共性:可以一次添加多个内容,内容可以是DOM对象.HTML string. jQuery对象 创建元素 var obj = $('<div class="test"><p><span>Done</span></p></div>'); 两种方法可以创建元素 直接写入html 传入一个原生d

dom操作原生js巩固

原生js的dom操作巩固 前言:这玩意其实很简单,但是每次用的时候都有点含糊,故写个文章,每次忘得时候看一看 原生dom操作 1.创建dom元素:createElement(标签名) 2.删除dom元素:removeChild(标签名) 3.在什么元素后添加dom元素:元素.appendChild(标签名) 4.在什么元素前添加dom元素:元素.insertBefore(标签名) 5.替换dom元素:replace(插入的元素,被替换的元素) 6.获取父节点:parentNode 7.获取子节点

JS原生DOM操作总结

DOM的主要操作--增.删.改.查节点 (1) 查找节点 document.getElementById('div1') document.getElementsByName('uname') document.getElementsByTagName('span') document.getElementsByClassName('alert') document.querySelector('#div1') document.querySelectorAll('.alert'); (2) 操

原生DOM探究 -- NodeList v.s. HTMLCollection

涉及获取元素的主要API 在获取原生DOM元素的时候,主要涉及这几个DOM API(链接为Living Standard): Node及对应集合NodeList Element(继承Node)及对应集合HTMLCollection Document(继承Node) 注:计划取代NodeList和HTMLCollection的Elements目前并无广泛实现 基础知识 -- NodeList v.s. HTMLCollection 在不同版本的浏览器中,如果使用获取多元素的DOM方法,有的会得到N

ExtJs4学习(二):Dom文档操作

现在主流的JS框架要数ExtJs和JQuery应用的比较广泛.JQuery属于轻量级的,一般做网站应用比较常见,可见块头小的优势.ExtJs比较庞大,它除了对基本的JS语法和HTML DOM操作方式的封装之外,还提供了一套强大的UI库.在企业级B/S解决方案应用上独占优势.就单说它在原生JS的封装,DOM操作方式封装方面也足以藐视JQuery.下面我就通过对比API,体现两种框架的异曲同工之处.我们已JQuery API为主线,来看看ExtJs是否有替代的方案. 注意一点:ExtJs4.0相对上

JavaScript操作DOM与jQuyer操作DOM的对比

1.通过jQuery方法包装后的对象,是一个类数组对象.它与DOM对象完全不同,唯一相似的是它们都能操作DOM. 2.通过jQuery方法包装后的对象,是一个类数组对象.它与DOM对象完全不同,唯一相似的是它们都能操作DOM.通过jQuery处理DOM的操作,可以让开发者更专注业务逻辑的开发,而不需要我们具体知道哪个DOM节点有那些方法,也不需要关心不同浏览器的兼容性问题,我们通过jQuery提供的API进行开发,代码也会更加精短. 3.jQuery是一个类数组对象,而DOM对象就是一个单独的D

dom节点的操作

dom节点的操作 -- jQuery 内部插入 1.(结尾)append 方法 . appendto方法(为了方便链式操作) (开头)prepend方法 $('#div1').append($('#div2'));     //将div2 插入到 div1 里面的末尾 ? $('#div1').appendto($('#div2'));     //将div1 插入到 div2 里面的末尾 ? $('#div1').prepend($('#div2'));     //将div2 插入到 div