浏览器渲染页面流程
浏览器内核拿到内容后，渲染步骤大致可以分为以下几步：
-
解析HTML，构建DOM树
-
解析CSS，生成CSS规则树
-
合并DOM树和CSS规则，生成render树
-
布局render树（Layout/reflow），负责各元素尺寸、位置的计算
-
绘制render树（paint），绘制页面像素信息
-
浏览器会将各层的信息发送给GPU，GPU会将各层合成（composite），显示在屏幕上
如下图：
browser_rending.png
HTML解析，构建DOM
整个渲染步骤中，HTML解析是第一步。
简单的理解，这一步的流程是这样的：
浏览器解析HTML，构建DOM Tree
解析HTML到构建出DOM当然过程可以简述如下：
Bytes → characters → tokens → nodes → DOM
譬如假设有这样一个HTML页面：（以下部分的内容出自参考来源，修改了下格式）
<html>
<head>
<meta name="viewport" content="width=device-width,initial-scale=1">
<link href="style.css" rel="stylesheet">
<title>Critical Path</title>
</head>
<body>
<p>Hello <span>web performance</span> students!</p>
<div><img src="awesome-photo.jpg"></div>
</body>
</html>
浏览器的处理如下：
browser_parse_html.png
列举其中的一些重点过程：
-
Conversion转换：浏览器将获得的HTML内容（Bytes）基于他的编码转换为单个字符
-
Tokenizing分词：浏览器按照HTML规范标准将这些字符转换为不同的标记token。每个token都有自己独特的含义以及规则集
-
Lexing词法分析：分词的结果是得到一堆的token，此时把他们转换为对象，这些对象分别定义他们的属性和规则
-
DOM构建：因为HTML标记定义的就是不同标签之间的关系，这个关系就像是一个树形结构一样
例如：body对象的父节点就是HTML对象，然后段略p对象的父节点就是body对象
最后的DOM树如下：
browser_parse_dom.png
生成CSS规则
同理，CSS规则树的生成也是类似。简述为：
Bytes → characters → tokens → nodes → CSSOM
譬如style.css内容如下：
body { font-size: 16px }
p { font-weight: bold }
span { color: red }
p span { display: none }
img { float: right }
那么最终的CSSOM树就是：
browser_parse_cssom.png
构建渲染树
当DOM树和CSSOM都有了后，就要开始构建渲染树了
一般来说，渲染树和DOM树相对应的，但不是严格意义上的一一对应
因为有一些不可见的DOM元素不会插入到渲染树中，如head这种不可见的标签或者display: none等
整体来说可以看图：
browser_parse_rendertree.png
渲染
有了render树，接下来就是开始渲染，基本流程如下：
browser_rendingprocess.jpg
图中重要的四个步骤就是：
-
计算CSS样式
-
构建渲染树
-
布局，主要定位坐标和大小，是否换行，各种position overflow z-index属性
-
绘制，将图像绘制出来
然后，图中的线与箭头代表通过js动态修改了DOM或CSS，导致了重新布局（Layout）或渲染（Repaint）
这里Layout和Repaint的概念是有区别的：
-
Layout，也称为Reflow，即回流。一般意味着元素的内容、结构、位置或尺寸发生了变化，需要重新计算样式和渲染树
-
Repaint，即重绘。意味着元素发生的改变只是影响了元素的一些外观之类的时候（例如，背景色，边框颜色，文字颜色等），此时只需要应用新样式绘制这个元素就可以了.
回流的成本开销要高于重绘，而且一个节点的回流往往回导致子节点以及同级节点的回流， 所以优化方案中一般都包括，尽量避免回流。
什么会引起回流？
1.页面渲染初始化
2.DOM结构改变，比如删除了某个节点
3.render树变化，比如减少了padding
4.窗口resize
5.最复杂的一种：获取某些属性，引发回流，
很多浏览器会对回流做优化，会等到数量足够时做一次批处理回流，
但是除了render树的直接变化，当获取一些属性时，浏览器为了获得正确的值也会触发回流，这样使得浏览器优化无效，包括
(1) offset(Top/Left/Width/Height)
(2) scroll(Top/Left/Width/Height)
(3) cilent(Top/Left/Width/Height)
(4) width,height
(5) 调用了getComputedStyle()或者IE的currentStyle
回流一定伴随着重绘，重绘却可以单独出现
所以一般会有一些优化方案，如：
-
减少逐项更改样式，最好一次性更改style，或者将样式定义为class并一次性更新
-
避免循环操作dom，创建一个documentFragment或div，在它上面应用所有DOM操作，最后再把它添加到window.document
-
避免多次读取offset等属性。无法避免则将它们缓存到变量
-
将复杂的元素绝对定位或固定定位，使得它脱离文档流，否则回流代价会很高
注意：改变字体大小会引发回流
再来看一个示例：
var s = document.body.style;
s.padding = "2px"; // 回流+重绘
s.border = "1px solid red"; // 再一次 回流+重绘
s.color = "blue"; // 再一次重绘
s.backgroundColor = "#ccc"; // 再一次 重绘
s.fontSize = "14px"; // 再一次 回流+重绘
// 添加node，再一次 回流+重绘
document.body.appendChild(document.createTextNode('abc!'));
普通图层和复合图层
渲染步骤中就提到了composite概念。
可以简单的这样理解，浏览器渲染的图层一般包含两大类：普通图层以及复合图层
首先，普通文档流内可以理解为一个复合图层（这里称为默认复合层，里面不管添加多少元素，其实都是在同一个复合图层中）
其次，absolute布局（fixed也一样），虽然可以脱离普通文档流，但它仍然属于默认复合层。
然后，可以通过硬件加速的方式，声明一个新的复合图层，它会单独分配资源
（当然也会脱离普通文档流，这样一来，不管这个复合图层中怎么变化，也不会影响默认复合层里的回流重绘）
可以简单理解下：GPU中，各个复合图层是单独绘制的，所以互不影响，这也是为什么某些场景硬件加速效果一级棒。
