Inside look at modern web browser 是介绍浏览器实现原理的系列文章，共 4 篇，本次精读介绍第一篇。
虽然本文写于 2018 年，但如今依然值得学习，因为浏览器实现非常复杂，从细节开始学习很容易迷失方向，缺乏整体感，而这篇文章从宏观层面开始介绍，几乎没有涉及代码实现，全都是思路性的描述，非常适合培养对浏览器整体框架性思维。
原文有非常多形象的插图与动图，便于加深对知识的理解，所以也推荐直接阅读原文。
文章先从 CPU、GPU、操作系统开始介绍，因为这些是浏览器运行的基座。
CPU 即中央处理器，可以处理几乎所有计算。以前的 CPU 是单核的，现在大部分笔记电脑都是多核的，专业服务器甚至有高达 100 多核的。CPU 计算能力很强，但只能一件件事处理，
GPU 一开始是为图像处理设计的，即主要处理像素点，所以拥有大量并行的处理简单事物的能力，非常适合用来做矩阵运算，而矩阵运算又是计算机图形学的基础，所以大量用在可视化领域。
CPU、GPU 都是计算机硬件，这些硬件各自都提供了一些接口供汇编语言调用；而操作系统则基于它们之上用 C 语言（如 linux）将硬件管理了起来，包括进程调度、内存分配、用户内核态切换等等；运行在操作系统之上的则是应用程序了，所以应用程序不直接和硬件打交道，而是通过操作系统间接操作硬件。
为什么应用程序不能直接操作硬件呢？这样做有巨大的安全隐患，因为硬件是没有任何抽象与安全措施的，这意味着理论上一个网页可以通过 js 程序，在你打开网页时直接访问你的任意内存地址，读取你的聊天记录，甚至读取历史输入的银行卡密码进行转账操作。
显然，浏览器作为一个应用程序，运行在操作系统之上。
为了让程序运行的更安全，操作系统创造了进程与线程的概念（linux 对进程与线程的实现是同一套），进程可以分配独立的内存空间，进程内可以创建多个线程进行工作，这些线程共享内存空间。
因为线程间共享内存空间，因此不需通信就能交流，但内存地址相互隔离的进程间也有通信需求，需通过 IPC（Inter Process Communication）进行通信。
进程之间相互独立，即一个进程挂了不会影响到其它进程，而在一个进程中可以创建一个新进程，并与之通信，所以浏览器就采用了这种策略，将 UI、网络、渲染、插件、存储等模块进程独立，并且任意挂掉后都可以被重新唤起。
浏览器可以拆分为许多独立的模块，比如：
- 浏览器模块（Browser）：负责整个浏览器内行为协调，调用各个模块。
- 网络模块（Network）：负责网络 I/O。
- 存储模块（Storage）：负责本地 I/O。
- 用户界面模块（UI）：负责浏览器提供给用户的界面模块。
- GPU 模块：负责绘图。
- 渲染模块（Renderer）：负责渲染网页。
- 设备模块（Device）：负责与各种本地设备交互。
- 插件模块（Plugin）：负责处理各类浏览器插件。
基于这些模块，浏览器有两种可用的架构设计，一种是少进程，一种是多进程。
少进程是指将这些模块放在一个或有限的几个进程里，也就是每个模块一个线程，这样做的好处是最大程度共享了内存空间，对设备要求较低，但问题是只要一个线程挂了都会导致整个浏览器挂掉，因此稳定性较差。
多进程是指为每个模块（尽量）开辟一个进程，模块间通过 IPC 通信，因此任何模块挂掉都不会影响其它模块，但坏处是内存占用较大，比如浏览器 js 解析与执行引擎 V8 就要在这套架构下拷贝多份实例运行在每个进程中。
Chrome 尽量为每个 tab 单独创建一个进程，所以我们才能在某个 tab 未响应时，从容的关闭它，而其它 tab 不会受到影响。不仅是 tab 间，一个 tab 内的 iframe 间也会创建独立的进程，这样做是为了保护网站的安全性。
Chrome 并不满足于采用一种架构，而是在不同环境下切换不同的架构。Chrome 将各功能模块化后，就可以自由决定当前将哪些模块放在一个进程中，将哪些模块启动独立进程，即可以在运行时决定采用哪套进程架构。
这样做的好处是，可以在资源受限的机器上开启单进程模式，以尽量节约内存开销，实际上在手机应用上就是这么做的；而在资源丰富、内核数量充足的机器上采用独立进程模式，虽然消耗了更多资源，但获得了更好的稳定性。
site-isolation 将同一个 tab 内不同 iframe 包裹在不同的进程内运行，以确保 iframe 间资源的独占性，以及安全性。该功能直到 2018.7 才更新，是因为背后有许多复杂的工作要处理，比如开发者工具的调试、网页的全局搜索功能，都不能因为进程的隔离而受到影响，Chrome 必须让每个进程单独响应这些操作，并最终聚合在一起，让用户感受不到进程间的阻隔。
本文从浏览器如何基于操作系统提供的进程、线程概念构建自己的应用程序开始，从硬件、操作系统、软件的分层开始，介绍到浏览器是如何划分模块的，并且分配进程或线程给这些模块运行，这背后的思考非常有价值。
从宏观角度看，要设计一个安全稳定、高性能、具有拓展性的浏览器，首先要把各功能模块划分清楚，并定义好各模块的通信关系，在各业务场景下制定一套模块协作的流程。
类似应用程序的主从模式，浏览器的 Browser 模块可以看作主模块，它本身用于协调其它模块的运行，并维持其它各模块的正常工作，在其它模块失去响应时等待或重新唤起，或者在模块销毁时进行内存回收。
各从模块也分工明确，比如在浏览器敲击 URL 地址时，会先通过 UI 模块响应用户的输入，并判断输入是否为 URL 地址，因为输入的可能是其它非法参数，或一些查询或设置命令。若输入的确实是 URL 地址，则校验通过后，会通知 Network 网络模块发送请求，UI 模块就不再关心请求是如何处理了。Network 模块也是相对独立的，仅处理请求的发送与接收，如果接收到的是 HTML 网页，则交给 Renderer 模块进行渲染。
有了这些相对独立且分工明确的模块划分后，将这些模块作为线程或进程管理就都不会影响它们的业务逻辑了，唯一影响的就是内存是否共享，以及某个模块 crash 后是否会影响到其它模块了，所以基于这个架构，判断设备类型，以采用单进程或多进程模式就变得简单了很多，且这个进程弹性架构本身也不需要入侵各模块业务逻辑，本身就是一套独立的机制。
浏览器作为非常复杂的应用程序，想要持续维护，就必须对每个功能点都进行合理的设计，让模块间高内聚、低耦合，这样才不至于让任何修改牵一发而动全身。
微前端的沙箱隔离方案也比较火，这里可以和浏览器 tab/iframe 隔离做个对比。
基于 js 运行时的沙箱方案大多都因为吐槽 iframe 慢而诞生的，一般会基于 with 改变沙箱代码的上下文，修改访问的全局对象引用，但基于 js 原型链特征，为了阻断向原型链追溯到主应用代码，一般会采用 proxy 对 with mock 的变量进行访问阻断。
还有一些方案利用创建空 iframe 获取到 document 变量传递给沙箱，一定程度做到了访问隔离，且对 document 添加的监听会随 iframe 销毁而销毁，便于控制。
还有一些更加彻底的尝试，将 js 代码扔到 web worker 运行，并通过 mock 模拟了 worker 运行时缺失的 dom API。
对比这些方案可以发现，只有最后 worker 的方案是最彻底的，因为浏览器创建的 worker 进程是完全资源隔离的，想要和浏览器主线程通信只能利用 postMessage，虽然有一些基于 ArrayBuffer 的内存共享方案，但因为支持的数据类型具有针对性，也不会存在安全问题。
回到浏览器开发者的视角，为什么 iframe 隔离要花费九牛二虎之力拆分多进程，最后再费很大功夫拼接回来，还原出一个相对无缝的体验？浏览器厂商其实完全可以利用上面提到的 js 运行时能力，对 API 语法进行改造，创建一个逻辑上的沙盒环境。
我认为本质原因是浏览器要实现的沙盒必须是进程层面的，也就是对内存访问权限的绝对隔离，因为逻辑层面的隔离可能随着各浏览器厂商实现差异，或 API 本身存在的逻辑漏洞而导致越权情况的出现，所以如果需要构造一个完全安全的沙盒，最好利用浏览器提供的 API 创建新的进程处理沙盒代码。
本文介绍了浏览器是如何基于操作系统做宏观架构设计的，主要就说了一件事，即对进程，线程模型的弹性使用。同时在 tab、iframe 的设计中也要考虑到安全性要求，在必要的时候采用进程，在浏览器自身模块间因为没有安全性问题，所以可对进程模型进行灵活切换。
如果你想参与讨论，请 点击这里，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。
关注 前端精读微信公众号
版权声明：自由转载-非商用-非衍生-保持署名（创意共享 3.0 许可证）