問題

    構(gòu)建一個(gè)永遠(yuǎn)不會(huì)崩潰或者掛起的排版引擎基本是不可能的，我們同樣也不要指望哪天能夠構(gòu)建出一個(gè)絕對(duì)安全的排版引擎。

    我們現(xiàn)階段的瀏覽器運(yùn)行在一個(gè)單用戶，多合作，多任務(wù)的操作系統(tǒng)中。就像一個(gè)笨拙的應(yīng)用程序可以讓整個(gè)系統(tǒng)崩潰一樣。一個(gè)糟糕的網(wǎng)頁(yè)同樣可以讓一個(gè)現(xiàn)代的瀏覽器崩潰。其原因可能是一個(gè)插件出現(xiàn)bug,最終的結(jié)果是整個(gè)瀏覽器以及其他正在運(yùn)行的標(biāo)簽被銷毀。

    現(xiàn)代操作系統(tǒng)已經(jīng)非常健壯了，它讓應(yīng)用程序在各自的進(jìn)程中運(yùn)行和不會(huì)影響到其他程序。一個(gè)進(jìn)程崩潰不會(huì)損害到其他進(jìn)程以及操作系統(tǒng)。同時(shí)系統(tǒng)會(huì)嚴(yán)格的限制一個(gè)用戶訪問另外一個(gè)用戶空間的數(shù)據(jù)。

架構(gòu)總攬

    我們?yōu)闉g覽器的每個(gè)標(biāo)簽(Tab)開辟一個(gè)獨(dú)立的進(jìn)程，這樣我們防止整個(gè)應(yīng)用程序因?yàn)榕虐嬉娴腷ug而崩潰。同樣我們會(huì)嚴(yán)格限制進(jìn)程訪問操作系統(tǒng)及其內(nèi)存空間。

    我們將運(yùn)行UI和管理標(biāo)簽的插件線程稱之為"瀏覽器進(jìn)程"或者說是"瀏覽器"，同樣，我們將每個(gè)標(biāo)簽相關(guān)的進(jìn)程稱之為"排版進(jìn)程"或者說是"排版"。我們使用開源的WebKit作為HTML的解析和排版引擎。

管理排版(Render)進(jìn)程

每個(gè)排版進(jìn)程都有一個(gè)全局的RenderProcess 的對(duì)象用以管理和父瀏覽器進(jìn)程之間的通訊并且保持全局狀態(tài)。瀏覽器每一個(gè)排版進(jìn)程保持一個(gè)對(duì)應(yīng)的RenderProcessHost對(duì)象用以管理瀏覽器狀態(tài)并負(fù)責(zé)與其他排版進(jìn)程進(jìn)行通訊。瀏覽器進(jìn)程和排版進(jìn)程通過Chromium的IPC系統(tǒng)進(jìn)行通訊。

管理視圖(Views)

每個(gè)排版進(jìn)程包含一個(gè)或多個(gè)RenderView 對(duì)象。RenderProcess對(duì)象負(fù)責(zé)管理RenderView 對(duì)象以及標(biāo)簽(Tabs)的內(nèi)容。RenderProcessHost里面包含有RenderViewHost。

同時(shí)每個(gè)RenderViewHost對(duì)應(yīng)著排版進(jìn)程的一個(gè)視圖。在一個(gè)排版進(jìn)程里面的視圖都有一個(gè)不同的視圖ID。這些視圖ID有可能和其他排版進(jìn)程里面的視圖ID重名。因此我們確定一個(gè)位于的視圖需要同時(shí)借助RenderProcessHost和視圖ID。瀏覽器通過RenderViewHost 對(duì)象與指定標(biāo)簽的內(nèi)容進(jìn)行通訊。RenderViewHost 通過RenderProcessHost 傳遞消息給RenderView上的RenderProcess 對(duì)象。

組件和接口

在排版進(jìn)程內(nèi)：

• RenderProcess  通過IPC與瀏覽器內(nèi)對(duì)應(yīng)的RenderProcess 進(jìn)行通訊。每一個(gè)排版進(jìn)程包含一個(gè)唯一的RenderProcess  對(duì)象。
• RenderView 對(duì)象負(fù)責(zé)聯(lián)系瀏覽器進(jìn)程里面的RenderView Host對(duì)象(通過RenderProcess)和WebKit排版引擎。RenderView 負(fù)責(zé)顯示每個(gè)標(biāo)簽下的網(wǎng)頁(yè)以及彈出窗口。

在瀏覽器進(jìn)程內(nèi)：

• Browser 對(duì)象負(fù)責(zé)顯示最上層的瀏覽器窗口。
• RenderProcessHost 對(duì)象顯示單個(gè)瀏覽器的側(cè)邊 ↔ 排版進(jìn)程的IPC連接(ps:不太理解這句話，付原文如下：The RenderProcessHost object represents the browser side of a single browser ↔ renderer IPC connection)。每個(gè)排版進(jìn)程僅有一個(gè)RenderProcessHost對(duì)象。
• RenderViewHost 對(duì)象封裝與遠(yuǎn)程RenderView 之間的通訊。同時(shí)負(fù)責(zé)RenderWidget對(duì)象的輸入和顯示。

    更多細(xì)節(jié)可以參考 How Chromium displays web pages 

排版進(jìn)程的共享

    通常情況下。每頁(yè)新窗口或者是新標(biāo)簽都將在新進(jìn)程里面打開。瀏覽器進(jìn)程負(fù)責(zé)創(chuàng)建新進(jìn)程并引導(dǎo)它創(chuàng)建一個(gè)RenderView。

    有時(shí)候有必要讓標(biāo)簽或者是窗口共享排版線程。一個(gè)網(wǎng)頁(yè)應(yīng)用開啟了一個(gè)新的窗口并采用同步實(shí)現(xiàn)進(jìn)行通訊。例如：Javasript里面的window.open。在這種情況下，當(dāng)我們創(chuàng)建一個(gè)新的窗口或者一個(gè)新的標(biāo)簽。我們需要重用當(dāng)前進(jìn)程打開的窗口。我們還有一種策略：當(dāng)創(chuàng)建進(jìn)程的數(shù)量太多的時(shí)候，我們會(huì)把新創(chuàng)建的標(biāo)簽附加到已有的進(jìn)程上。或者當(dāng)用戶已經(jīng)有一個(gè)進(jìn)程打開了所需的地址。這個(gè)策略我們已經(jīng)在in Process Models. 里面描述過。

崩潰檢測(cè)或異常排版

       每個(gè)瀏覽器進(jìn)程的IPC連接會(huì)監(jiān)視進(jìn)程的句柄(handle)，如果句柄指示異常(are signaled),排版引擎已經(jīng)崩潰并并通知到標(biāo)簽。然后我們會(huì)顯示一個(gè)"sab tab"頁(yè)面通知用戶排版引擎已經(jīng)崩潰。這個(gè)頁(yè)面可以通過按刷新鍵重新加載或者輸入一個(gè)新的地址進(jìn)行瀏覽。當(dāng)這種情況發(fā)生時(shí)，我們通知用戶原來的進(jìn)程已經(jīng)不存在了我們需要?jiǎng)?chuàng)新一個(gè)新的進(jìn)程。

排版引擎的沙盒模型

        當(dāng)我們將WebKit至于一個(gè)獨(dú)立的進(jìn)程內(nèi)，就給了我們機(jī)會(huì)去限制它訪問系統(tǒng)資源。例如，我們可以確保排版引擎的對(duì)網(wǎng)絡(luò)的訪問都是通過它的父進(jìn)程完成的。同樣，我們可以通過操作系統(tǒng)內(nèi)置的權(quán)限限制排版引擎對(duì)文件系統(tǒng)的訪問。

         除了能夠限制排版引擎對(duì)文件系統(tǒng)和網(wǎng)絡(luò)的訪問外，我們還可以增加對(duì)其對(duì)用戶的顯示和相關(guān)對(duì)象的限制。我們可以在一個(gè)用戶不可見的windows 桌面上運(yùn)行一個(gè)排版進(jìn)程。

         這樣我們可以防止排版引擎打開新的窗口或者被劫持按鍵。

返還內(nèi)存

     給定的排版引擎運(yùn)作在獨(dú)立的進(jìn)程內(nèi)，它會(huì)將隱藏的標(biāo)簽當(dāng)做低優(yōu)先級(jí)處理。通常情況下，被最小化的窗口的進(jìn)程會(huì)講他們的內(nèi)存自動(dòng)返還到"可以內(nèi)存"池內(nèi)，在低內(nèi)存情況下。窗口會(huì)將這部分內(nèi)存交換到高優(yōu)先級(jí)內(nèi)存。這樣可以保證用戶可視的程序得到更多相應(yīng)。我們可以講這個(gè)策略用于隱藏的標(biāo)簽。當(dāng)一個(gè)排版進(jìn)程沒有最上層的標(biāo)簽，我們可以減小這個(gè)進(jìn)程的工作設(shè)置大小，這樣會(huì)提示系統(tǒng)如果有需要可以講這個(gè)進(jìn)程的內(nèi)存優(yōu)先交換出去。因?yàn)槲覀儼l(fā)現(xiàn)減少工作設(shè)置大小會(huì)降低兩個(gè)標(biāo)簽間的切換速度，我們采取逐步釋放的策略。這意味著如果用戶在常用標(biāo)簽間切換的時(shí)候，那些不常被使用的標(biāo)簽其內(nèi)存會(huì)優(yōu)先被置換出去。

用戶如果有足夠多的內(nèi)存運(yùn)行他們所以的程序的時(shí)候他們是不會(huì)體會(huì)到這個(gè)差別的。系統(tǒng)僅僅會(huì)回收需要的內(nèi)存，如果你有足夠的內(nèi)存是不會(huì)有性能損失的。

    這會(huì)幫助我們?cè)诘蛢?nèi)存環(huán)境下獲取更多優(yōu)化的內(nèi)存足跡。那些不常使用且被置于后天的標(biāo)簽其內(nèi)存可以完全交換給前置的標(biāo)簽。于此形成對(duì)比的是，一個(gè)單進(jìn)程瀏覽器，它所有標(biāo)簽的數(shù)據(jù)僅僅會(huì)隨意的散落在內(nèi)存中，而其不可能將使用過和未使用的內(nèi)存區(qū)分開，既浪費(fèi)了內(nèi)存空間有損害了系統(tǒng)性能。

插件

Firefox形式的NPAPI 插件運(yùn)行在他們自己的進(jìn)程內(nèi)，同其他的排版進(jìn)程保持分離。這些在Plugin Architecture.有進(jìn)一步的描述。

資源

Multi-threaded user interface in Windows on MSDN.

本文翻譯自http://dev.chromium.org/developers/design-documents/multi-process-architecture