開發者須要瞭解的WebKit

2013-3-22 22:37| 發佈者: sxwgf| 查看: 575| 評論: 0|來自: infoq

摘要: Paul Irish是著名的前端開發工程師，同時他也是Chrome開發者關係團隊成員，jQuery團隊成員，Modernizr、 Yeoman、CSS3 Please和HTML5 Boilerplate的lead developer。針對你們對WebKit的種種誤解，他在本身的博客發表 ...

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、WebKitWinCE…… 不一樣的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資源。