主流程
-
呈现引擎一开始会从网络层获取请求文档的内容，内容的大小一般限制在 8000 个块以内。
然后进行如下所示的基本流程：
解析html以构造DOM树————构建渲染树————布局渲染树————绘制渲染树
image.png
主流程示例：
-
Webkit 主流程（chrome浏览器）
image.png -
Mozilla 的 Gecko 呈现引擎主流程（firefox浏览器）
image.png
-
由图可以发现，两个引擎过程基本相同。主要有三个步骤：
1.解析。浏览器会解析HTML/SVG/XHTML，浏览器解析这三种文件会产生一个DOM Tree；解析CSS，产生style rules；解析Javacript，主要通过DOM API和CSSOM API来操作DOM Tree和CSS Rule Tree。
2.解析完成后，浏览器引擎会通过DOM Tree和CSS Rule Tree来构造Rendering Tree。
3.调用操作系统Native GUI的API绘制。
1.解析 HTML 标签, 构建 DOM 树
2.解析 CSS 标签, 构建 CSSOM 树
3.把 DOM 和 CSSOM 组合成 渲染树 (render tree）
为构建渲染树，浏览器大体上完成了下列工作：
- 从 DOM 树的根节点开始遍历每个可见节点。
- 某些节点不可见（例如脚本标记、元标记等），因为它们不会体现在渲染输出中，所以会被忽略。
- 某些节点通过 CSS 隐藏，因此在渲染树中也会被忽略，例如，上例中的 span 节点---不会出现在渲染树中，---因为有一个显式规则在该节点上设置了“display: none”属性。
visibility: hidden 与 display: none 是不一样的。前者隐藏元素，但元素仍占据着布局空间（即将其渲染成一个空框），而后者 (display: none) 将元素从渲染树中完全移除，元素既不可见，也不是布局的组成部分。
2.对于每个可见节点，为其找到适配的 CSSOM 规则并应用它们。
3.发射可见节点，连同其内容和计算的样式。
visibility: hidden与 display: none是不一样的。前者隐藏元素，但元素仍占据着布局空间（即将其渲染成一个空框），而后者 (display: none) 将元素从渲染树中完全移除，元素既不可见，也不是布局的组成部分。
最终输出的是一个包含屏幕上所有可见元素的内容和样式信息的渲染。有了渲染树，我们就可以进入“布局”阶段。
4.在渲染树的基础上进行布局, 计算每个节点的几何结构
到目前为止，我们已经计算出哪些节点应该是可见的和它们所计算出的样式，但是我们还没有在设备的视口中计算出它们的确切位置和大小——这就是“布局”阶段，也称为“回流”。
为了计算页面上每个对象的确切大小和位置，浏览器从呈现树的根元素开始遍历它。我们看一个简单的例子：
<head>
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>Critial Path: Hello world!</title>
</head>
<body>
<div style="width: 50%">
<div style="width: 50%">Hello world!</div>
</div>
</body>
</html>
上述页面包含两个嵌套的div：第一个（父）div将节点的显示大小设置为视口宽度的50%，而第二个div（被父节点包含）的宽度为其父元素的50%，即视口宽度的25%
布局过程输出的是一个“盒模型”，它精确地获取到视口中每个元素的确切位置和大小：所有相对测量值都被转换为屏幕上的绝对像素。
5.把每个节点绘制到屏幕上 (painting)
最后，现在我们知道哪些节点是可见的，以及它们的计算样式和几何图形，我们可以将这些信息传递到最后一个阶段，它将渲染树中的每个节点转换为屏幕上的实际像素。这一步通常被称为“绘制”或“栅格化”。
上述步骤都需要浏览器完成大量工作，所以相当耗时。不过，Chrome DevTools 可以帮助我们对上述所有三个阶段进行深入的了解。让我们看一下最初“hello world”示例的布局阶段：
- “Layout”事件在时间线中捕获渲染树构建以及位置和尺寸计算。
- 布局完成后，浏览器会立即发出“Paint Setup”和“Paint”事件，将渲染树转换成屏幕上的像素。
执行渲染树构建、布局和绘制所需的时间将取决于文档大小、应用的样式，以及运行文档的设备：文档越大，浏览器需要完成的工作就越多；样式越复杂，绘制需要的时间就越长（例如，单色的绘制开销“较小”，而阴影的计算和渲染开销则要“大得多”）。
