Chrome V8 系统架构

Chromium 多进程多线程架构

design-documents

https://www.chromium.org/developers/design-documents

https://www.chromium.org/developers/design-documents/multi-process-architecture

Inside look at modern web browser

https://developers.google.com/web/updates/2018/09/inside-browser-part1

https://developers.google.com/web/updates/2018/09/inside-browser-part2

https://developers.google.com/web/updates/2018/09/inside-browser-part3

https://developers.google.com/web/updates/2018/09/inside-browser-part4

浏览器解析过程

现代浏览器是一个及其庞大的大型软件，在某种程度上甚至不亚于一个操作系统，它由多媒体支持、图形显示、GPU 渲染、进程管理、内存管理、沙箱机制、存储系统、网络管理等大大小小数百个组件组成。

虽然开发者在开发 Web 应用时，无需关心底层实现细节，只需将页面代码交付于浏览器计算，就可以展示出丰富的内容。

但页面性能不仅仅关乎浏览器的实现方式，更取决于开发者的水平，对工具的熟悉程度，代码优化是无止尽的。

显然，了解浏览器的基本原理，了解 W3C 技术标准，了解网络协议，对设计、开发一个高性能 Web 应用帮助非常大。

当我们在使用 Chrome 浏览器时，其背后的引擎是 Google 开源的 Chromium 项目，而 Chromium 的内核则是渲染引擎 Blink（基于 Webkit）和 JavaScript 引擎 V8。

在阐述浏览器解析 HTML 文件之前，先简单介绍一下 Chromium 的多进程多线程架构（图 5），它包括多个进程：

一个 Browser 进程

多个 Renderer 进程

一个 GPU 进程

多个 NPAPI Render 进程

多个 Pepper Plugin 进程

而每个进程包括若干个线程：

一个主线程

在 Browser 进程中：渲染更新界面

在 Renderer 进程中：使用持有的内核 Blink 实例解析渲染更新界面

一个 IO 线程

在 Browser 进程中：处理 IPC 通信和网络请求

在 Renderer 进程中：处理与 Browser 进程之间的 IPC 通信

一组专用线程

一个通用线程池

chromium的多进程架构至少带来三点好处

避免单个页面的不响应或者奔溃影响整个浏览器的稳定性；
是当第三方插件奔溃时候不会影响页面或者浏览器的稳定性
方便了安全模型的实施，也就是说沙箱模型是基于多进程架构的, 其实，这很大程度上也是WebKit2产生的原因

通常来讲，chromium浏览器包括以下主要进程类型：

Browser进程：浏览器的主进程，负责浏览器界面的显示，各个页面的管理，其他各种进程的管理；

Render进程：页面的渲染进程，负责页面的渲染工作，WebKit的工作主要在这个进程中完成；

NPAPI插件进程：每种类型的插件只会有一个进程，每个插件进程可以被多个Render进程共享；

GPU进程：最多只有一个，当且仅当GPU硬件加速打开的时候才会被创建，主要用于对3D加速调用的实现；

Pepper插件进程：同NPAPI插件进程，不同的是为Pepper插件而创建的进程

Chromium浏览器的进程模型，包括以下特征：

browser进程和页面是分开的，这保证了页面的奔溃不会导致浏览器主界面的奔溃；

每个页面是独立的进程，这保证了页面之间相互不影响；

插件进程也是独立的，插件的问题不会影响浏览器主界面和页面；

GPU硬件加速进程也是独立的。因为这么多的进程，开发者通常需要知道进程列表中的进程类别，这很简单，可以通过进程的命令行参数"--type"来识别。

有趣的是，就在我写下上面这段文字的时候，我的chrome浏览器的flash插件崩溃了，幸运的是其他一切都很好，感谢chrome的多进程模型！