為了保證魯棒xìng和安全xìng，chromium採用了多程序架構，為標籤頁分配單獨的程序，我們稱這些程序為渲染程序（renderer process），在渲染程序中使用webkit引擎（現在是blink）來解析html和網頁的排版布局和渲染。但是這些程序執行在乙個沙盒中，它們只具有受限的訪問系統資源的能力，比如說網路資源，檔案系統等。如果這些渲染程序需要訪問這些系統資源，就只能通過另外乙個程序獲取，該程序就是瀏覽器程序（browser process），瀏覽器程序是chromium瀏覽器中的總管，他負責分配和管理其他所有的程序，例如渲染程序，plugin程序，gpu程序等。除了瀏覽器程序之外，其他所有程序的終止都不會導致瀏覽器的崩潰。另外，我們看到的瀏覽器ui介面都是執行在瀏覽器程序中，這裡可能有人提問，瀏覽器程序負責這麼多工（ui介面的響應，其他程序的程序間通訊和訪問網路檔案等系統資源）會不會影響ui響應的速度？這裡就要提到瀏覽器程序中的多執行緒了，其實在瀏覽器中存在許多執行緒，比如ui執行緒（主線程），io執行緒，file執行緒等，詳細內容可以參看另外一篇博文
總體架構圖如下：
管理渲染程序
每個渲染程序都存在乙個renderprocess物件，該物件負責與父程序（瀏覽器程序）程序進行通訊，並且維hù程序的全域性物件。瀏覽器程序也會為每個渲染程序分配乙個相對應的renderprocesshost，該物件負責和渲染程序中的renderprocess物件進行通訊。
管理檢視（views）
每個渲染程序都存在乙個或多個renderview物件，他們對應於我們在瀏覽器介面上看到的標籤頁，所以在上面我們概括的講每個標籤頁都會分配乙個程序其實是不準確的，只是一般情況是這樣，關於標籤頁和渲染程序的關係，我們將在後續的chromium程序模型中分析，這裡就不深入講解。這些renderview物件被renderprocess物件統一管理，為了與其他renderview物件相區分，每個物件都會分配乙個唯一的檢視id。另外在瀏覽器程序中也存在與renderview相對應的renderviewhost物件，這些物件由與renderview對應的renderprocesshost物件統一管理。現在假設瀏覽器也給某個具體的標籤頁傳送訊息時，訊息的流程如下renderviewhost ---> renderprocesshost ---> renderprocess---> renderview. 其中在renderprocesshost與renderprocess之間是程序間通訊（ipc）.
在渲染程序中：
每個渲染程序有且只有乙個renderprocess物件，該物件負責與瀏覽器程序中對應的renderprocesshost物件程序程序間通訊。
在渲染程序中可能存在乙個或多個renderview物件，該物件可能代表乙個標籤頁或者乙個彈出對話方塊。
在瀏覽器程序中：
browser物件代表最上層的瀏覽器視窗。
renderprocesshost物件存在於瀏覽器程序中，負責與渲染程序進行程序間通訊，每存在乙個渲染程序都在瀏覽器程序中存在乙個與之對應的renderprocesshost物件。
renderviewhost物件封裝了與渲染程序中renderview物件的程序間通訊。
總體上來說，當使用者開啟乙個新的網頁時，瀏覽器就分配乙個新的渲染程序，並在渲染程序中建立乙個renderview物件。
更多
Chromium的多程序模式
參考 簡單的說，chrome支援以下幾種程序模型 process per site 同網域名稱範疇的 放在乙個程序，比如www.google.com和www.google.com bookmarks就屬於乙個網域名稱內 google有自己的判定機制 不論有沒有互相開啟的關係，都算作是乙個程序中。用命...
python 多程序的通訊，介紹與使用
import time from multiprocessing import process,queue 要用multiprocessing下面的queue才可以。同樣這個也不能用於多執行緒通訊 from queue import queue 這個是用於多程序的，並不可以用 會報錯 def pro...
python多程序的坑 Python多程序相關的坑
python的multiprocessing模組實現了多程序功能，但官方文件上只有一些比較簡單的用法，主要是使用函式作為process的target，而如何在class中使用多程序並沒有多講解。google出兩篇比較詳細的文章，建議從它們入門 下面記錄一下自己這週在python多程序上碰到的坑 建立...