WebKit浏览器所共有的与不同的

让我们回顾一下所有 WebKit port 的共同点：

首先，WebKit 以同样的方式解析 HTML 。好吧，除了 Chromium，它是迄今为止唯一支持 threaded HTML 解析的 port。

然而一经解析，DOM 树构造依然相同。所以，实际上只有在 Chromium port 中 Shadow DOM 被打开的情况下， DOM 结构才会改变。当然这同样适用于自定义元素。

WebKit 都会创建了一个 window 对象和 document 对象。使得通过它暴露出来的属性和构造器（译者注：某种函数）可以在 feature flags 选择打开。

CSS解析基本是一样的，把你的 CSS 文件解析成（内部的）CSS 对象模式还是一个比较标准的过程。是的，尽管 Chrome 仅接受 -webkit- 前缀，然而 Apple 和其它的 port 接受遗留前缀像 -khtml- 和 -apple-。

排版，定位？好吧，也来点面包和黄油吧！Sub-pixel layout 和 saturated layout （译者注：已经添加链接）算法是 WebKit 的一部分，但是各 port 之间存在差异。

好极了（搞定了）。

所以，事情很复杂。

就像 Flickr  和 Github 通过 flags 标识实现特性，WebKit 也是这么做的。允许 port 通过 WebKit 的编译特性标识 ， 启用或禁用各种功能。这些特性可以作为运行时标识被暴露，也可以通过命令行开关（Chromium 是这样）  ，或者通过配置 about:flags 。

好吧，让我们重新归纳下各 WebKit 的共同点……

WebKit port 的共同点

DOM，window, document。大致相同。

CSSOM。

CSS 解析，属性/值处理。无供应商前缀处理。

HTML 解析和 DOM 结构。如果我们只考虑 Web 组件，它是相同的。

所有的布局和定位。Flexbox，浮动，块级格式化上下文… 所有这些都是共享的。

Chrome DevTools （ WebKit Inspector） 的 UI 和各种工具。尽管去年4月以来，Safari 为 Safari Inspector 放弃了自有的非 Webkit 的闭源 UI。

contenteditable， pushState，File API，大部分的 SVG，CSS Transform 公式， Web Audio API，localStorage。特性尽管后端不同。每一个 port 的 localStorage 可能使用不同的存储层，Web Audio API 可能使用不同的 audio API。

大量其它的特性和功能。

哪些是各 WebKit port 不同的

1. 运行在 GPU 上的

3D变换

WebGL

视频解码

2. 屏幕上的 2D 绘图

抗锯齿方法

SVG & CSS 渐变渲染

3. 文字渲染 & 断字

4. 网络堆栈（SPDY，预渲染，WebSocket 传输）

5. JavaScript 引擎。JavaScriptCore 在 WebKit repo. 它和 V8 绑定在 WebKit 里。

6. 表单控件渲染。

7. video & audio 元素行为（以及编解码器支持）。

8. 图像解码。

9. 导航 前进/后退。pushState() 的导航部分。

10. SSL 特性像严格传输安全性（Strict Transport Security）和公钥。

看下面这些： 2D 图形方面依赖于不同的 port ，我们用完全不同的库把它绘制到屏幕上：



或者更微观一点，最近的新特性：CSS.supports() 除了 win 和 wincairo， 所有的 port 都可用 ，同时它们没有启用 css3 conditional （css3 特性检测）特性。

既然我们了解了这些，是时候更加深入一些了。事实上以上的叙述是不正确的。 WebCore 是共享的，WebCore 是一个针对 HTML 和 SVG 的排版、渲染和文档对象模型（DOM）的库，它就是人们通常所说的 WebKit 。实际上“WebKit ”是 WebCore 和 port 的绑定层，尽管在扯淡时这种区别是不重要的。

下图应该有所帮助：



WebKit 里面许多的组件是可交换的（上图灰色区域）。

举个例子，起初，WebKit 的默认 JavaScript 引擎是 JavaScriptCore 。（它基于最初的 KJS （源于 KDE），WebKit 开始只是 KHTML 的一个 fork 分支）。后来，Chromium port 替换为 V8，然后使用独立的 DOM 绑定机制映射上去就完事了。

字体和文本渲染占一个平台的很大一部分。WebKit 有2个单独的文本路径：快速（Fast）和复杂（Complex）。两者都需要平台特定（port-side）的支持，但快速（Fast）仅需要知道如何 blit glyphs （传输字形）（WebKit 为平台做了缓存），而复杂（Complex）实际上是传递整个字符串到平台层，然后说“绘制这个吧”。

WebKit 像一个三明治。尽管在 Chromium 中更像墨西哥玉米卷。一个美味的 web 平台玉米卷。”——Dimitri Glazkov，Chrome WebKit hacker，Web 组件和 Shadow DOM 的拥护者。

现在，让我们放大镜头看看一些 port 和一些子系统。下面是 WebKit 的5个 port；尽管它们共享WebCore 的大部分，但它们的 stacks 是不同的。



PS：iOS 版 Chrome 注解：你可能知道它使用 UIWebView，由于 UIWebView 的能力意味着它只能使用像移动版 Safari 那样的渲染层，JavaScriptCore （替代 V8），单进程模式。尽管如此，大量的 Chromium 代码起衔接作用 ，例如网络层，同步和书签基础设施，地址栏，度量和崩溃报告。（同时，更重要的是，JavaScript 很少成为移动端的瓶颈，缺乏 JIT 编译器。