标签：cloud 生成 视图 函数 png line strong 步骤 http
框架并没有提高web的性能，只是让开发者更加专注的完成业务逻辑，而不用过渡的考虑性能上的优化。如果以性能来比的话，框架是绝对比不过优化后的原生代码的。
二、什么是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的思考远没有结束，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的理解有误呢？
2、再次审视Virtual DOM
框架存在的意义是什么？是提高性能？提高开发效率？亦或是其他用途，每个人对框架的理解不同，答案也不尽相同。但是不得不承认，存在框架的情况下，项目的可维护性有了极大的提高，而对于其他方面就要做出牺牲，比如性能。在上面的性能测试中，其实完全走入了一个误区，在测试中我们用到的原生的操作其实是“人为”地对操作进行优化之后的结果，而如果抛开人为优化的前提，最终的结果可能就不是这样了。**Virtual DOM的优势不在于单次的操作，而是在大量、频繁的数据更新下，能够对视图进行合理、高效的更新。**这一点是原生操作远远无法替代的。
到此为止，再次审视Virtual DOM，可以简单得出如下结论：
https://github.com/y8n/blog/issues/5
标签：cloud 生成 视图 函数 png line strong 步骤 http
原文地址：https://www.cnblogs.com/feng9exe/p/11733854.html
