虚拟DOM和真实DOM

虚拟DOM原理

使用js对象，通过各个不同key，完整表示一个正式DOM。

tag: 当前节点的标签名
data: 当前节点的数据对象
children: 数组类型，包含了当前节点的子节点
text: 当前节点的文本，一般文本节点或注释节点会有该属性
elm: 当前虚拟节点对应的真实的dom节点
ns: 节点的namespace
context: 编译作用域
functionalContext: 函数化组件的作用域
key: 节点的key属性，用于作为节点的标识，有利于patch的优化
componentOptions: 创建组件实例时会用到的选项信息
child: 当前节点对应的组件实例
parent: 组件的占位节点
raw: raw html
isStatic: 静态节点的标识
isRootInsert: 是否作为根节点插入，被<transition>包裹的节点，该属性的值为false
isComment: 当前节点是否是注释节点
isCloned: 当前节点是否为克隆节点
isOnce: 当前节点是否有v-once指令 VNode是虚拟DOM的基类，通过实例化这个类形成。

区别

正式dom和虚拟dom都是对象，但是虚拟DOM使用少量对象表示了真实DOM，且真实DOM对象属性较多，操作时候消耗内存。直接操作DOM重新渲染，但是虚拟DOM会有旧dom和操作后的dom，然后对两个dom进行比较，局部更新。较少内存消耗。
正式dom可以在浏览器获取，虚拟dom不能获取
正式dom频繁回流和重绘，效率更低

虚拟DOM真的比真实操作DOM快吗？

这是一个性能 vs. 可维护性的取舍。框架的意义在于为你掩盖底层的 DOM 操作，让你用更声明式的方式来描述你的目的，从而让你的代码更容易维护。没有任何框架可以比纯手动的优化 DOM 操作更快，因为框架的 DOM 操作层需要应对任何上层 API 可能产生的操作，它的实现必须是普适的。针对任何一个 benchmark，我都可以写出比任何框架更快的手动优化，但是那有什么意义呢？在构建一个实际应用的时候，你难道为每一个地方都去做手动优化吗？出于可维护性的考虑，这显然不可能。框架给你的保证是，你在不需要手动优化的情况下，我依然可以给你提供过得去的性能 参考原文链接：blog.csdn.net/saucxs/arti… DOM操作和js计算比起来，js计算相对更好，真实DOM，假如有一个很多的长列表，有一个数据改变就要全部重新渲染，相对虚拟dom来说只是js计算和修改数据的DOM操作，虚拟DOM只是为了使用js计算替代大部分的DOM操作，让你可以接受，不是绝对的比真实DOM更快