浏览器渲染机制|原理篇

这篇文章不要按 API 清单来背。先用上面的 Mind Map 建立全局结构，再通过交互 DEMO 观察正常路径和边界路径如何改变状态；阅读正文时重点核对每一步的输入、负责执行的参与者、产生的中间状态以及最终可观察结果。遇到版本敏感结论，要把“历史实现”“当前行为”和“工程兼容策略”分开说明；遇到性能或架构取舍，则用实际指标、失败现象和验证手段支撑判断。

版本校准： 原理文章中的代码代表特定实现与写作时间。应用到当前项目时，应先确认浏览器、框架或工具的主版本，再区分稳定的规范语义、可变化的内部实现和项目自身约束。

# 线程和进程

进程和线程的概念可以这样理解：

进程是一个工厂，工厂有它的独立资源–工厂之间相互独立–线程是工厂中的工人，多个工人协作完成任务–工厂内有一个或多个工人–工人之间共享空间

工厂有多个工人，就相当于一个进程可以有多个线程，而且线程共享进程的空间。

进程是cpu资源分配的最小单位（是能拥有资源和独立运行的最小单位，系统会给它分配内存） 线程是cpu调试的最小单位（线程是建立在进程的基础上的一次程序运行单位，一个进程中可以有多个线程。核心还是属于一个进程。）

# 浏览器是多进程的

浏览器是多进程的，每打开一个tab页，就相当于创建了一个独立的浏览器进程。

# 浏览器包含的进程：

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

在浏览器中打开一个网页相当于新起了一个进程（进程内有自己的多线程）

# 浏览器多进程的优势

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

简单理解就是：如果浏览器是单进程的，某个Tab页崩溃了，就影响了整个浏览器，体验就会很差。同理如果是单进程的，插件崩溃了也会影响整个浏览器; 当然，内存等资源消耗也会更大，像空间换时间一样。

# 重点是浏览器内核（渲染进程）

对于普通的前端操作来说，最重要的渲染进程：页面的渲染，js的执行，事件的循环等都在这个进程内执行;

浏览器是多进程的，浏览器的渲染进程是多线程的；

# GUI渲染线程

• 负责渲染浏览器界面，解析HTML,CSS,构建DOM树和RenderObject树，布局和绘制等。
• 当界面需要重绘或由于某种操作引发回流时，该线程就会执行。
• 注意，GUI渲染线程与JS引擎线程是互斥的，当JS引擎执行时GUI线程会被挂起（相当于冻结了）,GUI更新会被保存在一个队列中等到JS引擎空闲时立即被执行。

# JS引擎线程

• 也称为JS内核，负责处理JavaScript脚本程序。（例如V8引擎）。
• JS引擎线程负责解析JavaScript脚本，运行代码。
• JS引擎一直等待着任务队列中任务的到来，然后加以处理，一个Tab页（render进程）中无论什么时候都只有一个JS线程在运行JS程序。
• 同样注意，GUI渲染线程与JS引擎线程是互斥的，所以如果JS执行的时间过长，这样就会造成页面的渲染不连贯，导致页面渲染加载阻塞。

# 事件触发线程

• 归属于浏览器而不是JS引擎，用来控制事件循环（可以理解成JS引擎自己都忙不过来，需要浏览器另开线程协助）。
• 当JS引擎执行代码块如setTimeout时（也可来自浏览器内核的其它线程，如鼠标点击，AJAX异步请求等），会将对应任务添加到事件线程中。
• 当对应的事件符合触发条件被触发时，该线程会把事件添加到待处理队列的队尾，等待JS引擎的处理。
• 注意，由于JS的单线程关系，所以这些待处理队列中的事件都得排队等待JS引擎处理（当JS引擎空闲时才会去执行）。

# 定时触发器线程

• 传说中的setTimeout和setInterval所在的线程
• 浏览器定时计数器并不是由JavaScript引擎计数的，（因为JavaScript引擎是单线程的，如果处于阻塞线程状态就会影响计时的准确）
• 因此通过单独线程来计时并触发定时（计时完毕后，添加到事件队列中，等待JS引擎空闲后执行）
• 注意，W3C在HTML标准中规定，规定要求setTimeout中低于4ms的时间间隔算为4ms。

# 异步http请求线程

• 在XMLHttpRequest在连接后是通过浏览器新型一个线程请求
• 将检测到状态变更时，如果设置有回调函数，异步线程就产生状态变更事件，将这个回调再放入事件队列中，再由JavaScript引擎执行

总结下来，渲染进程如下：

# Browser主进程和浏览器内核（渲染进程）的通信过程

打开一个浏览器，可以看到：任务管理器出现了2个进程（一个主进程，一个是打开Tab页的渲染进程）；

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

# 浏览器内核（渲染进程）中线程之间的关系

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

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

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

JS阻塞页面加载

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

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

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

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

这里说的是头部引入css的情况 首先，我们都知道：css是由单独的下载线程异步下载的。 然后还有几个现象：

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

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

WebWorker,JS的多线程？

前文中有提到JS引擎是单线程的，而且JS执行时间过长会阻塞页面，那么JS就真的对cpu密集型计算无能为力么？

所以，后来HTML5中支持了WebWorker。

这样理解下：

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

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

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

WebWorker与SharedWorker

既然都到了这里，就再提一下SharedWorker（避免后续将这两个概念搞混）

WebWorker只属于某个页面，不会和其他页面的Render进程（浏览器内核进程）共享 所以Chrome在Render进程中（每一个Tab页就是一个render进程）创建一个新的线程来运行Worker中的JavaScript程序。

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

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

# 总结浏览器渲染流程

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

浏览器内核拿到内容后，渲染大概可以划分为：

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

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

load事件与DOMContentLoaded事件的先后

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

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

当 DOMContentLoaded 事件触发时，仅当DOM加载完成，不包括样式表，图片。 (譬如如果有async加载的脚本就不一定完成)

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

所以，顺序是：DOMContentLoaded -> load