虚拟DOM

1、什么是虚拟DOM？

render执行的结果获得的并非真正的DOM节点，结果仅仅是轻量级的JavaScript对象，咱们称之为virtual DOM。

虚拟DOM是React的一大亮点，具备batching(批处理)和高效的Diff算法。这让咱们能够无需担忧性能问题而”毫无顾忌”的随时“刷新”整个页面，由虚拟 DOM来确保只对界面上真正变化的部分进行实际的DOM操做。

2、虚拟DOM VS 直接操做原生DOM？

若是没有 Virtual DOM，简单来讲就是直接重置 innerHTML。这样操做，在一个大型列表全部数据都变了的状况下，还算是合理，可是，当只有一行数据发生变化时，它也须要重置整个 innerHTML，这时候显然就形成了大量浪费。

比较innerHTML 和Virtual DOM 的重绘过程以下：

innerHTML: render html string + 从新建立全部 DOM 元素

Virtual DOM: render Virtual DOM + diff + 必要的 DOM 更新

​ 和 DOM 操做比起来，js 计算是很是便宜的。Virtual DOM render + diff 显然比渲染 html 字符串要慢，可是，它依然是纯 js 层面的计算，比起后面的 DOM 操做来讲，依然便宜了太多。固然，曾有人作过验证说React的性能不如直接操做真实DOM，代码以下：

function Raw() {
    var data = _buildData(),
        html = "";
    ...
    for(var i=0; i<data.length; i++) {
        var render = template;
        render = render.replace("{{className}}", "");
        render = render.replace("{{label}}", data[i].label);
        html += render;
    }
    ...
    container.innerHTML = html;
    ...
}

 

​ 该测试用例中虽然构造了一个包含1000个Tag的String，并把它添加到DOM树中，可是只作了一次DOM操做。然而，在实际开发过程当中，这1000个元素更新可能分布在20个逻辑块中，每一个逻辑块中包含50个元素，当页面须要更新时，都会引发DOM树的更新，上述代码就近似变成了以下格式：

function Raw() {
    var data = _buildData(), 
        html = ""; 
    ... 
    for(var i=0; i<data.length; i++) { 
        var render = template; 
        render = render.replace("{{className}}", ""); 
        render = render.replace("{{label}}", data[i].label); 
        html += render; 
        if(!(i % 50)) {
            container.innerHTML = html;
        }
    } 
    ... 
}

 

这样来看，React的性能就远胜于原生DOM操做了。

​ 并且，DOM 彻底不属于Javascript (也不在Javascript 引擎中存在).。Javascript 实际上是一个很是独立的引擎，DOM实际上是浏览器引出的一组让Javascript操做HTML文档的API而已。在即时编译的时代，调用DOM的开销是很大的。而Virtual DOM的执行彻底都在Javascript 引擎中，彻底不会有这个开销。

​ React.js 相对于直接操做原生DOM有很大的性能优点， 很大程度上都要归功于virtual DOM的batching 和diff。batching把全部的DOM操做搜集起来，一次性提交给真实的DOM。diff算法时间复杂度也从标准的的Diff算法的O(n^3)降到了O(n)。这里留到下一次博客单独讲。

3、虚拟DOM VS MVVM？

相比起 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 + 必要 DOM 更新
• 依赖收集：从新收集依赖 + 必要 DOM 更新

​ 能够看到，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 默认版本无优化，优化过的在下面）

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

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

（该段落借鉴了知乎的相关回答）

4、对React虚拟DOM的误解？

​ React 历来没有说过 “React 比原生操做 DOM 快”。React给咱们的保证是，在不须要手动优化的状况下，它依然能够给咱们提供过得去的性能。

​ React掩盖了底层的 DOM 操做，能够用更声明式的方式来描述咱们目的，从而让代码更容易维护。下面仍是借鉴了知乎上的回答：没有任何框架能够比纯手动的优化 DOM 操做更快，由于框架的 DOM 操做层须要应对任何上层 API 可能产生的操做，它的实现必须是普适的。针对任何一个 benchmark，我均可以写出比任何框架更快的手动优化，可是那有什么意义呢？在构建一个实际应用的时候，你难道为每个地方都去作手动优化吗？出于可维护性的考虑，这显然不可能。

1. 为何虚拟DOM更胜一筹

注意：虚拟DOM只是实现MVVM的一种方案，或者说是视图更新的一种策略。没有虚拟DOM比MVVM更好一说。

咱们回顾传统MVC框架,如backbone,它是将某个模板编译成模板函数,须要更新时,是本身手动将数据总体传入模板函数,获得一个字符串,使用innerHTML刷新某个容器!注意,这里其实能够优化,但因为是手动,是体力活,都是使用很粗放型的innerhTML了事(使用jQuery的html方法性能会更差,不过好处是它处理了IE下的innerHTML BUG及全平台的没法执行内部的script标签的BUG) 因为总体替换,一会儿销毁这么多元素(有时还绑着事件,可能致使GC出问题),又要插入这么多元素,再从新绑定事件(这个可使用事件代理缓解) 所以性能很是差

方案二是使用脏检测的angular,要求对全部做用域对象进行diff,使用通知刷新函数进行视图更新. 页面上的指令越多,须要比较的数据越多(有循环, 须要乘以数组长度或对象键值对个数),可能用于循环时间过长致使页面假死

方案三使用avalon这样的密封舱方案(船底是分红一个个独立的区域,局部受损也不会致使沉船).avalon使用Object.defineProperty及VBS实现属性监控, 这样用户修数据时,就能当即进入。事件总线系统(观察者模式), 而后取得与这属性相关联的订阅者数组(换言之的密封舱,不像ng那样,一个$scope对象就一个$$watcher数组).

而通常状况下,VM中的某个属性在视图中也只会用到几个位置,那么几个位置,就会生成几个绑定对象,都放在相应的订阅者数组中,每一个订阅者数组都不会太长.所以同步视图,不会所以遍历的数组过长而假死.所以ng在处理2000个指令的页面时就易出问题 (一个grid,每每有两三重循环,很容就飙到5000个指令),而avalon的密封舱方案是能撑到12000个指令。但avalon须要保存大量的绑定对象,而且将普通属性转换访问器属性,也须要占用内存,这是一个以空间换时间的方案.

不过avalon在处理ms-repeat, ms-with, ms-each这个循环绑定时,也实现得不太好,这其中要生成大量的代理VM,整个页面都在生成销毁VM中拖慢了(即使使用各类池子进行循环再用).

方案四,像knockout那样, 使用时让用户痛苦一些,使用可同步视图的东西用函数(wrapper)包裹起来,刷新视图,就只须要从新调用这个wrapper.如今全部新的MVVM都是从ko那里学到依赖收集.这个wraper会通知其依赖的wrapper,经过极其痛苦晦涩的方式进入事件总线, 执行视图刷新函数. knockout是使用闭包用到极致的库,显然这样作性能也不好.

最后react, 首先使用编译手段(jsx的虚拟DOM转换), 将这部分消耗能提早释放出去,不过将字符串(jsx模板)转换为一个个JS对象,也占不了多少内存. 而后是数据发生变更时,因为数据变更都是须要用setState方法,所以兼容性很好,少了Object.defineProperty或wrapper的消耗,而后对应数据经过render转换成字符串,字符串再转换虚拟DOM树。先后虚拟DOM进行比较, 更新视图.

react是面向组件设计, 一个组件就是一个密封舱, 不多会对全部虚拟DOM进行比较, 因为强制使用单向流动, 减小每次变更须要的diff. 没有绑定对象与wrapper的内存占用高的问题.

react的流行，只是ng太难用了，当ng或其余MVVM改用虚拟DOM进行视图更新，这优点就不须要！

react的问题很明显，库很是大，它基本上离开了jsx换转器就活不成。 这么大的库， 换言之你们能对它改动的地方就越多，每升一个版本就数千改动。做为架构师的咱们，须要对其源码进行很是熟悉的了解，要不出了问题没法本身处理，每次等外国人回复就迟了。

react的复杂度，很易触发你们对它的重构，即使占有方有向前兼容的愿望，但能抵得几回诱惑呢，所以通过几个版本会面目全非。若是你坚持不变，那么其余人就会另起山头， 开源的东西很易出现一个更优点的仿品！react的实现很糟糕的，强在设计！

虚拟DOM的难点是如何将一个字符串变成一个模板函数，而后再转换为虚拟DOM。 目前没有简单的HTML parser实现，stackoverflow上说不能使用几行正则就能拆分HTML！ 所以这个高门槛，致使react的代替方案难产！github上有许多自称使用了虚拟DOM的框架，不是假的就是超垃圾的实现！更况且react支持自定义标签，所以不单是解析HTML的问题了，须要对自定义标签进行更多的处理！

--摘自2篇文章