摘要：多線程的主要目的就是為了保持用戶界面的高響應(yīng)度，保證線程進程中的主線程不會被任何其他費用時的操作阻礙從而影響了對用戶操作的響應(yīng)。

微信公眾號：愛寫bugger的阿拉斯加
如有問題或建議，請后臺留言，我會盡力解決你的問題。

此文章是我最近在看的【W(wǎng)ebKit 技術(shù)內(nèi)幕】一書的一些理解和做的筆記。
而【W(wǎng)ebKit 技術(shù)內(nèi)幕】是基于 WebKit 的 Chromium 項目的講解。

WebKit 的一個顯著特征就是支持不同的瀏覽器，因為不同瀏覽器的需求不同，所以在 WebKit 中一些代碼 可以共享，但是另外一部分是不同的，這些不同的部分稱為 WebKit 的移植( Ports ）。

上圖的 WebKit 架構(gòu)，虛線框表示該部分模塊在不同瀏覽器使用的 WebKit 內(nèi)核中的實現(xiàn)是不同的，也就是它們 不是普遍共享的。用實線框表示的部分，表示它們是基本上是共享的，但不是絕對，是因為它們中的一些特性可能并不是共享的，而且可以通過不同的編譯設(shè)置改變它們的行為。

圖中最下面的是操作系統(tǒng)，不同瀏覽器可能會依賴不同的操作系統(tǒng)，同一個瀏覽器使用的 WebKit 也可能依賴不同的的操作系統(tǒng)。

操作系統(tǒng)之上的就是 WebKit 賴以工作的眾多第三方庫，這些庫是 WebKit 運行的基礎(chǔ)。

在它們二者之上的就是 WebKit 項目了。

WebCore 包含了了目前被 各個瀏覽器所使用的 WebKit 共享部分，這些都是加載和渲染網(wǎng)頁的基礎(chǔ)部分，它們必不可少，包括 HTML (解釋器)、CSS (解釋器)、SVG、DOM、渲染樹（RenderObject 樹和RenderLqyer 樹等)，以及 Inspector(Web Inspector和調(diào)試網(wǎng)頁)。這些共享部分有些是基礎(chǔ)框架，其背后支持也需要各個平臺的不同實現(xiàn)。

JavaScriptCore 引擎是 WebKit 中默認 JavaScript 引擎，也就是說一些 WebKit 的移植使用該引擎。而且它只是默認，并不是唯一的，是可以替換的。事實上，WebKit 中對 JavaScript 引擎的調(diào)用是獨立于引擎的。在 Google 的 Chormium 開源項目中，它被替換成 V8 引擎。

WebKit Ports 指的是 WebKit 中的非共享部分，對于不同瀏覽器使用的 WebKit 來說，移植中的這些模塊由于平臺差異、第三方庫和需求不同等原因，往往按照自己的方式來設(shè)計與實現(xiàn)，這就產(chǎn)生了移植部分，這也是導(dǎo)致眾多 WebKit 版本的行為并非一到的重要原因。這其中包括硬件的 加速架構(gòu)，網(wǎng)絡(luò)棧，視頻解碼，圖片解碼等。

在 WebCore 和 WebKit Ports 之上的層主要是提供嵌入式編程接口，這些接口是提供給瀏覽器調(diào)用（當(dāng)然也可以有其他使用者）。圖中有左右兩個部分分別是狹義 WebKit 的接口和 WebKit2 的接口。因為接口與具體的移植有關(guān)，所以有一個與瀏覽器相關(guān)的綁定層。綁定層上面就是 WebKit 項目對外暴露的接口層。實際上接口層的定義也是與移植密切相關(guān)的，而不是 WebKit 有什么統(tǒng)一接口。

WebKit 還有一個部分在圖中沒有展現(xiàn)出來，那就是測試用例，包括布局測試用例( Layout Tests )和性能測試用例（ Performance Tests ），這兩類測試包括了大量的測試用例和期望結(jié)果。為了保證 WebKit 的代碼質(zhì)量，這些用例被用來驗證渲染結(jié)果的正確性。

Chromium 也是基于 WebKit ( Blink ) 的，而且在 WebKit 的移植部分中，所以可以通過 Chromium 可以了解如何基于 WebKit 構(gòu)建瀏覽器。

在上面這些模塊之上的就是著名 的 "Content 模塊" 和 “Content API（接口）”，它們是 Chromium 對渲染網(wǎng)頁功能的抽象。"Content 模塊" 的本意是指網(wǎng)頁的內(nèi)容，這里是指用來渲染內(nèi)容的模塊。如果沒有 Content 模塊，瀏覽器的開發(fā)者也可以在 WebKit 的 Chormium 移植上渲染網(wǎng)頁內(nèi)容，但是沒有辦法獲得沙箱模型?？邕M程的 GPU 硬件加速機制、眾多的 HTML5 功能，因為這些功能 很多是在 Content 層里面實現(xiàn)的。

“Content 模塊” 和 “Content API” 將下面的渲染機制。安全機制和插件機制等隱藏起來，提供一個接口層。該接口目前被上層模塊或者其他項目使用，內(nèi)部 調(diào)用者包括 Chromium 瀏覽器、 Content Shell 等、外部包括 CEF (Chromium Embedded Framework)、Opera 瀏覽器等。

“Chromium 瀏覽器” 和 ”Content Shell“ 是構(gòu)建在 Content API 之上的兩個 ”瀏覽器“，Chromium 具有瀏覽器完整的功能，也就是我們編譯出來能看到的瀏覽器式樣。而 ”Content Shell“ 是使用 Content API 來包裝的一層簡單的 ”殼“，但是它也是一個簡單的 ”瀏覽器“，用戶可以使用 Content 模塊來渲染和顯示網(wǎng)頁內(nèi)容。Content Shell 的作用很明顯，其一可以用來測試 Content 模塊很多功能的正確性，例如渲染、硬件加速等。其二是一個參考，可以被很多外部的項目參考來開發(fā)基于 ”Content API“ 的瀏覽器或者各種類型的項目。

在 Android 系統(tǒng)上， Content Shell 的作用更大，這是因為同它并排的左側(cè)的 ”Chromium 瀏覽器“ 部分的代碼根本就沒有開源，這直接導(dǎo)致開發(fā)者只能依賴 Content Shell。

”Android WebView“ 是為了滿足 Android 系統(tǒng)上的 WebView 而設(shè)計的，其思想是利用 Chromium 的實現(xiàn)來替換原來 Android 系統(tǒng)默認的 WebView。

多進程模型至少帶來了三點好處：

1、避免因單個頁面不響應(yīng)或者崩潰而影響整個瀏覽器的穩(wěn)定性

2、當(dāng)?shù)谌讲寮罎r不會影響頁面或者瀏覽器的穩(wěn)定性，這時因為第三方插件也被使用多帶帶的進程來運行

3、它方便了安全模型的實施，也就是說沙箱模型是基于多進程架構(gòu)的。

Chromium 瀏覽器主要包括以下進程類型：

1、Browser 進程：瀏覽器的主進程，負責(zé)瀏覽器界面的顯示、各個頁面的管理、是所有其他類型進程的祖先、負責(zé)它們的創(chuàng)建和銷毀等工作，它有且僅有一個。

2、Renderer 進程：網(wǎng)頁的渲染進程，負責(zé)頁面的渲染工作， Blink/WebKit 的渲染工作主要在這個進程中完成，可能有多個，但是 Renderer 進程的數(shù)量與用戶打開的網(wǎng)頁數(shù)量不一定一致，Chromium 設(shè)計了靈活的機制，允許用戶配置。此外，在沙箱模型啟動的情況下，該進程可能會發(fā)生一些改變。

3、NPAPI 插件進程：該進程是為 NPAPI 類型的插件而創(chuàng)建的。其創(chuàng)建的基本原則是每種類型的插件只會被創(chuàng)建一次，而且僅當(dāng)使用時才會被創(chuàng)建。當(dāng)有多個網(wǎng)頁需要使用同一種類型的插件的時候，例如很多網(wǎng)頁需要使用 Flash 插件， Flash 插件的進程會為每個使用者創(chuàng)建一個實例，所以插件進程是被共享的。

4、GPU 進程： 最多只有一個，當(dāng)且僅當(dāng) GPU 硬件加速打開的時候才會被創(chuàng)建，主要用于對 3D 圖形加速調(diào)用的實現(xiàn)。

5、Pepper 插件進程：同 NPAPI 插件進程，不同的是為 Pepper 插件而創(chuàng)建的進程。

6、其他類型的進程：圖中還有一些其他類型的進程沒有描述出來，例如 Linux 下的 “Zygote” 進程，Renderer 進程其實都是由它創(chuàng)建而來。另外一個就是名為 “Sandbox” 的準備進程，這在安全機制中作進一步的介紹。

對于桌面系統(tǒng)（Windows、Liunx、Mac OS）中的 Chormium 的瀏覽器，它們的進程模型總結(jié)后包括以下一些特征：

1、Browser 進程和頁面的渲染分開的，這保證了頁面的渲染導(dǎo)致的崩潰不會導(dǎo)致瀏覽器主界面的崩潰。

2、每個網(wǎng)頁是獨立的進程，這保證了頁面之間相互不影響。

3、插件進程也是獨立的，插件本身的問題不會影響瀏覽器主界面和網(wǎng)頁

4、GPU 硬件加速進程也是獨立的。

Browser 進程和 Render 進程是如何利用 WebKit 渲染網(wǎng)頁的，這其中的代碼層次由圖 3-6 給出。

最下面的就是 WebKit 接口層，一般基于 WebKit 接口層的瀏覽器直接在上面構(gòu)建，而沒有引入復(fù)雜的多進程架構(gòu)。

然后，在 WebKit 接口層上面就是 Chromium 基于 WebKit 的接口層而引入黏附層，它的出現(xiàn)主要是因為 Chromium 中的一些類型和 WebKit 內(nèi)部不一致，所以需要一個簡單的橋接層。

再上面的就是 Renderer，它主要是處理進程間通信，接受來自Browser 進程的請求，并調(diào)用相應(yīng)的 WebKit 接口層，同時，將 WebKit 的處理結(jié)果發(fā)送回去，上面這些介紹的層都是在 Renderer 進程中工作的。

下面就進入了 Browser 進程，與 Renderer 進程相對應(yīng)的就是 RendererHost, 其目的也是處理同 Renderer 進程之間的通信。不過 RendererHost 是給 Renderer 進程發(fā)送請求并接收來自 Renderer 進程的結(jié)果。

Web Contents 表示的就是網(wǎng)頁的內(nèi)容，因為網(wǎng)頁可能有多個需要繪制的內(nèi)容，例如彈出的對話框內(nèi)容，所以這里是 “Contents”。它同時包括顯示網(wǎng)頁內(nèi)容的一個子窗口（在桌面系統(tǒng)上），這個子窗口最后被嵌入瀏覽器的用戶界面，作為它的一個標簽頁。

每個進程內(nèi)部都有很多的線程。

多線程的主要目的就是為了保持用戶界面的高響應(yīng)度，保證 UI 線程（Browser進程中的主線程）不會被任何其他費用時的操作阻礙從而影響了對用戶操作的響應(yīng)。這些費時的其他操作很多，例如本地文件讀寫、socket 讀寫、數(shù)據(jù)庫操作等。

既然文件讀寫等會阻礙其他操作，所以把它們放在多帶帶的線程里面自己忙或者等待去吧。而在 Renderer 進程中，Chromium 則不讓其他操作阻止渲染線程的快速執(zhí)行。為了利用多核的優(yōu)勢，Chromium 將渲染過程管線化，這樣可以讓渲染的階段在不同的線程執(zhí)行。

網(wǎng)頁的加載和渲染過程在圖中模型下的基本工作方式如以下步驟：
1、Browser 進程收到用戶的請求，首先由 UI 線程處理，而且將相應(yīng)的任務(wù)轉(zhuǎn)給 IO 線程，它隨即將該任務(wù)傳遞給 Renderer 進程。

2、Renderer 進程的 IO 線程經(jīng)過簡單解釋后交給渲染線程。渲染線程接受請求，加載網(wǎng)頁并渲染網(wǎng)頁，這其中可能需要 Browser 進程獲取資源和需要 GPU 進程來幫助渲染，最后 Renderer 進程將結(jié)果由 IO 線程傳遞給 Browser 進程。

3、最后 Renderer 進程接收到結(jié)果并將結(jié)果繪制出來。

Content 接口不僅提供了一層對多進程進行渲染的抽象接口，而且它從誕生以來一個重要的目標就是要支持所有的 HTML5 功能、GPU 硬件加速功能和沙箱機制，這可以讓 Content 接口的使用都們不需要很多的工作即可得到很強大的能力。

Content 接口按照功能分成六個部分。每個部分的接口一般也可以分成兩類，第一類是嵌入者（embedder，這里可以是 Chromium 瀏覽器、CEF3 和 Content Shell ）調(diào)用的接口，另一類是嵌入者應(yīng)該實現(xiàn)的回調(diào)接口，被 Content 接口的內(nèi)部實現(xiàn)所調(diào)用，用來參與具體實現(xiàn)的邏輯或者事件的監(jiān)聽等。

相比于狹義的 WebKit ，WebKit2 是一套全新的結(jié)構(gòu)和接口，而不是一個簡單的升級版。它的主要目的和思想同 Chromium 類似，就是將渲染過程放在多帶帶的進程中來完成，獨立于用戶界面。

依舊是自底向上介紹，WebKit2 中也引入了插件進程，而且它還引入了網(wǎng)絡(luò)進程。圖中的 “Web 進程” 對應(yīng)于 Chromium 中的 Renderer 進程，主要是渲染網(wǎng)頁。在這之上的是 “UI 進程”，它對應(yīng)于 Chromium 中的 Browser 進程。接口就是暴露在該進程中，應(yīng)用程序只需要調(diào)用該接口即可。其中 “應(yīng)用程序 ” 指的是瀏覽器或者任何使用該接口的程序。

希望本文對你有點幫助。

對 全棧開發(fā) 有興趣的朋友可以掃下方二維碼關(guān)注我的公眾號 —— 愛寫bugger的阿拉斯加

分享 web 開發(fā)相關(guān)的技術(shù)文章，熱點資源，全棧程序員的成長之路

陛下...看完奏折，點個贊再走吧！