DreamersCorp. No Boundaries No Limitations

圖片點此

• 崩潰檢測或異常排版

  每個瀏覽器程序的IPC連接會監視程序的 句柄/控制碼 (handle)。如果句柄指示異常(are signaled)，排版引擎已經崩潰，並通知到分頁。然後我們會顯示一個「sab tab」頁面，通知使用者排版引擎已經崩潰。這個頁面可以通過按刷新鍵，重新戴入或者輸入一個新的地址進行瀏覽。當這種情況發生時，我們通知使用者原來的 程序已經不存在了我們需要創新一個新的程序。

• 排版引擎的沙盒模型

  當我們將 WebKit至於一個獨立的程序內，就給了我們機會去限制它訪問系統資源。例如，我們可以確保排版引擎的對網路的訪問，都是通過它的父程序完成的。同樣， 我們可以通過作業系統內置的權限，限制排版引擎對檔案系統的訪問。除了能夠限制排版引擎對檔案系統和網路的訪問外，我們還可以增加其對使用者的顯示和相關 物件的限制。我們可以在一個使用者不可見的windows 桌面上運行一個排版程序。這樣我們可以防止排版引擎打開新的視窗或者被劫持按鍵。 more »

元件和介面（Components and interfaces）

在排版程序內：

• RenderProcess：通過IPC與瀏覽器內對應的 RenderProcess 進行通訊。每一個排版程序，包含一個唯一的RenderProcess 物件。
• RenderView 物件，聯繫著瀏覽器程序裡面的RenderView Host物件(通過RenderProcess)和WebKit排版引擎。RenderView 負責顯示每個分頁下的網頁以及彈出視窗。

在瀏覽器程序內：

• Browser 物件負責顯示最上層的瀏覽器視窗。
• RenderProcessHost 物件顯示單個瀏覽器的側邊 ↔ 排版程序的IPC連接(原文為：The RenderProcessHost object represents the browser side of a single browser ↔ renderer IPC connection)。
• 每個排版程序僅有一個RenderProcessHost物件。
• RenderViewHost 物件封裝與遠程RenderView 之間的通訊。同時負責RenderWidget物件的輸入和顯示。
• 更多細節可以參考 How Chromium displays web pages

排版程序的共享

通常情況下。每頁新視窗或者是新分頁都將在新程序裡面打開。瀏覽器程序負責創建新程序，並引導它創建一個RenderView。有時候有必要讓分頁或者是視 窗共享排版線程。一個網頁應用開啟了一個新的視窗並採用同步實現進行通訊。例如：Javascript裡面的 window.open。在這種情況下，當我們創建一個新的視窗或者一個新的分頁。我們需要重用當前程序打開的視窗。我們還有一種策略：當創建程序的數量 太多的時候，我們會把新創建的分頁附加到已有的程序上。或者當用戶已經有一個程序打開了所需的地址。這個策略我們已經在in Process Models. 裡面描述過。

參考來源

Chrome 多進程架構

本文修改自Chrome 多進程架構，該文譯自Multi-process Architecture。Multi-process 中文翻譯成多程序、多行程、多處理緒、多進程等詞彙。幾個名詞轉換，不一一列舉：對象（objet）→物件；進程（process）→（處理）程序；標籤（process）→分頁；窗口（window）→視窗。
問題：
如何使瀏覽器不會因為某個糟糕的網頁，導致其全盤崩潰？

架構總覽：
「Google瀏覽器」使其每個分頁（Tab）自成一個獨立的程序（process），從而防止整個應用程式因為排版引擎的bug而崩潰。同樣我們會嚴格限制程序訪問作業系統及其記憶體。

我們將運行UI（使用者介面）和管理分頁的插件程序，稱之為”瀏覽器程序或者說是”瀏覽器”。同樣，我們將每個分頁相關的程序，稱之為”排版程序”或者說是”排版”。我們使用開源的 WebKit 作為HTML的解析和排版引擎。

（圖片來源：http://dev.chromium.org）

管理排版(Render)程序每個排版程序都有一個全局的 RenderProcess 的物件，用以管理和父瀏覽器程序之間的通訊，並且保持全局狀態。瀏覽器每一個排版程序，保持一個對應的 RenderProcessHost 物件，用以管理瀏覽器狀態，並負責與其他排版程序進行通訊。瀏覽器程序和排版程序通過Chromium的IPC系統進行通訊。

管理視圖(Views)

每 個排版程序，包含一個或多個 RenderView 物件。RenderProcess物件負責管理RenderView 物件以及分頁(Tabs)的內容。RenderProcessHost裡面包含有RenderViewHost。同時每個RenderViewHost對 應著排版程序的一個 視圖。在一個排版程序裡面的 視圖都有一個不同的視圖ID。這些視圖ID有可能和其他排版程序裡面的視圖ID重名。因此我們確定一個位於的視圖需要同時借助 RenderProcessHost和視圖ID。瀏覽器通過RenderViewHost 物件與指定分頁的內容進行通訊。 RenderViewHost 通過RenderProcessHost 傳遞消息給RenderView上的RenderProcess 物件。

參考來源

Chrome 多進程架構