Webkit入門開胃菜
對于許多開發者而言，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 的內幕。
你已經得到了，同學。
【關于本文】本文涉及到非常多的專業術語，為了讓大家第一時間更好的品嘗這道大菜，一絲特別邀請了幾位 Webkit 專業開發人士作為本文的翻譯顧問，在此表示由衷的感謝！翻譯不當之處，歡迎批評指正。
