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