Web开发者应该了解的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 　　Safari的OS X版本和Windows版本是两个不同的移植版本。 　　WebKitnightly是基于Safari的Mac OS版本的。稍后详述…… 　　• Mobile Safari 　　是专属维护的分支，但随后就成了主流版本。 　　Chrome on iOS(使用的是Apple提供的 WebView，随后会说明它们的不同部分) 　　• Chrome (Chromium) 　　Chrome onAndroid (直接使用Chromiumport) 　　Yandex Browser, 360 Browser, Sogou Browser使用Chromium,还有Opera。 　　• Android Browser 　　紧跟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处理 　　sans vendorprefix handling 　　• HTML parsing and DOM construction 　　same if wesuspended belief in Web Components 　　• 排版与定位 　　Flexbox,Floats, block formatting contexts… all shared 　　• Chrome开发工具,也称为WebKit Inspector. 　　• 去年四月开始，Safari开始使用自己的Safari Inspector. 　　部分功能，如Content Editable, Push State, File API,大部分SVG API, CSS Transform math, Web Audio API, Local Storage 　　• 后台(backend)并不相同.比如不同的port会为local storage和Web Audio API使用不同的实现方法。 　　• 其它一些功能和特性 　　WebKit ports不同的部分 　　• GPU的运用 　　3D Transforms 　　WebGL 　　Video解码(decoding) 　　• 2D绘制 　　Anti-aliasing方法 　　SVG & CSS梯度渲染(gradientrendering) 　　• 文本渲染和断字处理(rendering & hyphenation) 　　• Network stack (SPDY,预读(pre-rendering), WebSocket transport) 　　• JavaScript引擎 　　WebKit中的JSC(也支持V8)，以及Chrome中的V8。 　　• 表格(forms)的渲染 　　• 音频和视频元素的行为 (包括codec的支持) 　　• 图片解码(Image decoding) 　　• 导航(Navigating back/forward) 　　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。 　　字体和文字的渲染也严重依赖于平台。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的块图，了解一下它们之间的异同。 　　注意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通常已经提供了一个简化版的演示。 　　另外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保持像是一天内的代码同步。

发布日期：2013年3月8日