对一些开发者而言，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提供的渲染功能。
什么是WebKit Nightly？
它是WebKit的Mac Port，和Safari内部运行的版本是一致的(除了一小部分的基础库会被替换掉)。所以它的行为和功能是和Safari一致的。你也可以这样理解WebKit Nightly就是Safari,而Chromium就是Chrome。
Chrome Canary 也会与WebKit保持像是一天内的代码同步。