WebKit 粗解

对一些开发者而言，WebKit就是一个黑盒子。丢进去HTML、CSS、JS等一连串的东西，而WebKit就能变魔术一般显示出一个很棒的网页出来。实际上，正我的同事IlyaGroriks提到的:

WebKit不但是白盒，而且是一个开放的白盒。

让我们花点时间来理解以下这些问题:

什么是WebKit?
什么不是WebKit?
浏览器是如何使用WebKit的?
为什么WebKit分支各不相同?

最近连Opera都转到WebKit平台上。下面的内容可以让你能够识别浏览器间的差异，去到合适的tracker上报Bug, 同时可以了解如何更有效的在各个浏览器上开发。

标准的浏览器组件

以下是现代浏览器的一些组件:

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

· 排版(Layout)

· 渲染(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提供的渲染功能。