北京中科刘云涛 http://m.jpm.cn/article-89116-1.html采用尤大大的回答：1.原生DOM操作vs.通过框架封装操作这是一个性能vs.可维护性的取舍。框架的意义在于为你掩盖底层的DOM操作，让你用更声明式的方式来描述你的目的，从而让你的代码更容易维护。没有任何框架可以比纯手动的优化DOM操作更快，因为框架的DOM操作层需要应对任何上层API可能产生的操作，它的实现必须是普适的。针对任何一个benchmark，我都可以写出比任何框架更快的手动优化，但是那有什么意义呢？在构建一个实际应用的时候，你难道为每一个地方都去做手动优化吗？出于可维护性的考虑，这显然不可能。框架给你的保证是，你在不需要手动优化的情况下，我依然可以给你提供过得去的性能。2.对React的VirtualDOM的误解React从来没有说过“React比原生操作DOM快”。React的基本思维模式是每次有变动就整个重新渲染整个应用。如果没有VirtualDOM，简单来想就是直接重置innerHTML。很多人都没有意识到，在一个大型列表所有数据都变了的情况下，重置innerHTML其实是一个还算合理的操作...真正的问题是在“全部重新渲染”的思维模式下，即使只有一行数据变了，它也需要重置整个innerHTML，这时候显然就有大量的浪费。我们可以比较一下innerHTMLvs.VirtualDOM的重绘性能消耗：innerHTML:renderhtmlstringO(templatesize)+重新创建所有DOM元素O(DOMsize) VirtualDOM:renderVirtualDOM+diffO(templatesize)+必要的DOM更新O(DOMchange)VirtualDOMrender+diff显然比渲染html字符串要慢，但是！它依然是纯js层面的计算，比起后面的DOM操作来说，依然便宜了太多。可以看到，innerHTML的总计算量不管是js计算还是DOM操作都是和整个界面的大小相关，但VirtualDOM的计算量里面，只有js计算和界面大小相关，DOM操作是和数据的变动量相关的。前面说了，和DOM操作比起来，js计算是极其便宜的。这才是为什么要有VirtualDOM：它保证了1）不管你的数据变化多少，每次重绘的性能都可以接受；2)你依然可以用类似innerHTML的思路去写你的应用。.MVVMvs.VirtualDOM相比起React，其他MVVM系框架比如Angular,Knockout以及Vue、Avalon采用的都是数据绑定：通过Directive/Binding对象，观察数据变化并保留对实际DOM元素的引用，当有数据变化时进行对应的操作。MVVM的变化检查是数据层面的，而React的检查是DOM结构层面的。MVVM的性能也根据变动检测的实现原理有所不同：Angular的脏检查使得任何变动都有固定的O(watchercount)的代价；Knockout/Vue/Avalon都采用了依赖收集，在js和DOM层面都是O(change)：脏检查：scopedigestO(watchercount)+必要DOM更新O(DOMchange) 依赖收集：重新收集依赖O(datachange)+必要DOM更新O(DOMchange)可以看到，Angular最不效率的地方在于任何小变动都有的和watcher数量相关的性能代价。但是！当所有数据都变了的时候，Angular其实并不吃亏。依赖收集在初始化和数据变化的时候都需要重新收集依赖，这个代价在小量更新的时候几乎可以忽略，但在数据量庞大的时候也会产生一定的消耗。MVVM渲染列表的时候，由于每一行都有自己的数据作用域，所以通常都是每一行有一个对应的ViewModel实例，或者是一个稍微轻量一些的利用原型继承的"scope"对象，但也有一定的代价。所以，MVVM列表渲染的初始化几乎一定比React慢，因为创建ViewModel/scope实例比起VirtualDOM来说要昂贵很多。这里所有MVVM实现的一个共同问题就是在列表渲染的数据源变动时，尤其是当数据是全新的对象时，如何有效地复用已经创建的ViewModel实例和DOM元素。假如没有任何复用方面的优化，由于数据是“全新”的，MVVM实际上需要销毁之前的所有实例，重新创建所有实例，最后再进行一次渲染！这就是为什么题目里链接的angular/knockout实现都相对比较慢。相比之下，React的变动检查由于是DOM结构层面的，即使是全新的数据，只要最后渲染结果没变，那么就不需要做无用功。Angular和Vue都提供了列表重绘的优化机制，也就是“提示”框架如何有效地复用实例和DOM元素。比如数据库里的同一个对象，在两次前端API调用里面会成为不同的对象，但是它们依然有一样的uid。这时候你就可以提示trackbyuid来让Angular知道，这两个对象其实是同一份数据。那么原来这份数据对应的实例和DOM元素都可以复用，只需要更新变动了的部分。或者，你也可以直接trackbyindex来进行“原地复用”：直接根据在数组里的位置进行复用。在题目给出的例子里，如果angular实现加上trackbyindex的话，后续重绘是不会比React慢多少的。甚至在dbmonster测试中，Angular和Vue用了trackbyindex以后都比React快:dbmon(注意Angular默认版本无优化，优化过的在下面）顺道说一句，React渲染列表的时候也需要提供key这个特殊prop，本质上和track-by是一回事。4.性能比较也要看场合在比较性能的时候，要分清楚初始渲染、小量数据更新、大量数据更新这些不同的场合。VirtualDOM、脏检查MVVM、数据收集MVVM在不同场合各有不同的表现和不同的优化需求。VirtualDOM为了提升小量数据更新时的性能，也需要针对性的优化，比如shouldComponentUpdate或是immutabledata。初始渲染：VirtualDOM脏检查=依赖收集 小量数据更新：依赖收集VirtualDOM+优化脏检查（无法优化）VirtualDOM无优化 大量数据更新：脏检查+优化=依赖收集+优化VirtualDOM（无法/无需优化）MVVM无优化不要天真地以为VirtualDOM就是快，diff不是免费的，batching么MVVM也能做，而且最终patch的时候还不是要用原生API。在我看来VirtualDOM真正的价值从来都不是性能，而是它1)为函数式的UI编程方式打开了大门；2)可以渲染到DOM以外的backend，比如ReactNative。5.总结以上这些比较，更多的是对于框架开发研究者提供一些参考。主流的框架+合理的优化，足以应对绝大部分应用的性能需求。如果是对性能有极致需求的特殊情况，其实应该牺牲一些可维护性采取手动优化：比如Atom编辑器在文件渲染的实现上放弃了React而采用了自己实现的tile-basedrendering；又比如在移动端需要DOM-pooling的虚拟滚动，不需要考虑顺序变化，可以绕过框架的内置实现自己搞一个。附上尤大的回答链接：
转载请注明：http://www.aierlanlan.com/rzdk/8708.html
