简述浏览器渲染机制
互联网不断高速发展的今天，使用浏览器浏览页面几乎已经变成日常必做事项了，那么你了解浏览器是怎么把一堆枯燥的代码变成一个艺术品般的网页展现在你眼前的吗？
页面渲染就是浏览器将HTML变成人眼看到的图像的全过程。
浏览器工作大流程
首先我们来看一张图
浏览器渲染流程
从图中我们可以得到几个结论：
- 浏览器会解析三个东西：
- 一个是HTML/SVG/XHTML等类似的东西，经过解析后生成一个DOM Tree
- CSS，解析CSS会产生CSS规则树。
- Javascript，脚本，主要是通过DOM API和CSSOM API来操作DOM Tree和CSS Rule Tree.
2.解析完成后，浏览器引擎会通过DOM Tree 和 CSS Rule Tree 来构造 Rendering Tree。注意：
- Rendering Tree 渲染树并不等同于DOM树，因为一些像Header或display:none的东西就没必要放在渲染树中了。
- CSS 的 Rule Tree主要是为了完成匹配并把CSS Rule附加上Rendering Tree上的每个Element。
- 之后计算每个Frame（也就是每个Element）的位置，这又叫layout和reflow过程。
- 最后通过调用操作系统Native GUI的API绘制。
渲染
渲染的流程基本上如下（黄色的四个步骤）：
- 计算CSS样式
- 构建Render Tree
- Layout（reflow） – 定位坐标和大小，是否换行，各种position, overflow, z-index属性 ……
- 正式开画（paint）
渲染流程
注意：上图流程中有很多连接线，这表示了Javascript动态修改了DOM属性或是CSS属性导致重新Layout（reflow），有些改变则不会造成影响，就是那些指到天上的箭头（比如修改后的CSS rule没有被匹配到）
这里就引申出现了今天我们另外两个重要的概念——reflow(回流)、repaint（重绘）
Reflow与Repaint的概念解释
Reflow
对于DOM结构中的各个元素都有自己的盒子（模型），这些都需要浏览器根据各种样式（浏览器的、开发人员定义的等）来计算并根据计算结果将元素放到它该出现的位置，这个过程称之为reflow。
DOM Tree 里的每个结点都会有 reflow 方法，一个结点的 reflow 很有可能导致子结点，甚至父点以及同级结点的 reflow。在一些高性能的电脑上也许还没什么，但是如果 reflow 发生在手机上，那么这个过程是非常痛苦和耗电的。
所以，下面这些动作有很大可能会是成本比较高的。
- 当你增加、删除、修改 DOM 结点时，会导致 Reflow 或 Repaint。
- 当你移动 DOM 的位置，或是搞个动画的时候。
- 当你修改 CSS 样式的时候。
- 当你 Resize 窗口的时候（移动端没有这个问题），或是滚动的时候。
- 当你修改网页的默认字体时。
注：display:none 会触发 reflow，而 visibility:hidden 只会触发 repaint，因为没有发现位置变化。
Repaint
当各种盒子的位置、大小以及其他属性，例如颜色、字体大小等都确定下来后，浏览器于是便把这些元素都按照各自的特性绘制了一遍，于是页面的内容出现了，这个过程称之为repaint。
由上可见这两个东东对浏览器渲染页面是很重要的啊，都是会影响性能的，因此我们需要尽量避免上述常见的会引起repaint和reflow的一些操作，以提高渲染速度。
如何优化？
Reflow是不可避免的，只能将Reflow对性能的影响减到最小,给出下面几条建议：
- 不要一条一条地修改 DOM 的样式。与其这样，还不如预先定义好 css 的 class，然后修改 DOM 的 className
- 把 DOM 离线后修改。
- 不要把 DOM 节点的属性值放在一个循环里当成循环里的变量。不然这会导致大量地读写这个结点的属性。
- 尽可能的修改层级比较低的 DOM节点。当然，改变层级比较底的 DOM节点有可能会造成大面积的 reflow，但是也可能影响范围很小。
- 为动画的 HTML 元件使用 fixed 或 absoult 的 position，那么修改他们的 CSS 是会大大减小 reflow 。
- 尽可量少使用table布局，牵一发而动全身。
