WebKit 架構(gòu)及模塊
特征：支持不同瀏覽器臊泌，一部分代碼共享妻怎，另外一部分不同箫锤，不同部分稱為 WebKit 的移植（Ports）逛钻，如下圖中虛線框表示不同瀏覽器中實現(xiàn)普遍不同僚焦。
- 最底層是操作系統(tǒng)，WebKit 可以在不同的操作系統(tǒng)上工作
- 操作系統(tǒng)之上的就是 WebKit 依賴的第三方庫曙痘，這些庫是 WebKit 運(yùn)行的基礎(chǔ)
- 再往上一層就是 WebKit 項目了芳悲，圖中又將其分為兩層
-
WebCore部分包含了目前被各個瀏覽器所使用的共享部分，是加工渲染網(wǎng)頁的基礎(chǔ)边坤。包括 HTML（解釋器）名扛、CSS（解釋器）、SVG茧痒、DOM肮韧、渲染樹（ReaderObject 樹、ReaderLayer 樹等）旺订、 Inspector（Web Inspector 開發(fā)者工具弄企、調(diào)試網(wǎng)頁） -
JavaScriptCore引擎是 WebKit 中的默認(rèn) JavaScript 引擎，WebKit 中對 JavaScript 引擎的調(diào)用是獨(dú)立引擎的区拳。例如 Chromium 中替換為 V8 引擎 -
WebKit Ports指的是 WebKit 中的非共享部分拘领，包括硬件加速架構(gòu)、網(wǎng)絡(luò)棧劳闹、視頻解碼院究、圖片解碼等
-
-
WebCore和WebKit Ports之上的層主要提供嵌入式編程接口，提供給瀏覽器調(diào)用本涕。接口層的定義也與移植密切相關(guān)，而不是 WebKit 有一個統(tǒng)一接口伙窃。
WebKit2 嵌入式接口不是 WebKit 嵌入式接口的簡單修改菩颖，而是為了瀏覽環(huán)境的安全性和穩(wěn)定性原因考慮而引入了跨進(jìn)程的架構(gòu)。由蘋果于 2010 年 4 月發(fā)布为障，WebKet2 的進(jìn)程結(jié)構(gòu)模型中至少有兩個進(jìn)程晦闰，其一是 WebKit2 所在的瀏覽器或者 Web 平臺的 UI 進(jìn)程放祟，其二是 Web 進(jìn)程，也就是網(wǎng)頁渲染所在的進(jìn)程
基于 Blink 的 Chromium 瀏覽器結(jié)構(gòu)
Chromium 瀏覽器的架構(gòu)及模塊
Chromium 也是基于 WebKit（Blink）的呻右，并且將很多先進(jìn)的理念引入到瀏覽器中領(lǐng)域跪妥，可以了解如何基于 WebKit 構(gòu)建瀏覽器。
架構(gòu)及模塊
Chromium 的架構(gòu)和主要模塊如下：
從圖中可以看到声滥，Blink 只是其中的一塊眉撵，還有眾多的 Chromium 模塊，包括 GPU/CommandBuffer （硬件加速架構(gòu)）落塑、V8 JavaScript 引擎纽疟、沙箱模型、CC（Chromium Compositor | Chromium 合成器）憾赁、IPC（進(jìn)程間通信）污朽、NPAPI（Netscape Plugin API）、UI 等
再向上就是 “Content 模塊” 和 “Content API（接口）”龙考，他們是 Chromium 對渲染網(wǎng)頁功能的抽象蟆肆。沙箱模型、跨進(jìn)程的 GPU 硬件加速機(jī)制晦款、眾多的 HTML5 功能都是在 Content 層里實現(xiàn)颓芭，將渲染機(jī)制、安全機(jī)制和插件機(jī)制隱藏起來柬赐，提供一個接口供上層模塊使用亡问。
多進(jìn)程模型
好處：
- 避免因單個頁面的不響應(yīng)或者崩潰而影響整個瀏覽器的穩(wěn)定性
- 當(dāng)?shù)谌讲寮罎r不會影響頁面或者瀏覽器的穩(wěn)定性
- 方便了安全模型的實施，沙箱模型是基于多進(jìn)程架構(gòu)的
Chromium 瀏覽器中主要包含的進(jìn)程類型
- Browser 進(jìn)程：瀏覽器主進(jìn)程肛宋，僅有一個
- Renderer 進(jìn)程：渲染進(jìn)程州藕，負(fù)責(zé)頁面渲染，可能有多個酝陈，但不一定同打開的網(wǎng)頁數(shù)量一致
- NPAPI 插件：為 NPAPI 類型的插件創(chuàng)建床玻，每種類型插件創(chuàng)建一次，僅當(dāng)使用時才創(chuàng)建沉帮，多個網(wǎng)頁中共享一個進(jìn)程但有不同的實例锈死。
- GPU 進(jìn)程：僅當(dāng) GPU 硬件加速打開時才會被創(chuàng)建
- PPAPI 進(jìn)程：Pepper 插件創(chuàng)建的進(jìn)程
- 其他類型進(jìn)程：Linux 下的“Zygote”進(jìn)程，Renderer 進(jìn)程由它創(chuàng)建穆壕〈＃“Sandbox”準(zhǔn)備進(jìn)程
Android 版不支持插件，GPU 進(jìn)程變成 Browser 進(jìn)程的一個線程喇勋，Renderer進(jìn)程會演變?yōu)?Android 上的服務(wù)（service）進(jìn)程缨该。并且有“影子”標(biāo)簽，會將后臺的網(wǎng)頁所使用的渲染設(shè)施都清除川背，當(dāng)用戶切換的時候需要重新加載渲染贰拿。
Renderer 進(jìn)程被創(chuàng)建的方式：
- Process-per-site-instance：每個頁面都有獨(dú)立的 Render 進(jìn)程
- Process-per-site：同一個域的頁面共享同一個進(jìn)程
- Process-per-tab：（默認(rèn)）每個標(biāo)簽頁
- Single process：所有渲染工作都在 Browser 進(jìn)程中進(jìn)行蛤袒，Android WebView 中使用
Browser 進(jìn)程和 Renderer 進(jìn)程
因為 Chromium 中的一些類型和 WebKit 內(nèi)部不一致，所以 Chromium 沒有直接使用 WebKit 的接口而是用粘附層進(jìn)行了橋接。并在橋接層之上添加了用于進(jìn)程間通信的 Renderer，將渲染封裝成為單獨(dú)的服務(wù)灯萍，屏蔽具體實現(xiàn)。
Browser 進(jìn)程中也需要 RendererHost 來負(fù)責(zé)進(jìn)程通信珍德，再向上就是 Web Contents，也就是一個一個的標(biāo)簽頁和上層的瀏覽器UI
多線程模型
每個進(jìn)程內(nèi)都有很多線程健蕊，保證 Browser 進(jìn)程中的 UI 線程不會被任何其他費(fèi)時操作影響菱阵。Renderer 進(jìn)程中，不讓其他操作阻止渲染線程的快速執(zhí)行缩功。并且將渲染過程管線化晴及，讓渲染可以在不同的線程執(zhí)行（渲染過程分為很多獨(dú)立階段，每個階段創(chuàng)建一個線程嫡锌，利用CPU多核能力加快渲染虑稼，像流水線一樣提高并發(fā)）
網(wǎng)頁加載渲染過程
- Browser 進(jìn)程收到用戶請求，先 UI 線程處理势木，轉(zhuǎn)發(fā)給 IO 線程蛛倦，然后傳遞給 Renderer 進(jìn)程
- Renderer 進(jìn)程有自己的 IO 線程，經(jīng)過簡單的解釋后交給渲染進(jìn)程渲染啦桌，渲染過程可能需要 Browser 進(jìn)程獲取資源溯壶，GPU 進(jìn)程幫助渲染。渲染結(jié)果由 IO 線程傳遞給 Browser 進(jìn)程
- Browser 進(jìn)程繪制
進(jìn)程間通信：絕大多數(shù)場景使用事件和 Chromium 新創(chuàng)建的任務(wù)傳遞機(jī)制甫男，僅在非用不可的情況下使用鎖或線程安全對象且改。
Content 接口
Content 接口不僅對多進(jìn)程渲染提供一層封裝，并且支持所有 HTML5 功能板驳，GPU 硬件加速功能又跛，沙箱機(jī)制。
WebKit2
WebKit2 是一套權(quán)限的結(jié)構(gòu)和接口若治，目的同 Chromium 類似慨蓝，將渲染過程放在單獨(dú)進(jìn)程中完成。
比較 WebKit2 和 Chromium
- Chromium 使用 WebKit 接口端幼，而不是 WebKit2
- Chromium 是將渲染封裝成為服務(wù)礼烈，在服務(wù)的基礎(chǔ)上構(gòu)建多進(jìn)程。而 WebKit2 希望將多進(jìn)程結(jié)構(gòu)隱藏起來静暂，直接在渲染中實現(xiàn)多進(jìn)程模型济丘。
