[譯]官方圖解：Chrome 快是有緣由的，現代瀏覽器的多進程架構！（Part 1）

Chrome 是程序員的標配了，而從全球的市場份額來看，它在全球市場的份額已經超過 60%。

在 Chrome 10 週年之際，官方發佈了一個系列文章，用圖解的方式，很清晰的講解了現代瀏覽器的運行原理，Chrome 之因此這麼好用，這麼快，是有緣由的。

這個系列，一共 4 篇文章，第一篇主要講解的是 Chrome 的多進程架構，配圖頗有意思，也很好理解，算是科普的文章。有興趣能夠看下去，若是反響好的話，後面 3 篇我會持續翻譯，以爲好就點個贊或者留言分享吧！

---

CPU、GPU、內存和多進程架構

咱們將經過 4 篇博客，來介紹 Chrome 瀏覽器從高級架構到渲染管道的具體細節。若是你想知道，瀏覽器是如何將你的代碼轉換爲功能性網站；或者你想肯定，爲何可使用特定技術能提升性能，那麼本系列適合你。

做爲本系列的第 1 部分，咱們將介紹關鍵技術名詞和 Chrome 的多進程架構。

1. CPU（中央處理器）

CPU(Central Procession Unit) 能夠被認爲是你計算機的大腦。CPU 核心，就像辦公室工做人員，能夠逐個處理交代給他們的許多不一樣的任務。它能夠處理從數學到藝術的全部事情，並把處理結果返回出去。曾經大多數 CPU 都是單核，但在現代硬件中，你一般會操做的是多核 CPU，多核 CPU 爲你的手機和計算機提供更強的計算能力。

2. GPU

GPU（Graphics Processing Unit）是計算機的另外一部分。與 CPU 不一樣，GPU 更擅長處理簡單任務，同時能夠跨多個核心。顧名思義，它最初是爲處理圖形而誕生的。這就是爲何在圖形處理中，當咱們說到 「使用 GPU」 或者 「GPU 支持」 的時候，一般就在說快速渲染和平滑交互。近年來，隨着 GPU 加速發展，僅在 GPU 上就能夠實現愈來愈多的計算任務。

如上圖所示，三層計算機體系結構中，硬件位於底部，操做系統位於中間，應用程序則在最上層。

當你在計算機或手機上啓動應用程序時，CPU 和 GPU 就是爲應用程序提供有力的支持。一般，應用程序使用操做系統提供的機制在 CPU 和 GPU 上運行。

Process 和 Thread 上執行的程序

在深刻瀏覽器架構以前，要掌握的另外一個概念是 Process（進程） 和 Thread（線程）。

進程能夠理解是應用程序的執行程序，線程則是存在於進程內部，並執行其進程程序的部分功能。

進程做爲線程的邊界，而線程就像遊動在進程中的魚。

進程能夠經過操做系統，啓動另外一個進程來執行不一樣的任務。此時，系統將爲新進程分配不一樣的內存。若是兩個進程間須要通訊，他們能夠利用 IPC（Inter Process Communication）的方式進行通訊。許多應用程序都是以這種方式執行的，所以若是某個工做進程（例如一個選項卡）無響應，重啓它，並不會影響相同應用程序的其餘進程。

瀏覽器架構

那麼如何使用進程和線程構建 Web 瀏覽器？

它多是一個具備多個線程的獨立進程，或者存在多個進程可是隻有部分進程之間會進行 IPC 通訊的結構。

這裏有個很是重要的點須要注意，這些不一樣的架構是實現細節。關於如何構建 Web 瀏覽器沒有標準規範，不一樣瀏覽器的架構可能徹底不一樣。

最重要的是瀏覽器進程，如何與負責應用程序不一樣部分的其餘進程協調。對於渲染器進程，將建立多個進程，並將其分配給每一個選項卡。直到最近，Chrome 才爲每一個標籤提供了一個執行進程，如今它嘗試爲每一個站點提供本身的進程，包括 iframe。

如圖所示，Chrome 的多進程架構，渲染進程會顯示多個圖層，表示 Chrome 爲每一個選項卡運行多個渲染器進程。

這些進程控制什麼？

下面介紹了每一個 Chrome 進程以及其控制的範圍：

• 瀏覽器（Browser）：控制 「Chrome」 應用程序，包括地址欄、書籤、後退和前進按鈕等。還須要處理 Web 瀏覽器的權限管理，例如網絡請求和文件訪問。
• 渲染器（Renderer）：控制選項卡內，網站裏顯示的全部內容。
• 插件（Plugin）：控制網站使用的插件，例如：Flash。
• GPU：獨立於其餘進程，專用於處理 GPU 任務，它被分紅不一樣的進程，由於 GPU 會處理來自多個進程的請求，並將它們繪製在相同的 Surface 中。

不一樣的進程，用於處理 Chrome 的不一樣部分。

還有更多的流程，如：擴展進程（Extension Process）和實用進程（Utility Process）。若是你想查看 Chrome 中正在運行的進程數，請點擊右上角的選項，菜單圖標→選擇更多工具→任務管理器。

這將打開一個窗口，其中包含當前正在運行的進程列表以及它們使用的 CPU/Memory 信息。

Chrome 採用多進程架構的好處

以前，我曾提到 Chrome 使用多個渲染器進程。在最簡單的狀況下，你能夠想象每一個選項卡都有本身的渲染器進程。假設你打開了 3 個選項卡，每一個選項卡都擁有獨立的渲染器進程。若是一個選項卡沒有響應，則能夠關閉無響應的選項卡，並繼續使用，同時保持其餘選項卡處於活動狀態。若是全部選項卡，都在一個進程上運行，則當一個選項卡無響應時，全部選項卡都不會響應。這就很尷尬了。

將瀏覽器的工做，分紅多個進程的另外一個好處是安全性和沙盒。因爲操做系統提供了限制進程權限的方法，所以瀏覽器能夠從某些功能中，對某些進程進行沙箱處理。例如，Chrome 瀏覽器能夠對處理用戶輸入（如渲染器）的進程，限制其文件訪問的權限。

每一個進程都有本身的私有內存空間，所以它們一般包含公有基礎功能（例如 V8 是 Chrome 的 JavaScript 引擎）。這意味着更多的內存使用，由於若是它們是同一進程內的線程，則沒法以它們的方式共享。爲了節省內存，Chrome 限制了它能夠啓動的進程數量。限制會根據設備的內存和 CPU 功率動態調整，但當 Chrome 達到限制時，它會在一個新的進程中打開這個站點。

Chrome 服務化 — 更省內存

一樣的方法也適用於瀏覽器進程。Chrome 正在進行體系結構更改，以便將瀏覽器程序的每一個部分，做爲一項服務運行，從而能夠輕鬆拆分爲不一樣的流程或彙總爲同一個流程。

通常的想法是，當 Chrome 在強大的硬件上運行時，它可能會將每一個服務拆分爲不一樣的進程，從而提供更高的穩定性，但若是它位於資源約束的設備上，Chrome 會將服務整合到一個進程中，從而節省內存佔用。在此更改以前，在相似 Android 的平臺上，已經使用相似的方法，來整合流程以減小內存使用。

站點隔離 — 獨立渲染進程

站點隔離是 Chrome 中最近推出的一項功能，能夠爲每一個跨網站 iframe 運行單獨的渲染器進程。

咱們一直在討論，每一個選項卡有一個獨立的渲染器進程，它容許跨站點 iframe 在單個渲染器進程中運行，並在不一樣站點之間共享內存空間。在同一個渲染器進程中運行 a.com 和 b.com 彷佛沒問題。該同源策略是網絡的核心安全模型，它確保一個站點在未經贊成的狀況下沒法訪問其餘站點的數據，繞過此策略是安全攻擊的主要目標。進程隔離是分離站點的最有效方法。由於 Meltdonw 和 Spectre 這兩個經典漏洞，咱們須要使用進程分離網站，這是很是重要的。默認狀況下，自 Chrome 67 啓用桌面隔離功能後，選項卡中的每一個跨站點 iframe 都會得到單獨的渲染器進程。

啓用站點隔離是一項多年的工程積累。站點隔離並不像分配不一樣的渲染器過程那麼簡單，它從根本上改變了 iframe 彼此通訊的方式。當咱們在運行在不一樣進程上的 iframe 頁面上，打開 devtools，就意味着 devtools 必須實現這些後臺通訊的功能，而且看起來是無縫的。即便使用簡單的文字查找（Ctrl+F），來查找頁面中的單詞，這個操做也是在搜索不一樣渲染器進程。正由於如此，瀏覽器工程師將站點隔離這個功能的發佈，當作一個重要里程碑的緣由。

小結

在這篇文章中，咱們介紹了瀏覽器體系結構的高級視圖，並介紹了多進程體系結構的優勢。咱們還介紹了 Chrome 中，與多進程架構密切相關的服務化和站點隔離。在下一篇文章中，咱們將開始深刻研究這些進程和線程之間發生的事情，以便顯示一個網站。

原文地址：

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

---

「聯機圓桌」👈推薦個人知識星球，一年 50 個優質問題，上桌聯機學習。

推薦閱讀：

寫做是核心競爭力 | Google 工程師解密「猜畫小歌」 | 圖解：HTTP 範圍請求 | Android P 適配經驗 | 技術創業選擇清單 | HTTP傳輸編碼 | 什麼正在消耗你？ | HTTP 內容編碼 | 圖解 HTTP 緩存 | 聊聊 HTTP 的 Cookie | 輔助模式實戰 | Accessibility 輔助模式 | 小程序 Flex 佈局 | 好的 PR 讓你更靠譜 | 密碼管理之道