浏览器渲染流程相关总结

Aditya2022-04-15前端JavaScript

1. 浏览器渲染流程相关总结

之前看了这篇文章《从输入URL到页面加载的过程？如何由一道题完善自己的前端知识体系！》感触颇深，所以一直想根据它的流程来完善自己的知识盲点，这篇文章算是第一步。

2. 区分进程和线程

对于这两个概念我已经记不清了，脑海中仅有的印象是：

浏览器是多进程的
JavaScript 是单线程的

所以，很需要对两者关系进行一次详细的梳理。

文字描述：

进程就是一个应用程序在处理机上的一次执行过程，它是一个动态的概念，而线程是进程中的一部分，进程包含多个线程在运行。
线程是指进程内的一个执行单元,也是进程内的可调度实体.

形象的比喻：

- 进程是一个工厂，工厂有它的独立资源

- 工厂之间相互独立

- 线程是工厂中的工人，多个工人协作完成任务

- 工厂内有一个或多个工人

- 工人之间共享空间
----------------------------------------------------------
- 工厂的资源 -> 系统分配的内存（独立的一块内存）

- 工厂之间的相互独立 -> 进程之间相互独立

- 多个工人协作完成任务 -> 多个线程在进程中协作完成任务

- 工厂内有一个或多个工人 -> 一个进程由一个或多个线程组成

- 工人之间共享空间 -> 同一进程下的各个线程之间共享程序的内存空间（包括代码段、数据集、堆等）

进程是 CPU 资源分配的最小单位（是能拥有资源和独立运行的最小单位）
线程是 CPU 调度的最小单位（线程是建立在进程的基础上的一次程序运行单位，一个进程中可以有多个线程）
不同的进程之间也可以进行通信，不过代价较大
单线程与多线程，都是指在一个进程内的单和多

进程和线程的区别在于：

简而言之, 一个程序至少有一个进程,一个进程至少有一个线程.

3. 浏览器是多进程的

前面也说了，浏览器是多进程的，那我们来了解一下为什么浏览器多进程以及它的优势是什么。

3.1 浏览器包含的进程

我们需要先了解一下浏览器包含的进程（仅列举主要进程）：

Browser 进程：浏览器的主进程（负责协调、主控），只有一个。作用有：
- 负责浏览器界面显示，与用户交互。如前进后退；
- 负责各个页面的管理，创建和销毁其他进程；
- 将 Renderer 进程得到的内存中的 Bitmap，绘制到用户界面上
- 网络资源的管理，下载等。
第三方插件进程：每种类型的插件对应一个进程，仅当使用该插件时才创建
GPU进程：最多一个，用于3D绘制等
浏览器渲染进程（浏览器内核）（Renderer进程，内部是多线程的）：默认每个Tab页面一个进程，互不影响。主要作用为：
- 页面渲染，脚本执行，事件处理等。

从而可以了解到：在浏览器中打开一个网页相当于新起了一个进程（进程内有自己的多线程）。但是由于浏览器的性能优化的结果，打开多个空白标签页后，会被浏览器进行合并成一个进程，所以每一个Tab标签对应一个进程并不一定是绝对的。

3.2 浏览器多进程的优势

相比于单进程浏览器，多进程有如下优点：

避免单个page crash影响整个浏览器
避免第三方插件crash影响整个浏览器
多进程充分利用多核优势
方便使用沙盒模型隔离插件等进程，提高浏览器稳定性

简单点理解：如果浏览器是单进程，那么某个Tab页崩溃了，就影响了整个浏览器，体验有多差；同理如果是单进程，插件崩溃了也会影响整个浏览器；而且多进程还有其它的诸多优势。

3.3 浏览器内核（渲染进程）

重点来了，我们可以看到，上面提到了这么多的进程，那么，对于普通的前端操作来说，最终要的是什么呢？答案是渲染进程。

可以这样理解，页面的渲染，JS的执行，事件的循环，都在这个进程内进行。接下来重点分析这个进程。

请牢记，浏览器的渲染进程是多线程的。

那么接下来看看它都包含了哪些线程（列举一些主要常驻线程）：

GUI渲染线程
- 负责渲染浏览器界面，解析HTML，CSS，构建DOM树和RenderObject树，布局和绘制等。
- 当界面需要重绘（Repaint）或由于某种操作引发回流(reflow)时，该线程就会执行
- 注意，GUI渲染线程与JS引擎线程是互斥的，当JS引擎执行时GUI线程会被挂起（相当于被冻结了），GUI更新会被保存在一个队列中等到JS引擎空闲时立即被执行。
JS引擎线程
- 也称为JS内核，负责处理Javascript脚本程序。（例如V8引擎）
- JS引擎线程负责解析Javascript脚本，运行代码。
- JS引擎一直等待着任务队列中任务的到来，然后加以处理，一个Tab页（renderer进程）中无论什么时候都只有一个JS线程在运行JS程序
- 同样注意，GUI渲染线程与JS引擎线程是互斥的，所以如果JS执行的时间过长，这样就会造成页面的渲染不连贯，导致页面渲染加载阻塞。
事件触发线程
- 归属于浏览器而不是JS引擎，用来控制事件循环（可以理解，JS引擎自己都忙不过来，需要浏览器另开线程协助）
- 当JS引擎执行代码块如setTimeOut时（也可来自浏览器内核的其他线程,如鼠标点击、AJAX异步请求等），会将对应任务添加到事件线程中
- 当对应的事件符合触发条件被触发时，该线程会把事件添加到待处理队列的队尾，等待JS引擎的处理
- 注意，由于JS的单线程关系，所以这些待处理队列中的事件都得排队等待JS引擎处理（当JS引擎空闲时才会去执行）
定时触发器线程
- 传说中的setInterval与setTimeout所在线程
- 浏览器定时计数器并不是由JavaScript引擎计数的,（因为JavaScript引擎是单线程的, 如果处于阻塞线程状态就会影响记计时的准确）
- 因此通过单独线程来计时并触发定时（计时完毕后，添加到事件队列中，等待JS引擎空闲后执行）
- 注意，W3C在HTML标准中规定，规定要求setTimeout中低于4ms的时间间隔算为4ms。
异步http请求线程
- 在XMLHttpRequest在连接后是通过浏览器新开一个线程请求
- 将检测到状态变更时，如果设置有回调函数，异步线程就产生状态变更事件，将这个回调再放入事件队列中。再由JavaScript引擎执行。

3.4 JS引擎为什么是单线程？

这个问题其实应该没有标准答案，譬如，可能仅仅是因为由于多线程的复杂性，譬如多线程操作一般要加锁，因此最初设计时选择了单线程。

但是觉得最具有说服力的还是与它的用途有关。

作为浏览器脚本语言，JavaScript 的主要用途是与用户互动，以及操作 DOM。这决定了它只能是单线程，否则会带来很复杂的同步问题。比如，假定 JavaScript 同时有两个线程，一个线程在某个 DOM 节点上添加内容，另一个线程删除了这个节点，这时浏览器应该以哪个线程为准？

为了利用多核 CPU 的计算能力，HTML5 提出 Web Worker 标准，允许 JavaScript 脚本创建多个线程，但是子线程完全受主线程控制，且不得操作 DOM。所以，这个新标准并没有改变 JavaScript 单线程的本质。

3.5 Browser进程和浏览器内核（Renderer进程）的通信过程

看到这里，首先，应该对浏览器内的进程和线程都有一定理解了，那么接下来，再谈谈浏览器的 Browser 进程（控制进程）是如何和内核通信的，这点也理解后，就可以将这部分的知识串联起来，从头到尾有一个完整的概念。

如果自己打开任务管理器，然后打开一个浏览器，就可以看到：任务管理器中出现了两个进程（一个是主控进程，一个则是打开Tab页的渲染进程），然后在这前提下，看下整个的过程：(简化了很多)

Browser进程收到用户请求，首先需要获取页面内容（譬如通过网络下载资源），随后将该任务通过RendererHost接口传递给Render进程
Renderer进程的Renderer接口收到消息，简单解释后，交给渲染线程，然后开始渲染
- 渲染线程接收请求，加载网页并渲染网页，这其中可能需要Browser进程获取资源和需要GPU进程来帮助渲染
- 当然可能会有JS线程操作DOM（这样可能会造成回流并重绘）
- 最后Render进程将结果传递给Browser进程
Browser进程接收到结果并将结果绘制出来

4. 梳理浏览器内核中线程之间的关系

到了这里，已经对浏览器的运行有了一个整体的概念，接下来，先简单梳理一些概念

4.1 GUI渲染线程与JS引擎线程互斥

由于JavaScript是可操纵DOM的，如果在修改这些元素属性同时渲染界面（即JS线程和UI线程同时运行），那么渲染线程前后获得的元素数据就可能不一致了。

因此为了防止渲染出现不可预期的结果，浏览器设置GUI渲染线程与JS引擎为互斥的关系，当JS引擎执行时GUI线程会被挂起， GUI更新则会被保存在一个队列中等到JS引擎线程空闲时立即被执行。

4.2 JS阻塞页面加载

从上述的互斥关系，可以推导出，JS如果执行时间过长就会阻塞页面。

譬如，假设JS引擎正在进行巨量的计算，此时就算GUI有更新，也会被保存到队列中，等待JS引擎空闲后执行。然后，由于巨量计算，所以JS引擎很可能很久很久后才能空闲，自然会感觉到巨卡无比。

所以，要尽量避免JS执行时间过长，这样就会造成页面的渲染不连贯，导致页面渲染加载阻塞的感觉。

4.3 WebWorker

对于这个API 前文也解释过了，这里在加深一下了解。

MDN的官方解释是：

Web Worker为Web内容在后台线程中运行脚本提供了一种简单的方法。线程可以执行任务而不干扰用户界面

一个worker是使用一个构造函数创建的一个对象(e.g. Worker()) 运行一个命名的JavaScript文件 

这个文件包含将在工作线程中运行的代码; workers 运行在另一个全局上下文中,不同于当前的window

因此，使用 window快捷方式获取当前全局的范围 (而不是self) 在一个 Worker 内将返回错误

这样理解下：

创建Worker时，JS引擎向浏览器申请开一个子线程（子线程是浏览器开的，完全受主线程控制，而且不能操作DOM）
JS引擎线程与worker线程间通过特定的方式通信（postMessage API，需要通过序列化对象来与线程交互特定的数据）

所以，如果有非常耗时的工作，请单独开一个Worker线程，这样里面不管如何翻天覆地都不会影响JS引擎主线程，只待计算出结果后，将结果通信给主线程即可，perfect!

而且注意下，JS引擎是单线程的，这一点的本质仍然未改变，Worker可以理解是浏览器给JS引擎开的外挂，专门用来解决那些大量计算问题。

4.4 WebWorker与SharedWorker

WebWorker只属于某个页面，不会和其他页面的Render进程（浏览器内核进程）共享
- 所以Chrome在Render进程中（每一个Tab页就是一个render进程）创建一个新的线程来运行Worker中的JavaScript程序。
SharedWorker是浏览器所有页面共享的，不能采用与Worker同样的方式实现，因为它不隶属于某个Render进程，可以为多个Render进程共享使用
- 所以Chrome浏览器为SharedWorker单独创建一个进程来运行JavaScript程序，在浏览器中每个相同的JavaScript只存在一个SharedWorker进程，不管它被创建多少次。

看到这里，应该就很容易明白了，本质上就是进程和线程的区别。SharedWorker 由独立的进程管理，WebWorker 只是属于 render 进程下的一个线程。

5. 简单梳理下浏览器渲染流程

简化理解，前期工作可以略成：

- 浏览器输入url，浏览器主进程接管，开一个下载线程，
然后进行 http请求（略去DNS查询，IP寻址等等操作），然后等待响应，获取内容，
随后将内容通过RendererHost接口转交给Renderer进程

- 浏览器渲染流程开始

浏览器器内核拿到内容后，渲染大概可以划分成以下几个步骤：

解析html建立dom树
解析css构建render树（将CSS代码解析成树形的数据结构，然后结合DOM合并成render树）
布局render树（Layout/reflow），负责各元素尺寸、位置的计算
绘制render树（paint），绘制页面像素信息
浏览器会将各层的信息发送给GPU，GPU会将各层合成（composite），显示在屏幕上。

所有详细步骤都已经略去，渲染完毕后就是load事件了，之后就是自己的JS逻辑处理了。

5.1 load 事件与 DOMContentLoaded 事件的先后

上面提到，渲染完毕后会触发load事件，那么你能分清楚load事件与DOMContentLoaded事件的先后么？

很简单，知道它们的定义就可以了：

当 DOMContentLoaded 事件触发时，仅当DOM加载完成，不包括样式表，图片。

(譬如如果有async加载的脚本就不一定完成)

当 onload 事件触发时，页面上所有的DOM，样式表，脚本，图片都已经加载完成了。

（渲染完毕了）

所以，顺序是：DOMContentLoaded -> load

5.2 css加载是否会阻塞dom树渲染？

这里说的是头部引入 css 的情况。

首先，我们都知道：css 是由单独的下载线程异步下载的。

然后再说下几个现象：

css加载不会阻塞DOM树解析（异步加载时DOM照常构建）
但会阻塞render树渲染（渲染时需等css加载完毕，因为render树需要css信息）

这可能也是浏览器的一种优化机制。

因为你加载css的时候，可能会修改下面DOM节点的样式，
如果css加载不阻塞render树渲染的话，那么当css加载完之后，
render树可能又得重新重绘或者回流了，这就造成了一些没有必要的损耗。
所以干脆就先把DOM树的结构先解析完，把可以做的工作做完，然后等你css加载完之后，
在根据最终的样式来渲染render树，这种做法性能方面确实会比较好一点。

5.3 Composite

Chrome 拥有两套不同的渲染路径(rendering path)：硬件加速路径和旧软件路径(older software path)
Chrome 中有不同类型的层： RenderLayer(负责 DOM 子树)和GraphicsLayer(负责 RenderLayer的子树)，只有 GraphicsLayer 是作为纹理(texture)上传给GPU的。
什么是纹理？可以把它想象成一个从主存储器(例如 RAM)移动到图像存储器(例如 GPU 中的 VRAM)的位图图像(bitmapimage)
Chrome 使用纹理来从 GPU上获得大块的页面内容。通过将纹理应用到一个非常简单的矩形网格就能很容易匹配不同的位置(position)和变形(transformation)。这也就是3DCSS 的工作原理，它对于快速滚动也十分有效。

先了解一下浏览器的渲染机制

5.3.1 从 Nodes 到 LayoutObjects

DOM 树中得每个 Node 节点都有一个对应的 LayoutObject。LayoutObject 知道如何在屏幕上 paint Node 的内容。

5.3.2 从 LayoutObjects 到 PaintLayers

一般来说，拥有相同的坐标空间的 LayoutObjects，属于同一个渲染层（PaintLayer）。PaintLayer 最初是用来实现 stacking contest（层叠上下文），以此来保证页面元素以正确的顺序合成（composite），这样才能正确的展示元素的重叠以及半透明元素等等。因此满足形成层叠上下文条件的 LayoutObject 一定会为其创建新的渲染层，当然还有其他的一些特殊情况，为一些特殊的 LayoutObjects 创建一个新的渲染层，比如 overflow != visible 的元素。

5.3.3 从 PaintLayers 到 GraphicsLayers

某些特殊的渲染层会被认为是合成层（Compositing Layers），合成层拥有单独的 GraphicsLayer，而其他不是合成层的渲染层，则和其第一个拥有 GraphicsLayer 父层共用一个。

而每个GraphicsLayer（合成层单独拥有的图层）都有一个 GraphicsContext，GraphicsContext 会负责输出该层的位图，位图是存储在共享内存中，作为纹理上传到 GPU 中，最后由 GPU 将多个位图进行合成，然后显示到屏幕上。

5.3.4 如何变成合成层

合成层创建标准

最常用的方式：translate3d、translateZ
opacity属性/过渡动画（需要动画执行的过程中才会创建合成层，动画没有开始或结束后元素还会回到之前的状态）
will-chang属性（这个比较偏僻），一般配合opacity与translate使用（而且经测试，除了上述可以引发硬件加速的属性外，其它属性并不会变成复合层），作用是提前告诉浏览器要变化，这样浏览器会开始做一些优化工作（这个最好用完后就释放）
video、iframe、canvas、webgl等元素
其它，譬如以前的flash插件

5.3.5 合成层的有点

合成层的位图，会交由 GPU 合成，比 CPU 处理要快
当需要 repaint 时，只需要 repaint 本身，不会影响到其他的层
对于 transform 和 opacity 效果，不会触发 layout 和 paint

注意：

提升到合成层后合成层的位图会交GPU处理，但请注意，仅仅只是合成的处理（把绘图上下文的位图输出进行组合）需要用到GPU，生成合成层的位图处理（绘图上下文的工作）是需要CPU。
当需要repaint的时候可以只repaint本身，不影响其他层，但是paint之前还有style， layout,那就意味着即使合成层只是repaint了自己，但style和layout本身就很占用时间。
仅仅是transform和opacity不会引发layout 和paint，那么其他的属性不确定。

总结合成层的优势：一般一个元素开启硬件加速后会变成合成层，可以独立于普通文档流中，改动后可以避免整个页面重绘，提升性能。

性能优化点：

提升动画效果的元素合成层的好处是不会影响到其他元素的绘制，因此，为了减少动画元素对其他元素的影响，从而减少paint，我们需要把动画效果中的元素提升为合成层。提升合成层的最好方式是使用 CSS 的 will-change属性。从上一节合成层产生原因中，可以知道 will-change 设置为opacity、transform、top、left、bottom、right 可以将元素提升为合成层。
使用 transform 或者 opacity 来实现动画效果, 这样只需要做合成层的合并就好了。
减少绘制区域对于不需要重新绘制的区域应尽量避免绘制，以减少绘制区域，比如一个 fix 在页面顶部的固定不变的导航header，在页面内容某个区域 repaint 时，整个屏幕包括 fix 的 header 也会被重绘。而对于固定不变的区域，我们期望其并不会被重绘，因此可以通过之前的方法，将其提升为独立的合成层。减少绘制区域，需要仔细分析页面，区分绘制区域，减少重绘区域甚至避免重绘。

5.3.6 利用合成层可能踩到的坑

合成层占用内存的问题
层爆炸，由于某些原因可能导致产生大量不在预期内的合成层，虽然有浏览器的层压缩机制，但是也有很多无法进行压缩的情况，这就可能出现层爆炸的现象（简单理解就是，很多不需要提升为合成层的元素因为某些不当操作成为了合成层）。解决层爆炸的问题，最佳方案是打破 overlap 的条件，也就是说让其他元素不要和合成层元素重叠。简单直接的方式：使用3D硬件加速提升动画性能时，最好给元素增加一个z-index属性，人为干扰合成的排序，可以有效减少chrome创建不必要的合成层，提升渲染性能，移动端优化效果尤为明显。

absolute和硬件加速的区别

浏览器渲染的图层一般包含两大类：普通图层以及合成层
首先，普通文档流内可以理解为一个复合图层（这里称为默认复合层，里面不管添加多少元素，其实都是在同一个复合图层中）
其次，absolute布局（fixed也一样），虽然可以脱离普通文档流，但它仍然属于默认复合层。
然后，可以通过硬件加速的方式，声明一个新的合成层，它会单独分配资源（当然也会脱离普通文档流，这样一来，不管这个合成层中怎么变化，也不会影响默认复合层里的回流重绘）

6. 写在最后

本来是想写一下浏览器渲染这一块，但是越写设计的东西越来越多，相关联的东西也就越来越多，无奈只能不断更改大纲，所以内容就变成了：从浏览器进程，到浏览器内核进程运行，再到浏览器渲染流程，杂而碎，说是从头到尾梳理一遍吧，但有些地方也是点到为止。
从文中可以看出来，自己知识盲区的地方越是大篇幅的总结，完全可以另起一篇总结文章。
最近也是梳理自己的知识体系，慢慢补充吧