从 chromium 源码来窥探浏览器的渲染
你好，我是承和。
今天给大家分享一下我对于浏览器渲染以及优化方面的一些理解。
传统面试题
我们在各种面试题以及面试中都大概率看到过这个题目，浏览器在拿到数据后到最终呈现在⻚面上经历了哪些过程？
这绝不是浏览器“刷”的一下就把页面给渲染出来了，中间经历了非常复杂的流程，我们一点点由浅入深来窥探浏览器渲染的整个过程。
传统回答
首先我们可以看下比较传统的回答方式，我们不去考虑 js 文件对⻚面解析造成的影响，在最简单的⻚面中，浏览器仅仅拿到 HTML 文件 和 CSS 文件 ，便可以渲染出一个⻚面。在浏览器引擎中，会分别使用 HTML 解析器以及 CSS 解析器将接收到的二进制流数据转化为浏览器能够识别的 DOM 树和 CSS 规则树，随后将两者进行结合生成 Render(Layout Object)树，浏览器在拿到 (Layout Object)树后再经历分层，绘制等，我们才能在屏幕上看到最终的⻚面。
Chrome 多进程机制
我们从另一个⻆度，Chrome 多进程的⻆度也可以进行探索，大家都知道 Chrome 采用的是一个 多进程架构。 详情参考现代浏览器架构。例如浏览器进程，负责浏览器主框架，提供一些通用的能力，GPU 进程则负责将渲染进程上传到 GPU 中的位图纹理进行处理随后呈现到屏幕上等。而浏览器渲染关联的渲染进程，当然是我们最关心的，它究竟是由哪些线程组成的，以及各个线程之间是如何通信合作来完成渲染的呢？
渲染进程组成
渲染进程主要由如下几个线程组成：
GUI 渲染主线程： 解析 html，css，构建 DOM 树和 LayoutObject。
JS 引擎线程： 执行，解析 JS 代码。
合成器线程：进行分块操作，同时也负责接受用戶的滚动，输入，分发回调事件等。
栅格化线程：将绘制命令转换为位图或者 GPU 能识别的纹理。
我们可以通过 chrome://tracing 记录在一个⻚面渲染过程中，各个线程之间的通信：
如上所示：CRFRenderMain 表示的是渲染主线程，主要进行一些计算的操作。Compositior 表示合成器线程，主要进行合成操作。Compositior Tile Workder 表示栅格化线程，现代浏览器往往有 2-4 个栅格化线程，浏览器会根据资源情况合理分配栅格化线程资源。
线程间通信过程
我们从一帧渲染开始，来看各个线程之间的通信过程，如下所示：
同时Blink内核为了清晰区分各个阶段，也定义了一个类DocumentLifeCycle 来确保各个阶段不会发生来回的跳转。类似于 React 当中的生命周期，一帧的渲染是一个 原子操作， 只要开始渲染便会一路执行到底，而不会进行回滚操作。
整体的渲染流程如下：
合成器线程接收到Vsync信号，开始新的一帧绘制。
我们知道合成器线程可以处理用戶的输入，如果一些输入事件中存在一些回调事件，例如滚动的回调事件，那么合成器线程在上一帧收集完这些事件之后，会在当前帧将这些事件交给渲染主线程进行处理。
执行 requestAnimationFrame 相关的动画操作。
解析 HTML 数据，形成 DOM 树，这是 HTML 解析器(HTMLParser)的主要工作。浏览器接收到的html 数据也是字节流，因此要将其转换成浏览器能认识及转换的 token 标签，在这之中主要经历了如下步骤：
4.1. 解码：浏览器将接收的字节流(Bytes)基于编码方式解析为字符(characters)。
4.2. 分词：通过分词器（词法分析）将字符转换为 Token，分为 Tag Token 和文本 Token。详情可参考 vue 源码中的模板解析过程，大部分还是相同的。
4.3. 将 tokens 标签转换为 nodes 节点，随后将 nodes 节点添加至 DOM 树上，这两步是并行执行的，在这期间，主要是通过栈的数据结构来进行维护(类似于常⻅面试题-括号匹配)，当遇到开标签时，将对应 node 推入栈中，并且添加至 DOM 树上，当遇到文本标签时，就直接将文本 node 添加至 DOM 树上即可，当遇到闭合标签时，就进行出栈操作。另外 html 是一⻔友好语言，对于开闭标签不匹配的场景，或者是自定义的标签，都有自己的处理方式，在这里就不做具体展开。
在有了 DOM 树之后，就需要去计算样式，计算样式的主要过程就不展开了，我们主要来看 CSS 解析器的产物，便是 styleSheets，在控制台使用document.styleSheets可以看到：
关于 stylesheets 的具体属性，可参考stylesheets 详解
我们引入 css 的方式主要有行内样式，行内样式表，外部样式表(最经常使用)，这里的 stylesheets 便是一个个引入方式的最终解析产物。
在将各个引入方式进行解析后，我们就要将这些样式赋予我们的 DOM 节点，浏览器会结合 CSS 的 继承 ， 优先级层叠 等规则，形成 CSS 规则树，可以通过浏览器的Element->Computed 查看一个DOM 节点上的具体样式。
Layout，计算布局，这里主要是将⻚面中真正需要渲染的元素在 Layout Object 树中进行展示。
更新 Layer Tree，这里主要是进行一些分层的操作，例如，更新 Paint Layer Tree 及 Graphic Layer Tree，在下文会进行具体展开。
Paint，生成绘画指令，以及记录需要执行哪些绘画调用和调用顺序，将其序列化记录进 SkPicture 数据结构中。
Composite，计算出每个合成层在合成时所需要的数据，包括位移（Translation）、缩放（Scale）、旋转（Rotation）混合等操作的参数。
以上这些都主要是在浏览器主线程中进行的操作，可看出主要进行的都是些复杂度不是很高的计算操作，而 JS 的解析执行则会放到专⻔的 JS 解析线程中去执行。
提交至合成器线程，合成器线程主要在做的就是一个分块操作，大家都知道，若我们对一个⻚面中的所有元素进行绘制的话是非常消耗性能的(因为可视区域外的渲染根本没有必要)，因此我们会首先进行分块操作，将⻚面中的可视元素进行摘取并绘制。这样可以大大地节省资源。
栅格化，栅格化主要进行的操作便是将上面产生的绘制指令转换成 GPU 能识别的位图或者纹理，主要有以下 2 种方式。
a. 基于 CPU，使用 Skia 库的软件加速(Software Rasterization)，首先绘制进位图里，然后再作为纹理上传到 GPU。
b. 基于 GPU，采用硬件加速(Hardware Rasterization)，这个过程是借助 OpenGL 直接在 GPU 纹理中进行绘制和光栅化，填充像素，也就是 GPU Raster。
提交至 GPU 进程，进行渲染和前后缓冲区的交换，将结果展示至屏幕中。
分层阶段
在上面阐述的线程间通信中，我们主要忽略了分层这个过程，下面我们就主要来研究分层过程中产生的 3 棵树究竟是用来干嘛的。
Layout Object Tree (布局树)
作用：DOM 节点可以分为可视化节点(div,p),非可视化节点(script,meta,head)等。Render 树的作用就是展现⻚面上真正需要渲染的元素，忽略掉不可⻅元素，例如(display:none)，添加不存在 DOM 树中但需要显示的内容(例如伪元素)。
布局树形成概览
产生的过程如上图所示，便是将 DOM 树和 CSS 规则树进行结合，忽略掉不可⻅元素，以及添加可⻅元素，来计算出各个元素在⻚面中的位置。
在 Chrominum 中的源码也较简单，通过判断 display 来产生不同的 Layout Object。
映射关系
各个 html 节点与 Layout Object 的映射关系如下所示，他们都继承自同一个基类 LayoutObject，在其 基础上衍生出了不同的盒子模型，例如我们熟知的块级元素，行内元素以及行内块元素等，这些不同的类都定义了对其子元素以及兄弟元素之间是如何进行布局的，在这不做具体展开。
例子
我们也可以拿一个最简单的布局代码举例，来看看他会产生怎样的一颗 Render 树。
Document
123
1
456