- 浏览器会解析三个东西：
- 一个是HTML/SVG/XHTML，事实上，Webkit有三个C++的类对应这三类文档。解析这三种文件会产生一个DOM Tree。
- CSS，解析CSS会产生CSS规则树。
- Javascript，脚本，主要是通过DOM API和CSSOM API来操作DOM Tree和CSS Rule Tree.
定律一：资源是否下载依赖 JS 执行结果：在当前 JS 加载和执行完成前，阻塞后续资源下载
定律二：JS 执行依赖 CSS 最新渲染：JS 代码在执行前，浏览器必须保证在此 JS 之前的所有 css（无论外链还是内嵌）都已下载和解析完成
定律三：现代浏览器存在 prefetch 优化：现代浏览器在 UI update 线程之外，还会开启另一个线程，对后续 JS 和 CSS 提前下载（注意，仅提前下载，并不执行）
- 解析完成后，浏览器引擎会通过DOM Tree 和 CSS Rule Tree 来构造 Rendering Tree。注意：
- Rendering Tree 渲染树并不等同于DOM树，因为一些像Header或display:none的东西就没必要放在渲染树中了。
- CSS 的 Rule Tree主要是为了完成匹配并把CSS Rule附加上Rendering Tree上的每个Element。也就是DOM结点。为了能加快解析，选择器应尽量用id和class，避免过渡层叠
- 然后，计算每个Element 的位置，这又叫layout和reflow过程。
- 最后通过调用操作系统Native GUI的API绘制。
其中渲染的流程基本上如下：
1. 计算CSS样式
2. 构建Render Tree (将CSS样式attach到DOM节点)
3. Layout – 定位坐标和大小，是否换行，各种position, overflow, z-index属性 ……
4. 正式开画
这里涉及到重绘repaint和回流reflow（layout）的概念，我们都知道改变display属性会导致reflow和repaint，而改变visibility的属性只会导致repaint，如果某个元素的几何尺寸没变，而只是改变了背景色那么也只会导致repaint，如果元素的几何尺寸变了，那么就需要重新验证和计算render tree，是部分还是全部发生变化，因为HTML使用的是流式布局，所以如果某元件的几何尺寸发生了变化，需要重新布局。Reflow的成本比Repaint的成本高得多的多，所以，下面这些动作有很大可能会是成本比较高的。
- 当你增加、删除、修改DOM结点时，会导致Reflow或Repaint
- 当你移动DOM的位置，或是搞个动画的时候。
- 当你修改CSS样式的时候。
- 当你Resize窗口的时候（移动端没有这个问题），或是滚动的时候。
- 当你修改网页的默认字体时。
var bstyle = document.body.style; // cache
bstyle.padding = "20px"; // reflow, repaint
bstyle.border = "10px solid red"; // 再一次的 reflow 和 repaint
bstyle.color = "blue"; // repaint
bstyle.backgroundColor = "#fad"; // repaint
bstyle.fontSize = "2em"; // reflow, repaint
// new DOM element - reflow, repaint
document.body.appendChild(document.createTextNode('dude!'));一般来说，浏览器会把这样的操作积攒一批，然后做一次reflow，这又叫异步reflow或增量异步reflow。但是有些情况浏览器是不会这么做的，比如：resize窗口，改变了页面默认的字体，等。对于这些操作，浏览器会马上进行reflow。
减少repaint和reflow的方法
1. 不要一条一条地修改DOM的样式。与其这样，还不如预先定义好css的class，然后修改DOM的className。
2. 把DOM离线后修改。如：
- 使用documentFragment 对象在内存里操作DOM
- 先把DOM给display:none(有一次reflow)，然后你想怎么改就怎么改。比如修改100次，然后再把他显示出来。
- clone一个DOM结点到内存里，然后想怎么改就怎么改，改完后，和在线的那个的交换一下。
3. 不要把DOM结点的属性值放在一个循环里当成循环里的变量。不然这会导致大量地读写这个结点的属性。
4. 尽可能的修改层级比较低的DOM。当然，改变层级比较低的DOM有可能会造成大面积的reflow，但是也可能影响范围很小。
5. 为动画的HTML元件使用fixed或absolute的position，那么修改他们的CSS是不会reflow的。
6. 千万不要使用table布局。因为可能很小的一个小改动会造成整个table的重新布局。
DOM 操作 真正的问题在于每次操作都会触发布局的改变、DOM树的修改和渲染。所以，当你一个接一个地去修改30个节点的时候，就会引起30次（潜在的）布局重算，30次（潜在的）重绘，等等。
Virtual DOM 实际上没有使用什么全新的技术，仅仅是把 “ 双缓冲（double buffering）” 技术应用到了DOM上面。 这样一来，当你在这个单独的虚拟的DOM树上也一个接一个地修改30个节点的时候，它不会每次都去触发重绘，所以修改节点的开销就变小了。 之后，一旦你要把这些改动传递给真实DOM，之前所有的改动就会整合成一次DOM操作。这一次DOM操作引起的布局计算和重绘可能会更大，但是相比而言，整合起来的改动只做一次，减少了（多次）计算。
不过，实际上不借助Virtual DOM也可以做到这一点。你可以自己手动地整合所有的DOM操作到一个DOM 碎片（DOM fragment） 里，然后再传递给DOM树。
既然如此，我们再来看看Virtual DOM到底解决了什么问题。 首先，它把管理DOM碎片这件事情自动化、抽象化了，使得你无需再去手动处理。另外，当你要手动去做这件事情的时候，你还得记得哪些部分变化了，哪些部分没变，毕竟之后重绘时，DOM树上的大量细节你都不需要重新刷新。这时候Virtual DOM的自动化对你来说就非常有用了，如果它的实现是正确的，那么它就会知道到底哪些地方应该需要刷新，哪些地方不要。
DocumentFragment 节点不属于文档树，继承的 parentNode 属性总是 null。
不过它有一种特殊的行为，该行为使得它非常有用，即当请求把一个 DocumentFragment 节点插入文档树时，插入的不是 DocumentFragment 自身，而是它的所有子孙节点。这使得 DocumentFragment 成了有用的占位符，暂时存放那些一次插入文档的节点。它还有利于实现文档的剪切、复制和粘贴操作, 同时我们了解到当需要对页面DOM进行操作的时候必然会导致多次 重绘、回流（什么是重绘，回流？）。这样会加大页面的负担。影响页面性能。因此我们可以创建这样一个临时占位符进行操作
以下是DEMO:
// Create the fragment
var fragment = document.createDocumentFragment();
//add DOM to fragment
for(var i = 0; i < 10; i++) {
var spanNode = document.createElement("span");
spanNode.innerHTML = "number:" + i;
fragment.appendChild(spanNode);
}
//add this DOM to body
document.body.appendChild(fragment);
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
