開發者應當瞭解的WebKit知識

時間 2019-11-20

標籤開發者應當瞭解 webkit 知識欄目職業生涯简体版

原文原文鏈接

http://blog.csdn.net/horkychen/article/details/8629976javascript

對一些開發者而言，WebKit就是一個黑盒子。丟進去HTML、CSS、JS等一連串的東西，而WebKit就能變魔術通常顯示出一個很棒的網頁出來。實際上，正個人同事IlyaGroriks提到的:css

WebKit不可是白盒，並且是一個開放的白盒。html

讓咱們花點時間來理解如下這些問題:html5

什麼是WebKit?
什麼不是WebKit?
瀏覽器是如何使用WebKit的?
爲何WebKit分支各不相同?java

最近連Opera都轉到WebKit平臺上。下面的內容可讓你可以識別瀏覽器間的差別，去到合適的tracker上報Bug, 同時能夠了解如何更有效的在各個瀏覽器上開發。android

標準的瀏覽器組件

如下是現代瀏覽器的一些組件:ios

· 解析(Parsing) (HTML, XML, CSS, JavaScript)css3

· 排版(Layout)web

· 渲染(Text and graphics rendering)算法

· 圖片解碼(Image decoding)

· 圖形加速(GPU interaction)

· 網絡訪問(Network access)

· 硬件加速(Hardware acceleration)

只有前兩項是被全部WebKit瀏覽器所共享的。其它的部分由不一樣的WebKit ports來實現。什麼意思?

WebKit的移植版本(Ports)

如今有不少WebKit的移植版本，先看一下WebKit hacker（也是Sencha的Director）Ariya Hidayat的解釋:

WebKit最爲公認的參考是Apple本身運行在Mac OS X上的分支,也是最初和原裝的WebKit庫。在Mac OS X上不，圍繞着CoreFundation等不一樣的原生系統庫實現出了不一樣的接口。好比讓WebKit之因此知道如何繪製出一個帶有圓角的flat button,其實最終是由CoreGraphics負責的。

在Mac移值版本上使用的是CoreGraphics(CG)，Mac上的Chrome則使用的是Skia。

WebKit不斷地被移植到不一樣的平臺上，包括桌面版本和Mobile版本,它們一般被稱爲一今後WebKit port。Apple本身也基於CoreFoundation庫的Windows版本移植了一份Windows版本的WebKit。

…不過Windows版的Safari已經死去.

除此以外，還有許多其它的ports (完整列表)。Google建立並維護着Chromium port。還有基於Gtk+的WebKitGtk。Nokia (其實是Trolltech)維護着Qt port,就是知名的QtWebKitmodule.

WebKit ports介紹

· Safari

o Safari的OS X版本和Windows版本是兩個不一樣的移植版本。

o WebKitnightly是基於Safari的Mac OS版本的。稍後詳述……

· Mobile Safari

o 是專屬維護的分支，但隨後就成了主流版本。

o Chrome on iOS(使用的是Apple提供的 WebView，隨後會說明它們的不一樣部分)

· Chrome (Chromium)

o Chrome onAndroid (直接使用Chromiumport)

o Yandex Browser, 360 Browser, Sogou Browser使用Chromium,還有Opera.

· Android Browser

o 緊跟WebKit的最新版本。

· 更多的移值版本: Amazon Silk, Dolphin, Blackberry, QtWebKit,WebKitGTK+, EFL port (Tizen), wxWebKit, WebKitWinCE等。

不一樣port的關注不一樣。Mac port關於於將瀏覽器從系統中分離，引入Obj-C和C++的綁定(binding)以方便在應用中使用WebKit渲染引擎。Chromium則純粹關注於瀏覽器。QtWebKit則爲其跨平臺應用提供運行時或渲染引擎。

WebKit瀏覽器的共性

全部WebKit ports的共性包括如下部分。(這段做者寫了屢次，每次都有Chrome工程加以糾正，各項後面的斜體部分。)

1. WebKit用相同的方式解析HTML。目前只有Chromium支持了多線程的HTML解析(threaded HTMLparsing) .

2. 使用相同的方式構建DOM Tree. 實際上只有Chromium支持Shadow DOM。

3. WebKit都會建立一個window 對象和document 對象。 不過可用的屬性和建構函數能夠經過功能選項來控制。

4. CSS解析。儘管如此，仍是應當讓你的CSS遵循CSSOM標準。 Chrome接受-webkit-前綴，相對的Apple和其它ports則接受-khtml-或 –apple-前綴.

5. 排版(Layout)和定位(positioning)。 WebKit包括了Sub-pixel排版和對比排版(saturated layout) 算法但每一個port的實現是不一樣的。

6. 基礎是相同的。

就像Flickr和Github透過flags來指定實現的功能，WebKit容許經過指定編譯期功能選項(WebKit’scompile-time Feature Flags)來啓用和禁用一系列的功能。還有運行時標誌來管理一些功能，經過命令行（command lineswitches (Chromium’s here) 或配置的方式(如about:flags)指定。

WebKit port共性列表

· DOM, window, document

· CSSOM

· CSS解析, property/value處理

o sans vendorprefix handling

· HTML parsing and DOM construction

o same if wesuspended belief in Web Components

· 排版與定位

o Flexbox,Floats, block formatting contexts… all shared

· Chrome開發工具,也稱爲WebKit Inspector.

o 去年四月開始，Safari開始使用本身的Safari Inspector.

· 部分功能，如Content Editable, Push State, File API,大部分SVG API, CSS Transform math, Web Audio API, Local Storage

o 後臺(backend)並不相同.好比不一樣的port會爲local storage和Web Audio API使用不一樣的實現方法。

· 其它一些功能和特性

WebKit ports不一樣的部分

· GPU的運用

o 3D Transforms

o WebGL

o Video解碼(decoding)

· 2D繪製

o Anti-aliasing方法

o SVG & CSS梯度渲染(gradientrendering)

· 文本渲染和斷字處理(rendering & hyphenation)

· Network stack (SPDY,預讀(pre-rendering), WebSocket transport)

· JavaScript引擎

o WebKit中的JSC(也支持V8)，以及Chrome中的V8。

· 表格(forms)的渲染

· 音頻和視頻元素的行爲 (包括codec的支持)

· 圖片解碼(Image decoding)

· 導航(Navigating back/forward)

o pushState()的導航部分

· SSL特性(Strict Transport Security和Public Key Pins)

下圖是2D graphics 在不一樣port中的依賴關係，幾乎是各自使用了徹底不一樣的庫來實現繪製操做:

舉一個更細節的例子，一個剛被引入的特性CSS.supports()只有win和wincairo兩個移植版本沒有支持,由於它們並無啓用CSS3特性。

簡單地說共享的組件就是WebCore。它其實就是一般意義上你們所說的WebKit，一個排版、渲染引擎，同時是HTML和SVG解析庫。而WebKit是WebCore與ports之間的綁定層(bindinglayer)，平時的交流並不太在乎它。

以下圖所示:

WebKit中的許多元件是能夠替換的 (上圖中的灰色部分)。

好比WebKit的默認JavaScript引擎JSC(JavaScriptCore,當由KHTML開始建立WebKit的同時基於KDE的KJS實現而來),在Chromium port由V8替換，並用獨特的DOM bindings。(關於DOM Binding能夠參考這裏。)

字體和文字的渲染也嚴重依賴於平臺。WebKit中有兩種不一樣Text Path: Fast and Complex。每一項都須要平臺(port-side)支持。Fast只須要知道如何貼上位圖輪廓(blit glyphs)就能夠了，WebKit會爲平臺準備數據。而Complex則徹底依賴於平臺去處理，它僅僅請求:」請畫出這個」。

「WebKit就像一個三明治，而 Chromium更像一個墨西哥玉米卷(taco)。」 Dimitri Glazkov, ChromeWebKit hacker. Web Components和Shadow DOM的擁護者。

(爲何是taco,看這裏就能夠了.)

下表中列出了5個WebKit port的塊圖，瞭解一下它們之間的異同。

-	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，所以它只能使用和Mobile Safari同樣的渲染引擎(rendering layers)，以及JavaScriptCore和單進程模型(single-process model)。固然 Chromium仍是有它的應用的，諸如網絡層(network layer),同步和書籤的基礎組件(sync and bookmarks infrastructure), Omnibox,metrics及崩潰報告(crashreporting). (之所值得這樣作，是由於 JavaScript不多會成爲移動端的瓶頸，而帶有JIT的編譯器的影響也會很小。)

WebKit瀏覽器間差別之大，何去何從？

大可沒必要！WebKit中提供了LayoutTest提供了大量的測試用例(28,000),不但針對已存在的功能，還包括迴歸測試。事實上，不管你什麼時候發現了一些新奇的DOM/CSS/HTML5特性，LayoutTest一般已經提供了一個簡化版的演示。(參考:深刻分析LayoutTest)

另外W3C也正增長其在頁面一致性測試上的投入。這表示不一樣的WebKit ports和全部瀏覽器會針對相同的頁面進行測試，將帶來更少的私有特性(quirks)和更多能夠共同操做的頁面。

Opera將如何轉換？

Robert Nyman和Rob Hawkes都分析過了,但值得注意的是Opera會採用Chromium。這表示WebGL, Canvas, Html5 forms, 2D graphics等實現會和Chrome同樣。相同的APIst和相同的後臺(backends)實現。因此Opera是Chromium-based, Opera與Chrome會保持同步兼容。

而且全部Opera瀏覽器都會採用Chromium,甚至包括Opera Mini，會將本來Presto實現的在服務器端的渲染方式放棄，轉而使用Chromium提供的渲染功能。