Google Chrome 「Multi-process」 架構(下)

researcher

This site has been moved to dreamerslab.com

本站已經移至 dreamerslab.com

圖片點此

  • 崩潰檢測或異常排版

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

  • 排版引擎的沙盒模型

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

  • 返還記憶體

    給定的排版引擎運作在獨立的程序內,它會將隱藏的分頁當做低優先級別處理。通常情況下,被最小化的視窗的程序,會讓他們的記憶體自動返還到”可利用記憶體”池內,在低記憶體情況下。視窗會將這部分記憶體交換到高優先級別記憶體。這樣可以保證使用者可視的程序得到更多相應。

    我們可以講這個策略用於隱藏的分頁。當一個排版程序沒有 最上層的分頁,我們可以減小這個程序的工作設置大小,這樣會提示系統如果有需要可以講這個程序的記憶體優先交換出去。因為我們發現減少工作設置大小會降低 兩個分頁間的切換速度,我們採取逐步釋放的策略。這意味著如果使用者在常用分頁間切換的時候,那些不常被使用的分頁其記憶體會優先被置換出去。

    使用者如果有足夠多的記憶體運行他們所有的程序的時候,他們是不會體會到這個差別的。系統僅僅會回收需要的記憶體,如果你有足夠的記憶體是不會有性能損失 的。這會幫助我們在低記憶體環境下獲取更多優化的記憶體足跡。那些不常使用且被置於後天的分頁,其記憶體可以完全交換給前置的分頁。於此形成對比的是,一 個單程序瀏覽器,它所有分頁的數據僅僅會隨意的散落在記憶體中,而且其不可能將使用過和未使用的記憶體區分開,既浪費了記憶體空間又損害了系統性能。

  • 插件

    Firefox形式的NPAPI 插件運行在他們自己的程序內,同其他的排版程序保持分離。這些在Plugin Architecture.有進一步的描述。

  • 資源

    Multi-threaded user interface in Windows on MSDN.

參考來源

Chrome 多進程架構

Related Posts


Comments are closed.