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的多進程模型！