开发者应当了解的WebKit知识

2013-5-20 15:27| 发布者: 红黑魂| 查看: 10501| 评论: 2|来自: CSDN

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

简单地说共享的组件就是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会保持同步兼容。