本章從webkit內部的主要結構和模塊開始，隨後介紹基於webkit的chromium遊覽器的內部結構和模塊，並介紹多線程和多進程模型，並將chromium的多進程模型同webkit2的多進程模型進行比較，剖析目前前沿的遊覽器架構和設計理念。
webkit架構
① 操作系統：webkit可以在不同的操作系統上工作，不同遊覽器可能會依賴不同的操作系統，同一個遊覽器使用的webkit也可能依賴不同的操作系統，如chromium遊覽器支持Windows，Mac OS，Linux，Android等；
② 第三方庫：位於操作系統層面之上，是webkit運行的基礎，包括圖形庫，網絡庫，視頻庫等；
③ webkit：webcore加載和渲染網頁的基礎，必不可少；JavaScriptCore引擎爲webkit中默認JavaScript引擎，非唯一，其它還有V8引擎等；webkit ports不同遊覽器使用webkit，由於平臺差異，依賴的第三方庫和需求不同等原因按照自己的方式來設計和實現，屬可移植部分；嵌入式編程接口主要是供遊覽器調用，由於與移植有關，因此有一個與遊覽器相關的綁定層；
基於blink的chromium遊覽器結構
Ⅰ 架構和模塊
chromium基於webkit(blink)，blink只是其中的一塊，和它並列的還有GPU/CommandBuffer(硬件加速架構)，V8 JavaScript引擎，沙箱模型，CC(Chromium Compositor)，IPC，UI等。在這些模塊之上是Content模塊和Content API(接口)，它們是chromium對渲染網頁功能的抽象，將下面的渲染機制，安全機制和插件機制等隱藏起來，提供一個接口層，該接口層被上層模塊或其他項目使用，內部調用者包括chromium遊覽器，Content Shell等，外部包括CEF（Chromium Embedded Framework）、Opera遊覽器等。Chromium遊覽器和Content Shell構建在Content API之上，Chromium具有完整的遊覽器功能，Content Shell是使用Content API來包裝的一層殼，使得用戶可以使用Content模塊來渲染和顯示網頁內容；Android WebView是爲了滿足Android上的WebView設計的，其思想是替換原來Android系統默認的WebView。
Ⅱ 多進程模型
在webkit內核之上，chromium率先在webkit之外引入了多進程模型，使用多進程帶來的好處包括如下三點：其一避免了因單個頁面的不響應或者奔潰而影響整個遊覽器的穩定器，特別是對用戶界面的影響；其二當第三方插件奔潰時不會影響頁面或者遊覽器的穩定性，因爲第三方插件也被基於單獨的進程來運行；其三方便了安全模型的實施，沙箱模型就是基於多進程架構。
chromium遊覽器多進程模型如下圖：
Browser進程：遊覽器的主進程，負責遊覽器界面的顯示、各個頁面的管理，是所有其他類型進程的祖先，負責它們的創建和銷燬等，並且有且只有一個；
Render進程：網頁的渲染進程，負責頁面的渲染工作，blink/webkit的渲染工作主要是在這個進程完成，可能有多個，具體個數允許用戶配置；
NPAPI插件進程：是爲NPAPI類型的插件而創建的，其創建的基本原則是每種類型的插件只會被創建一次，而且僅當使用時纔會創建，當有多個網頁要使用同一個類型的插件的時候，插件進程是被共享的；
GPU進程：做多隻有一個，並且僅當GPU硬件加速打開的時候纔會被創建，主要用於對3D圖形加速調用的實現；
Pepper插件進程：同NPAPI進程，不同是是爲Pepper插件而創建的進程；
其它類型的進程：包括linux下的Zygote進程，render進程就是有它創建；Sandbox進程，用於安全進制中；
總結包括如下特徵：Browser進程和頁面的渲染是分開的，保證了頁面的渲染導致的奔潰不會導致遊覽器主界面的奔潰；每個網頁是獨立的進程，保證了頁面之間相互不影響；插件進程也是獨立的，插件本身的問題不會影響遊覽器主界面和網頁；GPU硬件加速進程也是獨立的。
render進程個數配置類型：
- Process-per-site-instance: 爲每個頁面創建一個獨立的Render進程，不管這些頁面是否來自同一個域，帶來的好處是每個頁面互不影響，壞處是資源的巨大浪費；
- Process-per-site: 屬於同一個域的頁面共享同一個進程，而不屬於同一個域的頁面則分屬於不同的進程，好處是對於相同的域，進程可以共享，壞處是可能會有特別大的Render進程；
- Process-per-tab: chromium爲每個標籤都創建一個獨立的進程，不管它們是否是不同的域不同實例，chroimum的默認行爲；
- Single process: chromium不爲頁面創建任何獨立的進程，所有的渲染都在Browser進程中進行，是Browser進程中的多個線程；
Ⅲ Browser進程和Render進程
Browser進程和Render進程都是在webkit的接口之外由chromium引入的，其代碼層次如下：
webkit接口層： 一般基於webkit接口層的遊覽器直接在上面構建，而沒有引入複雜的多進程架構；
黏附層：由於chromium中的一些類型和webkit內部不一致，需要一個簡單的橋接層；
Render：主要處理進程間通信，接收來自Browser進程的請求，並調用相應的webkit接口層，同時，將webkit的處理結果發送回去；
上面界面的層都是在Render進程中工作的，下面就進入Browser進程。
RenderHost：與Render對應，目的是處理同Render進程之間的通信，是給Render進程發送請求並接收來自Render進程的結果；
Web Contents：表示頁面的內容，頁面可能有多個需要繪製的內容，如彈出對話框內容，因此是Contents，它同時包括顯示內容的一個子窗口，這個子窗口最後被嵌入遊覽器的用戶界面，作爲一個標籤頁；
Ⅳ 多線程模型
chromium多線程模型：
基本工作方式如下
- Browser進程收到用戶的請求，首先由UI線程處理，而且將相應的任務轉給IO線程，他隨機將該任務傳遞給Render進程；
- Render進程的IO線程經過簡單解釋後交給渲染線程，渲染線程接收請求，加載網頁並渲染網頁，這其中可能需要Browser進程獲取資源和需要GPU進程來幫助渲染，最後Render進程將結果由IO線程傳遞給Browser進程；
- Browser進程接收到結果並將結果繪製出來；
Ⅴ Content接口
Content接口不僅提供一層對多線程進行渲染的抽象接口，而且支持所有的HTML5功能、GPU硬件加速功能和沙箱機制，可以讓使用者不需要很多的工作就可以得到強大的能力。Content接口的相關定義文件均在”content/public”目錄下，按照功能分爲六大部分，每個部分的接口一般可以分爲兩類，第一類是嵌入者(embedder，可以是chromium遊覽器，CEF3，Content Shell)調用的接口，另一類是嵌入者應該實現的回調，被Content接口的內部實現所調用，用來參與具體實現的邏輯或者事件的監聽等。
- App： 主要與應用程序或者進程的創建和初始化有關，它被所有的進程使用，用來處理一些進程的公共操作，包括進程創建的初始化函數(Content模塊的初始化和關閉動作)和各種回調函數(告訴嵌入者啓動完成，進程啓動，退出，沙盒模型初始化開始和結束等)；
- Browser：包括兩類，第一類包括對一些HTML5功能和其他一些高級功能實現的參與，因爲這些實現需要chromium的不同平臺的實現，同時需要例如Notification、Speech recognition、Web Worker、Download、Geolocation等Content層提供的接口，Content模塊需要調用它們來實現HTML5的功能，第二類典型接口類是ContentBrowserClient，主要是顯示部分的邏輯，被Browser進程調用，還有一些事件的函數回調；
- Common： 定義一些功能的接口，被Browser和Render共享，如一些進程相關、參數、GPU相關等；
- Plugin：僅有一個接口，通知嵌入者Plugin進程何時被創建；
- Render：包括兩類，第一類包含獲取RenderThread的消息循環，註冊V8 Extension，計算JavaScript表達式等，第二類包含ContentRenderClient，主要是實現部分邏輯，被Browser調用，還有爲一些事件的函數回調；
- Utility： 工具類接口，主要包括讓嵌入者參與Content接口中線程的創建和消息的過濾；
