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

微信公眾號(hào)：愛寫bugger的阿拉斯加
如有問題或建議，請后臺(tái)留言，我會(huì)盡力解決你的問題。

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

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

上圖的 WebKit 架構(gòu)，虛線框表示該部分模塊在不同瀏覽器使用的 WebKit 內(nèi)核中的實(shí)現(xiàn)是不同的，也就是它們 不是普遍共享的。用實(shí)線框表示的部分，表示它們是基本上是共享的，但不是絕對(duì)，是因?yàn)樗鼈冎械囊恍┨匦钥赡懿⒉皇枪蚕淼?，而且可以通過不同的編譯設(shè)置改變它們的行為。

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

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

在它們二者之上的就是 WebKit 項(xiàng)目了。

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

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

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

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

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

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

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

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

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

在 Android 系統(tǒng)上， Content Shell 的作用更大，這是因?yàn)橥⑴诺淖髠?cè)的 ”Chromium 瀏覽器“ 部分的代碼根本就沒有開源，這直接導(dǎo)致開發(fā)者只能依賴 Content Shell。

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

多進(jìn)程模型至少帶來了三點(diǎn)好處：

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

2、當(dāng)?shù)谌讲寮罎r(shí)不會(huì)影響頁面或者瀏覽器的穩(wěn)定性，這時(shí)因?yàn)榈谌讲寮脖皇褂枚鄮У倪M(jìn)程來運(yùn)行

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

Chromium 瀏覽器主要包括以下進(jìn)程類型：

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

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

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

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

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

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

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

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

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

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

4、GPU 硬件加速進(jìn)程也是獨(dú)立的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

希望本文對(duì)你有點(diǎn)幫助。

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

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

陛下...看完奏折，點(diǎn)個(gè)贊再走吧！