《WebKit技術內幕》閱讀摘要 —— WebKit 架構和模塊

WebKit 架構及模塊

特徵：支持不一樣瀏覽器，一部分代碼共享，另一部分不一樣，不一樣部分稱爲 WebKit 的移植（Ports），以下圖中虛線框表示不一樣瀏覽器中實現廣泛不一樣。

• 最底層是操做系統，WebKit 能夠在不一樣的操做系統上工做
• 操做系統之上的就是 WebKit 依賴的第三方庫，這些庫是 WebKit 運行的基礎
• 再往上一層就是 WebKit 項目了，圖中又將其分爲兩層
  • WebCore 部分包含了目前被各個瀏覽器所使用的共享部分，是加工渲染網頁的基礎。包括 HTML（解釋器）、CSS（解釋器）、SVG、DOM、渲染樹（ReaderObject 樹、ReaderLayer 樹等）、 Inspector（Web Inspector 開發者工具、調試網頁）
  • JavaScriptCore 引擎是 WebKit 中的默認 JavaScript 引擎，WebKit 中對 JavaScript 引擎的調用是獨立引擎的。例如 Chromium 中替換爲 V8 引擎
  • WebKit Ports 指的是 WebKit 中的非共享部分，包括硬件加速架構、網絡棧、視頻解碼、圖片解碼等
• WebCore 和 WebKit Ports 之上的層主要提供嵌入式編程接口，提供給瀏覽器調用。接口層的定義也與移植密切相關，而不是 WebKit 有一個統一接口。

WebKit2 嵌入式接口不是 WebKit 嵌入式接口的簡單修改，而是爲了瀏覽環境的安全性和穩定性緣由考慮而引入了跨進程的架構。由蘋果於 2010 年 4 月發佈，WebKet2 的進程結構模型中至少有兩個進程，其一是 WebKit2 所在的瀏覽器或者 Web 平臺的 UI 進程，其二是 Web 進程，也就是網頁渲染所在的進程

基於 Blink 的 Chromium 瀏覽器結構

Chromium 瀏覽器的架構及模塊

Chromium 也是基於 WebKit（Blink）的，而且將不少先進的理念引入到瀏覽器中領域，能夠了解如何基於 WebKit 構建瀏覽器。

架構及模塊

Chromium 的架構和主要模塊以下：

從圖中能夠看到，Blink 只是其中的一塊，還有衆多的 Chromium 模塊，包括 GPU/CommandBuffer （硬件加速架構）、V8 JavaScript 引擎、沙箱模型、CC（Chromium Compositor | Chromium 合成器）、IPC（進程間通訊）、NPAPI（Netscape Plugin API）、UI 等

再向上就是 「Content 模塊」 和 「Content API（接口）」，他們是 Chromium 對渲染網頁功能的抽象。沙箱模型、跨進程的 GPU 硬件加速機制、衆多的 HTML5 功能都是在 Content 層裏實現，將渲染機制、安全機制和插件機制隱藏起來，提供一個接口供上層模塊使用。

多進程模型

好處：

• 避免因單個頁面的不響應或者崩潰而影響整個瀏覽器的穩定性
• 當第三方插件崩潰時不會影響頁面或者瀏覽器的穩定性
• 方便了安全模型的實施，沙箱模型是基於多進程架構的

Chromium 瀏覽器中主要包含的進程類型

• Browser 進程：瀏覽器主進程，僅有一個
• Renderer 進程：渲染進程，負責頁面渲染，可能有多個，但不必定同打開的網頁數量一致
• NPAPI 插件：爲 NPAPI 類型的插件建立，每種類型插件建立一次，僅當使用時才建立，多個網頁中共享一個進程但有不一樣的實例。
• GPU 進程：僅當 GPU 硬件加速打開時纔會被建立
• PPAPI 進程：Pepper 插件建立的進程
• 其餘類型進程：Linux 下的「Zygote」進程，Renderer 進程由它建立。「Sandbox」準備進程

Android 版不支持插件，GPU 進程變成 Browser 進程的一個線程，Renderer進程會演變爲 Android 上的服務（service）進程。而且有「影子」標籤，會將後臺的網頁所使用的渲染設施都清除，當用戶切換的時候須要從新加載渲染。

Renderer 進程被建立的方式：

• Process-per-site-instance：每一個頁面都有獨立的 Render 進程
• Process-per-site：同一個域的頁面共享同一個進程
• Process-per-tab：（默認）每一個標籤頁
• Single process：全部渲染工做都在 Browser 進程中進行，Android WebView 中使用

Browser 進程和 Renderer 進程

由於 Chromium 中的一些類型和 WebKit 內部不一致，因此 Chromium 沒有直接使用 WebKit 的接口而是用粘附層進行了橋接。並在橋接層之上添加了用於進程間通訊的 Renderer，將渲染封裝成爲單獨的服務，屏蔽具體實現。

Browser 進程中也須要 RendererHost 來負責進程通訊，再向上就是 Web Contents，也就是一個一個的標籤頁和上層的瀏覽器UI

多線程模型

每一個進程內都有不少線程，保證 Browser 進程中的 UI 線程不會被任何其餘費時操做影響。Renderer 進程中，不讓其餘操做阻止渲染線程的快速執行。而且將渲染過程管線化，讓渲染能夠在不一樣的線程執行（渲染過程分爲不少獨立階段，每一個階段建立一個線程，利用CPU多核能力加快渲染，像流水線同樣提升併發）

網頁加載渲染過程

• Browser 進程收到用戶請求，先 UI 線程處理，轉發給 IO 線程，而後傳遞給 Renderer 進程
• Renderer 進程有本身的 IO 線程，通過簡單的解釋後交給渲染進程渲染，渲染過程可能須要 Browser 進程獲取資源，GPU 進程幫助渲染。渲染結果由 IO 線程傳遞給 Browser 進程
• Browser 進程繪製

進程間通訊：絕大多數場景使用事件和 Chromium 新建立的任務傳遞機制，僅在非用不可的狀況下使用鎖或線程安全對象。

Content 接口

Content 接口不只對多進程渲染提供一層封裝，而且支持全部 HTML5 功能，GPU 硬件加速功能，沙箱機制。

WebKit2

WebKit2 是一套權限的結構和接口，目的同 Chromium 相似，將渲染過程放在單獨進程中完成。

比較 WebKit2 和 Chromium

• Chromium 使用 WebKit 接口，而不是 WebKit2
• Chromium 是將渲染封裝成爲服務，在服務的基礎上構建多進程。而 WebKit2 但願將多進程結構隱藏起來，直接在渲染中實現多進程模型。

更多

《WebKit技術內幕》知識提煉 —— 資源加載和網絡棧