认识浏览器架构

2023-12-20浏览器架构进程模型Chrome

为什么开一个页面要启动多个进程

打开 Chrome 任务管理器（更多工具 → 任务管理器），你会看到仅仅打开一个 Tab，Chrome 启动了至少 4 个进程：浏览器主进程、GPU 进程、网络进程、渲染进程。再加上扩展和插件，数量更多。

理解这个架构的演进，不是为了背概念，而是为了在面对性能问题、内存泄漏、页面崩溃时知道从哪里入手。

2007 年之前，浏览器所有模块（网络、渲染引擎、JS 引擎、插件）运行在同一个进程内。

不稳定。 一个插件的崩溃拖垮整个浏览器。渲染引擎执行复杂 JS 崩溃，同样全挂。

不流畅。 所有页面共享一个线程，一个页面的死循环会让整个浏览器无响应：

while (true) {
  console.log("freeze");
}

单进程下，这行代码卡死的不是你当前页，是所有页。

不安全。 插件用 C/C++ 编写，拥有系统级权限。恶意插件可以读写磁盘、窃取数据。页面脚本也可以利用浏览器漏洞提权。

Chrome 的解决方案：每个模块独立进程，进程间通过 IPC 通信，互相隔离。

多进程的代价：内存占用更大（每个进程包含公共基础结构的副本），架构更复杂。

Chrome 正将各模块重构为独立的 Service，通过定义好的接口通信。在强性能设备上多进程运行，在资源受限设备上合并到少量进程。本质上是在性能和资源之间做动态权衡。

渲染进程是沙箱化的——页面 JS 无法直接访问文件系统或系统 API，这是安全边界，也是限制。理解了就知道为什么浏览器 API 是现在这个样子。
进程隔离 ≠ 没有性能影响——一个 Tab 的渲染进程崩溃不影响其他 Tab，但多个 Tab 共享 GPU 进程和网络进程，GPU 密集或大量并发请求仍然会相互影响。
内存问题要从进程模型理解——Chrome 的内存占用高不是因为"浏览器做得烂"，而是多进程架构的设计代价。排查内存泄漏时，先确定是哪个进程在涨：渲染进程？扩展进程？
Service Worker 对应 SOA 思想——把缓存、推送等能力拆成独立服务，不依赖页面生命周期。