基于WebKit的浏览器？先了解WebKit Port

虽然现在我们已经有了很多基于 Webkit 的浏览器了，特别是有消息称 Opera 也已经转移到 WebKit 了，但是想要理解他们的相同点和不同点还是挺难的。下面我将侧重讲这方面，你将能更好的分辨浏览器的差异，在合适的 bug 跟踪系统提交 bug，并了解如何更加高效的针对特定的浏览器进行开发。

标准的 Web 浏览器组件

在 现代浏览器的组成与结构 这篇里面我们已经谈过了一下，这里再复述一遍吧。

让我们看一下现代 web 浏览器的几个组件：

解析（HTML, XML, CSS, JavaScript）

排版（Layout）

文字和图像渲染

图像解码

GPU 交互

网络接入

硬件加速

那么哪些是基于 WebKit 的浏览器所共享的呢？ 几乎只有前两项。

其它的由各自的 WebKit port 负责。让我们回顾下这意味着什么？ WebKit Port 虽然 Webkit 有不同的 ”port”，引用来自 Sencha 的 WebKit hacker 兼 eng 主管— Ariya Hidayat 解释一下 ：

WebKit 最常见的参考实现是 Apple 自己的运行在 Mac OS X 上的WebKit 实现（这也是最早最原始的 WebKit 库）。正如你所知，在 Mac OS X 上各种接口的实现使用不同的本地库，大多集中在 CoreFoundation 。比如，你定义了一个带有特别的圆角的平面彩色按钮，那么 WebKit 会知道在哪里以及如何画绘制这个按钮。可是，最终实际画绘制按钮的职责（作为用户显示器上的像素）还是落到了 CoreGraphics 身上。

如上所述，只有 Apple 自己在 Mac 上的实现是使用 CG。Chrome 在 Mac 上的实现使用的是 Skia。

随着时间推移，WebKit 被移植到不同的平台，包括桌面和移动端。这种做法通常被称作“一个 WebKit port”。对于 Safari 浏览器的 Windows 版本，Apple 也把自己的 WebKit 移植到 Windows 上，同时使用 Windows 版（阉割版）的 CoreFoundation 库。

尽管 Windows 版 Safari 现在挂了 。

此外，还有许多其他的”port”（查看全部的列表）。Google 创建了一个持续维护的 Chromium port。还有，这是基于 GTK + 的 WebKitGtk。Nokia（通过它收购的 Trolltech 公司）维护 Qt 的 WebKit 移植版本，一般叫做QtWebKit 模块。（译者注：后来又便宜卖了，现在 Qt 属于 Digia 公司）

WebKit Port是什么

所谓一个WebKit Port，并没有确切的形式，可以看作是OS，平台（应用程序框架），JS引擎，以及各种第三方库的一个组合。比如WinCairo Port，就是OS=Windows，GraphicsLib=Cairo的一个Porting。Qt Port是一个跨平台的Port，Qt本身是跨平台的，所以WebKit对OS的依赖性就依靠Qt本身来解决。

WebKit Port通常处于以下几种目的：

使用WebKit作为浏览器（或者类似的User Agent）的页面解析，排版和渲染的核心，如Safari，Chrome

对WebKit进行封装，对外提供构建一个浏览器（或者类似的UA）的API接口，如Qt

以上两者皆有，如Android，iOS，BlackBerry

对于一个WebKit Port，必须提供的部分包括：

Threading：线程支持

Timer：计时器支持

File System：文件系统

Network：网络（网络甚至都不一定是需要的，如果Port不支持网络请求，而是只支持从文件系统读取的话…）

Graphics Engine/Drawing Surface：绘图引擎/绘图表层

Theme：页面内的各种输入组件的绘制（滚动条，按钮，输入框等），交由外部绘制的原因是它们通常需要符合相应的平台的感观（Look&Feel）

这里很重要的一点在于，WebCore本身并不一定需要一个窗口环境才能运作：

它需要一个绘图表层来绘制页面，但是并不关心这个绘图表层是来自于一个Widget还是一个离屏位图，是否需要和如何将最后的页面显示输出到一个Widget上面是Port自己的事情。

WebCore中的页面可以接收各种各样的输入事件，它处理这些事件和其它因为JS产生的事件，根据处理的结果更新自己的显示，如果产生一些进阶的事件需要外部进行处理，这时就会调用Port提供的相应的回调接口交由Port来处理。但是这些输入事件可以来源于用户真正的输入，然后通过外部的窗口环境转发给页面，但也可能是模拟的事件，WebCore本身并不关心这一点。

简单的说，WebCore本身对外定义了一个干净，清晰的接收输入事件，输出页面显示的接口，并且定义了各种事件的回调接口，Port可以对输入/输出接口进行适配，并且根据自己的需要实现相应的回调接口，来达成WebCore跟窗口环境的整合，所以对于一个WebKit Port，以下是可选的部分：

将平台产生的输入事件转发给页面处理

将页面的显示输出一个Widget的Surface上面

处理输入/输出过程中产生的一些事件的回调，和其它各种各样的回调，比如网络请求和响应的处理，弹出对话框，创建新窗口等等

插件的创建和绘制

提供自己的API封装

WebCore的这种架构引入了很多抽象层，带来额外的系统复杂性，但是获得了对各种不同平台，不同的窗口环境，不同的系统架构支持的灵活性，这也是它成功的主要原因。

一些 WebKit port

1. Safari

OS X 版和 Windows 版的 Safari 是两个不同的 port

用于 Safari 的 WebKit nightly 将会慢慢成为一个边缘化的版本……

2. Mobile Safari

一开始在内部的私有分支上维护，不过最近代码也合并回主干（being upstreamed）。（译者注：upstream 是开源项目的术语，指其它人或者公司从主干代码开出来的私有分支的代码重新提交回主干）

iOS 版的 Chrome（使用 Apple 的 WebView；后面有更多关于它的不同之处）

3. Chrome (Chromium)

安卓版 Chrome （直接使用 Chromium port）

Chromium 也驱动 Yandex 浏览器 ，360 浏览器 ，搜狗浏览器 （译者注：其实国内的壳浏览器太多了，你懂的）等，以及将来的 Opera。

4. Android 浏览器。使用目前最新的 WebKit 代码。

还有很多 port ：Amazon Silk（亚马逊 Silk 浏览器）， Dolphin（海豚浏览器），Blackberry（黑莓浏览器），QtWebKit，WebKitGTK+，EFL port (Tizen)，wxWebKit，WebKitWinCE 等等。

不同的 port 可以有不同的侧重点。Mac port 关注的是浏览器内核和操作系统相关的实现部分的分离，它通过 Obj-C 和 C++ 代码把（WebKit）渲染引擎嵌入到本地应用中。 ​Chromium 则更多关注浏览器本身。而 QtWebKit 则把它的 WebKit 实现作为一个运行时的库或者渲染引擎，同其跨平台 GUI 应用程序框架一起提供给其它应用使用​。​​