Paul Irish是著名的前端開發(fā)工程師，同時他也是Chrome開發(fā)者關(guān)系團(tuán)隊成員，jQuery團(tuán)隊成員，Modernizr、 Yeoman、CSS3 Please和HTML5 Boilerplate的lead developer。針對大家對WebKit的種種誤解，他在自己的博客發(fā)表了《WebKit for Developers》一文，試圖為大家解惑。
對許多開發(fā)者來說，WebKit就像一個黑盒。我們把HTML、CSS、JS和其他一大堆東西丟進(jìn)去，然后WebKit魔法般的以某種方式把一個看起來不錯的網(wǎng)頁展現(xiàn)給我們。但事實上，Paul的同事Ilya Grigorik說：
WebKit才不是個黑盒。它是個白盒。并且，它是個打開的白盒。
所以讓我們來花些時間了解這些事兒：
什么是WebKit？
什么不是WebKit？
基于WebKit的瀏覽器是如何使用WebKit的？
為什么又有不同的WebKit？
現(xiàn)在，特別是Opera宣布將瀏覽器引擎轉(zhuǎn)換為WebKit之后，我們有很多使用WebKit的瀏覽器，但是我們很難去界定它們有哪些相同與不同。下面我爭取為這個謎團(tuán)做些解讀。而你也將會更懂得判斷瀏覽器的不同，了解如何在正確的地方報告bug，還會了解如何在特定瀏覽器下高效開發(fā)。（web前端學(xué)習(xí)交流群：328058344 禁止閑聊，非喜勿進(jìn)?。?/p>
標(biāo)準(zhǔn)Web瀏覽器組件
讓我們列舉一些現(xiàn)代瀏覽器的組件：
HTML、XML、CSS、JavsScript解析器
Layout
文字和圖形渲染
圖像解碼
GPU交互
網(wǎng)絡(luò)訪問
硬件加速
這里面哪些是WebKit瀏覽器共享的？差不多只有前兩個。其他部分每個WebKit都有各自的實現(xiàn)，所謂的“port”?，F(xiàn)在讓我們了解一下這是什么意思……
WebKit Ports是什么？
在WebKit中有不同的“port”，但是這里允許我來讓W(xué)ebKit hacker，Sencha的工程主管Ariya Hidayat來解釋：
WebKit最常見的參考實現(xiàn)是Apple在Mac OS X上的實現(xiàn)（這也是最早和最原始的WebKit庫）。但是你也能猜到，在Mac OS X下，許多不同的接口在很多不同的原生庫下被實現(xiàn)，大部分集中在CoreFoundation。舉例來說，如果你定義了一個純色圓角的按鈕，WebKit知道要去哪里，也知道要如何去繪制這個按鈕。但是，繪制按鈕的工作最終還是會落到CoreGraphics去。
上面已經(jīng)提到，CoreGraphics只是Mac port的實現(xiàn)。不過Mac Chrome用的是Skia。
隨時間推移，WebKit被“port”（移植）到了各個不同的平臺，包括桌面端和移動端。這種做法被稱作“WebKit port”。對Windows版Safari來說，Apple通過（有限實現(xiàn)的）Windows版本CoreFoundation 來port WebKit。
……不過Windows版本的Safari現(xiàn)在已經(jīng)死掉了。
除此之外，還有很多很多其它的“port”（參見列表）。Google創(chuàng)建并維護(hù)著它的Chromium port。這其實也是一個基于Gtk+的WebKitGtk。諾基亞通過收購Trolltech，維護(hù)著以QtWebKit module而聞名的WebKit Qt port。
讓我們看看其中一些WebKit ports：
SafariOS X Safari和Windows Safari使用的是不同的port
用于OS X Safari的WebKit Nightly以后會漸漸成為一個邊緣版本
Mobile Safari在一個私有代碼分支上維護(hù)，不過代碼現(xiàn)在正在合并到主干
iOS Chrome（使用了Apple的WebView，不過后面的部分有很多不同）
Chrome（Chromium）安卓Chrome（直接使用Chromium port）
Chromium也驅(qū)動了Yandex Browser、 360 Browser、Sogou Browser，很快，還會有Opera。
還有很多： Amazon Silk、Dolphin、Blackberry、QtWebKit、WebKitGTK+、The EFL port (Tizen)、wxWebKit、WebKitWinCE……
不同的port專注于不同的領(lǐng)域。Mac的port注意力集中在瀏覽器和操作系統(tǒng)的分割上，允許把ObjectC和C++綁定并嵌入原生應(yīng)用的渲染。Chromium專注在瀏覽器上。QtWebKit的port在他的跨平臺GUI應(yīng)用架構(gòu)上給apps提供運行時環(huán)境或者渲染引擎。
WebKit瀏覽器共享了那些東西？
首先，讓我們來看看這些WebKit ports的共同之處：
?。ㄗ髡咦ⅲ汉苡幸馑?，這些內(nèi)容我寫了很多次，每次Chrome團(tuán)隊成員都給我糾正錯誤，正如你看到的……）
“WebKit在使用相同的方式解析WebKit?！薄獙嶋H上，Chrome是唯一支持多線程HTML解析的port。
“一旦解析完成，DOM樹也會構(gòu)建成相同的樣子?！薄獙嶋H上Shadow DOM只有在Chromium才被開啟。所以DOM的構(gòu)造也是不同的。自定義元素也是如此。
“WebKit為每個人創(chuàng)建了‘window’對象和‘document’對象。”——是的，盡管它暴露出的屬性和構(gòu)造函數(shù)可以通過feature flags來控制。
“CSS解析都是相同的。將CSS解析為對象模型是個相當(dāng)標(biāo)準(zhǔn)的過程?！薄贿^，Chrome只支持-webkit-前綴，而Apple和其他的ports支持遺留的-khtml-和-apple-前綴。
“布局定位？這些是基本生計問題啊”—— 盡管Sub-pixel layout和saturated layout算法是WebKit的一部分，不過各個port的實現(xiàn)效果還是有很多不同。
所以，情況很復(fù)雜。
就像Flickr和GitHub通過flag標(biāo)識來實現(xiàn)自己的功能一樣，WebKit也有相同處理。這允許各個port自行決定是否啟用WebKit編譯特性標(biāo)簽的各種功能。通過命令行開關(guān)，或者通過about:flags還可以控制是否通過運行時標(biāo)識來展示功能特性。
好，現(xiàn)在讓我們再嘗試一次搞清楚WebKit究竟有哪些相同…
每個WebKit port有哪些共同之處
DOM、winow、document
CSS對象模型
CSS解析，鍵盤事件處理
HTML解析和DOM構(gòu)建
所有的布局和定位
Chrome開發(fā)工具和WebKit檢查器的UI與檢查器
contenteditable、pushState、文件API、大多數(shù)SVG、CSS Transform math、Web Audio API、localStorage等功能
很多其他功能與特性
這些領(lǐng)域現(xiàn)在有點兒模糊，讓我們嘗試把事情弄得更清楚一點。
什么是WebKit port們并沒有共享的：
GPU相關(guān)技術(shù)3D轉(zhuǎn)換
WebGL
視頻解碼
將2D圖像繪制到屏幕解析方式
SVG和CSS漸變繪制
文字繪制和斷字
網(wǎng)絡(luò)層（SPDY、預(yù)渲染、WebSocket傳輸）
JavaScript引擎JavaScriptCore 在WebKit repo中。V8和JavaScriptCore被綁定在WebKit中。
表單控制器的渲染
<video>和<audio>的元素表現(xiàn)和解碼實現(xiàn)
圖像解碼
頁面導(dǎo)航 前進(jìn)/后退pushState()的導(dǎo)航部分
SSL功能，比如Strict Transport Security和Public Key Pins
讓我們談?wù)勂渲械?D圖像部分： 根據(jù)port的不同，我們使用完全不同的庫來處理圖像到屏幕的繪制過程：
更宏觀一點來看，一個最近剛添加的功能：CSS.supports()在除了沒有css3特性檢測功能的win和wincairo這兩個port之外，在其它所有port中都可用。
現(xiàn)在到了賣弄學(xué)問的技術(shù)時間。上面講的內(nèi)容其實并不正確。事實上那是WebCore被共享的東西。而WebCore其實是當(dāng)大家討論HTML和SVG的布局、渲染和DOM處理時提到的WebKit。技術(shù)上講，WebKit是WebCore和各種ports之間的綁定層，盡管通常來說這個差別并不那么重要。
一個圖表應(yīng)該可以幫助大家理解：
WebKit中的許多組件都是可以更換的（圖中標(biāo)灰色的部分）。
舉個例子來說，Webkit的JavaScript引擎，JavaScriptCore，是WebKit的默認(rèn)組件。（它最初是當(dāng)WebKit從KHTML分支時從KJS演變來的）。同時，Chromium port用V8引擎做了替換，還使用了獨特的DOM綁定來映射上面的組件。
字體和文字渲染是平臺上的重要部分。在WebKit中有兩個獨立的文字路徑：Fast和Complex。這兩者都需要平臺特性的支持，但是Fast只需要知道如何傳輸字型，而Complex實際上需要掌握平臺上所有的字符串，并說“請繪制這個吧”。
"WebKit就像一個三明治。盡管Chromium的包裝更像是一個墨西哥卷。一個美味的Web平臺墨西哥卷。"
—— Dimitri Glazkov, Chrome WebKit hacker，Web Components和Shadow DOM擁護(hù)者。
現(xiàn)在，讓我們放寬鏡頭看看一些port和一些子系統(tǒng)。下面是WebKit的5個port；盡管它們共享了WebCore的大部分，但考慮一下它們的stack有哪些不同。
Chrome (OS X)
Safari (OS X)
QtWebKit
Android Browser
Chrome for iOS
Rendering
Skia
CoreGraphics
QtGui
Android stack/Skia
CoreGraphics
Networking
Chromium network stack
CFNetwork
QtNetwork
Fork of Chromium’s network stack
Chromium stack
Fonts
CoreText via Skia
CoreText
Qt internals
Android stack
CoreText
JavaScript
V8
JavaScriptCore
JSC (V8 is used elsewhere in Qt)
V8
JavaScriptCore (without JITting) *
iOS Chrome注：你可能知道它使用 UIWebView。由于UIWebView的能力限制。它只能使用移動版Safari的渲染層，JavaScriptCore（而不是V8）和單進(jìn)程模式。然而，大量的Chromium 代碼還是起到了調(diào)節(jié)作用 ，比如網(wǎng)絡(luò)層、同步、書簽架構(gòu)、地址欄、度量工具和崩潰報告。（同時，由于JavaScript很少成為移動端的瓶頸，缺少JIT編譯器只有很小的影響。）
好吧，那么我們該怎么辦？
現(xiàn)在所有WebKit完全不同了，我好怕。
別這樣！WebKit的layoutTests覆蓋面非常廣（據(jù)最新統(tǒng)計，有28,000個layoutTests），這些test不僅針對已存在的特性，而且針對任何發(fā)現(xiàn)的回歸。實際上，每當(dāng)你探索一些新的或難懂的DOM/CSS/HTML5特性時，在整個web平臺上，layoutTests經(jīng)常已經(jīng)有了一些奇妙的小demo。
另外，W3C正在努力研究一致性測試套件。這意味著我們可以期待使用同一個測試套件來測試不同的WebKit port和瀏覽器，以此來獲得更少的怪異模式，和一個帶來更少的怪癖模式和更具互操作性的web。
Opera剛剛遷移到了WebKit了。會怎樣？
Robert Nyman和 Rob Hawkes也談到了這個 ，但是我會再補充一些：Opera在公告中明顯指出Opera將采用Chromium*。這意味著WebGL，Canvas，HTML5 表單，2D圖像實現(xiàn)——Chrome和Opera將在所有這些功能上保持一致。API和后端實現(xiàn)也會完全相同。由于Opera是基于 Chromium，你可以有足夠的信心去相信你的尖端工作將會在Chrome和Opera上獲得兼容。
我還應(yīng)該指出，所有的Opera瀏覽器都將采用Chromium：包括他的Windows，Mac、Linux版本，和Opera Mobile（完全成熟的移動瀏覽器）。甚至Opera Mini都將使用基于Chromium的服務(wù)器渲染集群來替換當(dāng)前的基于Presto的服務(wù)器端渲染。
……那WebKit Nightly是什么？
它是WebKit的mac port ，和Safari運行的二進(jìn)制文件一樣（盡管會替換一些底層庫）。因為蘋果在項目中起主導(dǎo)地位，所以它的表現(xiàn)和功能與Safari的總是那么一致。在很多情況下，當(dāng)其它port可能會試驗新功能的時候，Apple卻顯得相對保守。不管怎樣，如果你想我用中學(xué)一樣的類比，想想這個好了：WebKit Nightly對于Safari就像Chromium對于Chrome。
同樣的，Chrome Canary 有著最新的WebKit資源。
告訴我更多的WebKit內(nèi)幕吧。
就在這兒了，小伙子：
