Chrome設計文檔-多進程架構

chromium multi-process architecture

本文檔從high-level的角度描述Chromium的多進程架構。

問題

要構建一個決不崩潰或掛起的渲染引擎幾乎是不可能的。一樣的，要構建一個100%安全的渲染引擎也是不可能的。

從某些角度來看，當今的web瀏覽器有點相似於過去的單用戶，多任務操做系統。正如一個異常的程序會致使整個系統down掉，一個異常的網頁也會致使一個現代瀏覽器掛掉。

現代操做系統之因此更加健壯利益於它們把應用放到隔離的進程中。一個應用的崩潰不會影響其它的應用或者操做系統自己。任一用戶對其它用戶的數據操做都是嚴格受限的。

架構概述

咱們針對瀏覽器的tab使用隔離的進程。這種方案能夠保護應用自己完整，不受渲染引擎的bugs或小差錯的影響。同時，咱們也嚴格限制從渲染引擎到其它進程的訪問。從某些方面來看，這給網頁瀏覽帶來了內存保護和訪問控制的收益。而這兩點均借鑑自操做系統。

咱們把主進程稱爲「browser process（瀏覽進程）或browser」。該進程負責UI的運行和tab的管理工做，同時，也負責插件進程的管理工做。相似的，tab特定的進程被稱爲「render process」或者「renderer」。Renderers使用」WebKit」開源引擎解析並佈局HTML文檔。

管理渲染進程（Rendering process / Renderer）

每個Renderer對應一個全局的RenderProcess對象。該對象管理Renderer與父進程Browser process間的通訊，並維護全局狀態。Browser則維護多個RenderProcessHost對象。每一個RenderProcessHost對應一個Renderer。Browser負責策略瀏覽狀態以及與Renderer的通訊。Browser與Renderers間的通訊由Chromium的IPC系統承擔。

管理Views

每一個Renderer有一個或多個RenderView對象。一個Renderer至關於一個tab。相應的，RenderProcessHost維護一個RenderViewHost。一個RenderViewHost對應於Renderer中的一個view。同一個Renderer中，爲了區分不一樣的view，每一個view會被分配一個ID。這些ID在同一個Renderer裏是惟一的，但在browser裏並非。因此，要標識一個view，須要RenderProcessHost和一個view ID。

組件和接口

在Render進程裏：

• RenderProcess負責處理與RenderProcessHost間的IPC。RenderProcessHost位於Browser中。每個Render進程僅一個RenderProcess。全部的browser和renderer間的通訊都是這樣子的。
• RenderView對象與browser進程中的RenderViewHost通訊（固然，是經過RenderProcess完成的）。RenderView表明一個網頁上的內容或彈出窗口中的網頁內容。

在Browser進程中：

• Browser對象表明一個頂層的browser窗口
• RenderProcessHost表明browser端的browser<->renderer ipc鏈接。在browser裏，每個render進程對應一個RenderProcessHost。
• RenderViewHost封裝了與遠端的RenderView間的通訊流程。RenderWidgetHost處理輸入和RenderWidget的繪製。

共享Renderer

一般，一個新窗口或新tab打開一個新的進程。瀏覽器會生成一個新進程，而後，指令它去建立一個單獨的RenderView。

有時，tabs或windows間共享Renderer也是必須的或者很是有必要的。好比，一個web應用使用window.open打開一個同步模式的新窗口。這種狀況下，當咱們建立一個新窗口或tab時，咱們須要複用原進程，即窗口打開者所在的進程。對於進程數過多的狀況，咱們也有相應的策略把新tab交給已存在的進程。這些策略參見Process Models。

崩潰探測或渲染異常

每個到browser進程IPC連接會監控渲染進程(renderer)的句柄。若是這些句柄收到信號，那麼渲染進程已經崩潰，tab頁收到崩潰通知。從今開始，當Renderer崩潰時，咱們會顯示一個」sad tab「屏來通知用戶。當前頁面能夠經過點擊」preload「按鈕從新加載。

Renderer沙盒化

假設WebKit在一個分離的進程中運行，咱們有機會控制它對系統資源的訪問。好比，咱們能夠限定renderer的網絡操做只能經過其父進程完成。相似的，咱們也能夠嚴格限制它對文件系統的訪問。

Plug-ins

NPAPI插件運行在本身的進程中，與renderers分離。詳情參見Plugin Architecture。