Virtual DOM本来是做什么用的

对于Virtual DOM这个概念应该是人尽皆知才对，那就是为了减轻浏览器的DOM操作，带来性能的提升，然后它带来了一个良好的副作用，那就是实现了跨平台的渲染。

跨平台本来只是它的副作用，但是很多人却把它理解成了VDom的设计目的，这种本末倒置的认知使很多人对VDom的优化作用都不知道了，在这里介绍下VDom的发展历史。

21世纪初脸书的是失败尝试

在2000年的时候iPhone已经成为了手机的代名词，以前在桌面平台风光无限的互联网公司也开始意识到了移动时代的来临，其中特别是以社交发家的脸书更是积极的部署移动互联网平台。

那时候的互联网已经开始有了统一的迹象，使用WebApp代替桌面软件已经慢慢的成为流行趋势，自然而然的这些互联网大佬们也想把桌面的哪一套照搬到移动端，多亏了iPhone拥有当时最优秀的移动端浏览器使得这个想法大概还是能够实现的。于是脸书就屁颠屁颠的开始了开发针对移动端H5 WebApp应用了。

尽管iPhone在具有当时最优秀的移动浏览器，而且也是率先支持H5的移动浏览器，但是碍于当时的硬件配置和赢弱的手机操作系统，使得脸书在当时开发H5应用的时候遇到很大的阻力，最为关键的阻力就是作为一家社交公司，大量的用户留言是必须要克服的门槛，在桌面端这一切都好解决，桌面电脑当时已经出现了性能过剩的现象，对于繁多的数据处理压根不是问题。但是到了手机端就不同了，大量留言的展示是极耗内存的事情，再加上当时手机硬件不够，导致整个H5应用用起来傻傻的，与iPhone那原生的应用判若两人。

这里也要提一句，在当时乔布斯是没有开放SDK给开发者自己开发原生应用的，唯一第三方能够开发的就是H5应用，是不是很神奇，乔老爷才是第一个提出WebApp的。后来也是苹果意识到当时的iPhone性能不足以支撑起来H5应用的使用，才慢慢的开放了SDK给第三方开发者。

也就是说脸书起了个早，却没落得个好，最后还是像原生应用妥协了，毕竟赚钱才是王道嘛，这没什么好丢脸的，后来很长一段时间扎克伯格还一直鼓吹原生应用，贬低H5应用，乔老爷也乐得看到这个结果，用原生SDK开发的话那么就是苹果独占应用，那有何乐而不为呢？

不过就在脸书宣布放弃H5技术改用原生SDK之后的两周左右的时间，就有两个技术爱好者模仿了脸书的H5应用，并且演示的效果出乎预料的好，他们对H5应用做了优化，使用类似于苹果UITable的渲染技术，只渲染用户看到的那部分数据，没看到的就不渲染出来，列表的滚动性能几乎接近原生应用，这就让人觉得脸书技术不行，转行开发原生应用是因为没有优秀的人才。

React的异军突起

虽然手机端上暂时不开发H5应用了，但是桌面端还是那时的主流，而且随着用户量的不断增加桌面端也逐渐出现了性能瓶颈，为此脸书在优化后段的同时，也在尝试新的方法优化前端。很多现在流行的前端开发思想就是从那时候出现的。

数据单向传递，虚拟Dom这些新技术的新想法的出现让脸书在桌面端上获得了飞跃的提升。其中虚拟DOM技术改变了整个前端开发思路。

当时最红的恐怕要数Angular，它的开箱即用理念极大的方便了前端开发者，然而Angular只是提供了一个MVVM的框架工具，对于底层DOM处理还是老一套，数据传进来就更新DOM，对于小数据量的应用问题不大，但是对于海量数据处理来说还是会卡。

也有Angular的工作人员将React引入了Angular，没想到效果出奇的好，借助于Angular的MVVM特性和React的虚拟DOM在处理大数据的时候获得了飞跃性的提高。这之后Angualr社区就去开发Angular2了，这之后就没有然后了，谁还会去理会一个推到重来的项目。

但是React却因此活了起来，它的性能是有目共睹的，即使你的代码写的很烂，它也能把你救会一半，就是这么牛。有了React脸书又可以杀回移动端了，当初的耻辱要你们双倍奉还。此后哪个框架说自己没有VDom恐怕都难在江湖立足了。

为什么Virtual DOM有用

浏览器中对性能影响较大的多半就是列表类型的应用，传统的做法无论你是显示一条数据还是一万条数据都是直接加载到DOM中，如果是一次全部插入到DOM中还好，但要是一条一条插入的话那浏览器表现出来的情况就是我已经卡死了，因为DOM操作是十分耗时和耗内存的。

为此要解决这个问题有两个办法，第一个就是使用Virtual Scroll技术，这个技术用的最多就是苹果的框架了，什么UITable，UIList什么的都是使用这个技术来实现的，原理就是侦测当前的视窗大小，将用户能够看到的数据读取出来并渲染，顺便多读取后面几条和前面几条数据方便滚动的时候能够平滑显示。这个方法其实不错，能够节省内存，性能也很好，看看初代iPhone就知道这个方法是很棒的了。

Virtual Scroll虽然好，但是有点浪费浏览器本身的功能了，毕竟苹果的框架本身就要负责渲染的事情，而我们一个写前端的还要负责渲染显然多此一举了，那还有什么办法呢？很简单，那就是把多次的DOM更新合并成一次更新就可以了，这就是Virtual DOM思想了，在内存中维护一个虚拟DOM树，把需要更新你的部分提取出来更新到真实的DOM树当中就好了。其实还有一个更简单的办法，你可以用字符串了表示DOM，然后直接用innerHTML替换也是可以的，但是字符串一旦数量多了性能依旧会大幅度下降，能够直接操作内存是最好的选择，而且使用innerHTML方法的话浏览器还是要执行一次解析工作，而直接DOM操作是不需要这个接续步骤的，衡量之后当然是用Virtual DOM方法更合算了。

Virtual DOM的副作用

说到副作用一般人想到都是坏事，Virtual DOM的副作用恰恰相反，他却带来一个好的副作用，那就是跨平台渲染。因为所有的渲染数据实际上都是保存在了内存中，react自己维护了一个渲染树，所有只要对这个渲染树进行适当的适配就能把它移植到任何一个渲染框架上去了。