譯文：WebKit for Developers

對於許多開發者而言，WebKit 是一個黑盒子。我們把 HTML, CSS, JS 和一堆資源放進去，然後 WebKit 以某種方式，奇妙地變出一箇中看又中用「美觀而實用」的網頁。事實上，如同我同事 Ilya Grigorik 所說 …

WebKit 它不是一個黑盒子，而是一個白盒子，並且是一個開放的白盒子。

那麼讓我們花一點時間來理清一些東西：

WebKit 是什麼？

WebKit 不是什麼？

基於 WebKit 的瀏覽器使如何運用 WebKit ？

為什麼所有的 WebKit 並不一樣「呢」？

雖然現在我們已經有了很多 Webkit 瀏覽器了，特別是有訊息稱 Opera 也已經轉移到 WebKit 了，但是想要理解他們的相同點和不同點還是挺難的。下面我將側重講這方面，你將能更好的分辨瀏覽器的差異，在合適的 bug 跟蹤系統提交 bug，並瞭解如何更加高效的針對特定的瀏覽器進行開發。 標準的 Web 瀏覽器元件 讓我們看一下現代 web 瀏覽器的幾個元件：

• 解析（HTML, XML, CSS, JavaScript）
• 排版（Layout）
• 文字和影像渲染
• 影像解碼
• GPU 互動
• 網路接入
• 硬體加速

那麼哪些是基於 WebKit 的瀏覽器所共享的呢？ 幾乎只有前兩項。

其它的由各自的 WebKit port 負責。讓我們回顧下這意味著什麼？ WebKit Port 雖然 Webkit 有不同的  ”port”，但請允許我引用來自 Sencha 的 WebKit hacker 兼 eng 主管— Ariya Hidayat 解釋一下 ：

WebKit 最常見的參考實現是 Apple 自己的執行在 Mac OS X 上的WebKit 實現（這也是最早最原始的 WebKit 庫）。正如你所知，在 Mac OS X 上各種介面的實現使用不同的本地庫，大多集中在 CoreFoundation 。比如，你定義了一個帶有特別的圓角的平面彩色按鈕，那麼 WebKit 會知道在哪裡以及如何畫繪製這個按鈕。可是，最終實際畫繪製按鈕的職責（作為使用者顯示器上的畫素）還是落到了 CoreGraphics  身上。

如上所述，只有 Apple 自己在 Mac 上的實現是使用 CG。Chrome 在 Mac 上的實現使用的是 Skia。

隨著時間推移，WebKit 被移植到不同的平臺，包括桌面和移動端。這種做法通常被稱作“一個 WebKit port”。對於 Safari 瀏覽器的 Windows 版本，Apple 也把自己的 WebKit 移植到 Windows 上，同時使用 Windows 版（閹割版）的 CoreFoundation 庫。

儘管 Windows 版 Safari 現在掛了 。

此外，還有許多其他的”port”（檢視全部的列表）。Google 建立了一個持續維護的 Chromium port。還有，這是基於 GTK + 的 WebKitGtk。Nokia（通過它收購的 Trolltech 公司）維護 Qt 的 WebKit 移植版本，一般叫做QtWebKit 模組。（譯者注：後來又便宜賣了，現在 Qt 屬於 Digia 公司）

一些 WebKit port

• Safari
  • OS X 版和 Windows 版的 Safari 是兩個不同的 port
  • 用於 Safari 的 WebKit nightly 將會慢慢成為一個邊緣化的版本……
• Mobile Safari
  • 一開始在內部的私有分支上維護，不過最近程式碼也合併回主幹（being upstreamed）。（譯者注：upstream 是開源專案的術語，指其它人或者公司從主幹程式碼開出來的私有分支的程式碼重新提交回主幹）
  • iOS 版的 Chrome（使用 Apple 的 WebView；後面有更多關於它的不同之處）
• Chrome (Chromium)
  • 安卓版 Chrome （直接使用 Chromium port）
  • Chromium 也驅動 Yandex 瀏覽器 ，360 瀏覽器 ，搜狗瀏覽器 （譯者注：其實國內的殼瀏覽器太多了，你懂的）等，以及將來的 Opera。
• Android 瀏覽器
  • 使用目前最新的 WebKit 程式碼
• 還有很多 port ：Amazon Silk（亞馬遜 Silk 瀏覽器）， Dolphin（海豚瀏覽器），Blackberry（黑莓瀏覽器），QtWebKit，WebKitGTK+，EFL port (Tizen)，wxWebKit，WebKitWinCE 等等。

不同的 port 可以有不同的側重點。Mac port 關注的是瀏覽器核心和作業系統相關的實現部分的分離，它通過 Obj-C 和 C++ 程式碼把（WebKit）渲染引擎嵌入到本地應用中。 Chromium 則更多關注瀏覽器本身。而 QtWebKit 則把它的 WebKit 實現作為一個執行時的庫或者渲染引擎，同其跨平臺 GUI 應用程式框架一起提供給其它應用使用。

哪些是所有 WebKit 瀏覽器所共享的？

首先，讓我們回顧一下所有 WebKit port 的共同點。

這很有趣，我試著寫了幾次。每次都會被 Chrome 團隊成員斧正，正如你將會看到的……

1. 首先，WebKit 以同樣的方式解析 HTML 。好吧，除了 Chromium，它是迄今為止唯一支援 threaded HTML 解析的 port（譯者注：Last week in WebKit: Threaded HTML parser and background blending）。

2.然而一經解析，DOM 樹構造依然相同。所以，實際上只有在 Chromium port 中 Shadow DOM 被開啟的情況下， DOM 結構才會改變。當然這同樣適用於自定義元素。

3. WebKit 都會建立了一個 window 物件和 document 物件。使得通過它暴露出來的屬性和構造器（譯者注：某種函式）可以在 feature flags 選擇開啟。

4.CSS解析基本是一樣的，把你的 CSS 檔案解析成（內部的）CSS 物件模式還是一個比較標準的過程。是的，儘管 Chrome 僅接受 -webkit- 字首，然而 Apple 和其它的 port 接受遺留字首像 -khtml- 和 -apple-。

5.排版，定位？好吧，也來點麵包和黃油吧！Sub-pixel layout 和 saturated layout （譯者注：已經新增連結）演算法是 WebKit 的一部分，但是各 port 之間存在差異。

6. 好極了。

所以，事情很複雜。

就像 Flickr  和 Github 通過 flags 標識實現特性，WebKit 也是這麼做的。允許 port 通過 WebKit 的編譯特性標識 ， 啟用或禁用各種功能。這些特性可以作為執行時標識被暴露，也可以通過命令列開關（Chromium 是這樣）  ，或者通過配置 about:flags 。

好吧，讓我們重新歸納下各 WebKit 的共同點……

WebKit port 的共同點

• DOM，window, document
  • 大致相同
• CSSOM
• CSS 解析，屬性/值處理
  • 無供應商字首處理
• HTML 解析和 DOM 結構
  • 如果我們只考慮 Web 元件，它是相同的
• 所有的佈局和定位
  • Flexbox，浮動，塊級格式化上下文… 所有這些是共享的
• Chrome DevTools （ WebKit Inspector） 的 UI 和各種工具
  • 儘管去年4月以來，Safari 為 Safari Inspector 放棄了自有的非 Webkit 的閉源 UI
• contenteditable， pushState，File API，大部分的 SVG，CSS Transform 公式， Web Audio API，localStorage
  • 特性儘管後端不同。每一個 port 的 localStorage 可能使用不同的儲存層，Web Audio API 可能使用不同的 audio API
• 大量其它的特性和功能

哪些是 WebKit port 不共享的

• 執行在 GPU 上的
  • 3D變換
  • WebGL
  • 視訊解碼
• 螢幕上的 2D 繪圖
  • 抗鋸齒方法
  • SVG & CSS 漸變渲染
• 文字渲染&斷字
• 網路堆疊（SPDY，預渲染，WebSocket 傳輸）
• JavaScript 引擎
  • JavaScriptCore 在 WebKit repo. 它和 V8 繫結在 WebKit 裡
• 表單控制元件渲染
• <video> & <audio> 元素行為（以及編解碼器支援）
• 影像解碼
• 導航 前進/後退
  • pushState() 的導航部分
• SSL 特性像嚴格傳輸安全性（Strict Transport Security）和公鑰

看下面這些： 2D 圖形方面依賴於不同的 port ，我們用完全不同的庫把它繪製到螢幕上：

或者更微觀一點，最近的新特性：CSS.supports()  除了 win 和 wincairo， 所有的 port 都可用 ，同時它們沒有啟用 css3 conditional （css3 特性檢測）特性。

既然我們瞭解了這些，是時候更加深入一些了。事實上以上的敘述是不正確的。 WebCore 是共享的，WebCore 是一個針對 HTML 和 SVG 的排版、渲染和文件物件模型（DOM）的庫，它就是人們通常所說的 WebKit 。實際上“WebKit ”是 WebCore 和 port 的繫結層，儘管在扯淡時這種區別是不重要的。

下圖應該有所幫助：

WebKit 裡面許多的元件是可交換的（上圖灰色區域）。

舉個例子，起初，WebKit 的預設 JavaScript 引擎是 JavaScriptCore 。（它基於最初的 KJS （源於 KDE），WebKit 開始只是 KHTML 的一個 fork 分支）。後來，Chromium port 替換為 V8，然後使用獨立的 DOM 繫結機制對映上去就完事了。

字型和文字渲染佔一個平臺的很大一部分。WebKit  有2個單獨的文字路徑：快速（Fast）和複雜（Complex）。兩者都需要平臺特定（port-side）的支援，但快速僅需要知道如何 blit glyphs （傳輸符號）（WebKit  為平臺做了快取），複雜確實需要轉換整個字串到平臺層然後說“請繪製這個”。

WebKit  像一個三明治。儘管在 Chromium  中更像墨西哥玉米卷。一個美味的 web 平臺玉米卷。”——Dimitri Glazkov，Chrome WebKit hacker，Web 元件和 Shadow DOM 的擁護者。

現在，讓我們放大鏡頭看看一些 port 和一些子系統。下面是 WebKit  的5個 port；儘管它們共享WebCore 的大部分，但它們的 stacks 是不同的。

* iOS 版 Chrome 註解：你可能知道它使用 UIWebView，由於 UIWebView 的能力意味著它只能使用像移動版 Safari 那樣的渲染層，JavaScriptCore （替代 V8），單程式模式。儘管如此，大量的 Chromium 程式碼起銜接作用 ，例如網路層，同步和書籤基礎設施，位址列，度量和崩潰報告。（同時，更重要的是，JavaScript 很少成為移動端的瓶頸，缺乏 JIT 編譯器（譯者注：詳細資料）只有很小的影響。）

好吧，那麼我們該怎麼辦？ 現在所有 WebKit 完全不同了，我弱弱的表示害怕。

沒必要！WebKit  的 layoutTests 覆蓋面非常廣（最新統計是28,000  個 layoutTests），不僅針對已存在的特性，而且針對任何發現的迴歸。實際上，每當你探索一些新的或難懂的 DOM/CSS/HTML5 特性時，layoutTests 常常已經有了奇妙的最小化的示例。

此外，W3C 正在努力研究一致性測試套件 。這意味著我們可以期待不同的 WebKit port 和所有瀏覽器使用同樣的測試套件測試，帶來更少的怪癖模式和更彼此協作的網路。所有參加過 Test The Web Forward 大會（譯者注：比如去年在北京的分會場） 為此做出努力的人們，謝謝你們。

Opera 剛剛轉移到 WebKit了。有何影響呢？

Robert Nyman 和 Rob Hawkes 也談到了這個 ，但是我將補充一些：Opera 公告的一個明顯的部分是 Opera 將採用 Chromium。這意味著 WebGL，Canvas，HTML5 表單，2D 影像實現——所有這些 Chrome 和 Opera 將保持一致。同樣的 APIs，同樣的後端實現。由於 Opera 是基於 Chromium，你可以深感自信，你未來的工作可以同時相容 Chrome 和 Opera 。

我也應該指出所有的 Opera 瀏覽器 將採用 Chromium。因此 Windows，Mac 和 Linux 版 Opera，以及 Opera Mobile（完全成熟的移動瀏覽器）。甚至 Opera  Mini 輕客戶端，將使用基於 Chromium 的渲染替換當前的基於 Presto 的伺服器端渲染。

WebKit Nightly，是什麼？

它是 WebKit 的一個 mac port ，內部執行跟 Safari 一樣的二進位制檔案（儘管會替換一些底層庫）。因此它的行為和特性跟 Safari 全一樣。如果你想回到從前，可以考慮它……總之，WebKit Nightly 面向 Safari ， Chromium 面向 Chrome 。 Chrome Canary 包含最進一兩天之內的 WebKit 資源。

告訴我更多 WebKit 的內幕。

你已經得到了，同學。