浏览器市场波澜：从KHTML到WebKit，再到Blink与Servo

Google宣布从WebKit 分支出自己的浏览器渲染引擎 Blink。很多人觉得这像是晴天霹雳，或者甚至是迟到的愚人节笑话，但是其实这件事情是难以避免的，而且是历史的重演。

什么是WebKit？它到底是谁的？

WebKit 是一个开源的浏览器引擎。它的前身是 KDE 在 1998 年开发的排版引擎 KHTML，最初用于 Linux 和 Unix 等开源操作系统。当时苹果觉得需要开发自己的浏览器，所以在比较了 Netscape（现在的 Firefox）的 Gecko 引擎 和 KHTML 引擎后，选择了后者，因为 KHTML 拥有更清晰的架构，而且比 Gecko 更小巧。苹果工程师 Don Melton 在 2001 年六月 25 号正式从 KHTML 分支出来，在苹果内部开始了 WebKit 的研发。

开始的时候，苹果和 KHTML 的关系还是不错的。苹果将 KHTML 发扬光大，在 2003 年推出了装备 WebKit 引擎的浏览器 Safari。但是随着时间的推进，WebKit 和 KHTML 之间交换代码变得越来越困难。苹果会间隔很长时间之后，提交一大批更改，而且没有文案，很多功能可能只开发了一半。对于 KDE 而言，将这些更改整合回 KHTML 是相当困难的。此外，苹果要求 KDE 开发者阅览苹果代码之前必须签署保密条款，KDE 也很难接受这一点。在 2005 年，KDE 开发者开始公开攻击苹果的做法，并称两方的合作关系已经彻底瓦解了。

事情被媒体报道之后，苹果做出了一系列的让步。在 2005 年，苹果宣布将 WebKit 完全开源（之前仅有从 KHTML 直接搬来的 WebCore 及 JavaScriptCore 是开源的）。KDE 和苹果的关系也得到了一些改善，有一些 KDE 的开发者们开始为 WebKit 提交更改，苹果的团队也复原了很多为苹果特定的修正，并且实现了平台层的抽象化，使引擎的核心代码可以在其他平台上运作。但是 KDE 没有忘记苹果的背叛，他们没有完全加入 WebKit 的开发，而是在 2010 年底推出了 KDE 开发平台 4.5，并列支持 KHTML 和 WebKit。

Google的介入

Google 加入 WebKit 的开发是在 2008 年 Chrome 浏览器推出前后的事情。Chrome 浏览器使用 WebKit 引擎是 Android 团队的建议，而 Chrome 主要用的其实还是从 KHTML 那里来的 WebCore，它不太用 WebCore 之外苹果开发的东西，而是使用自己开发的多进程浏览器架构等。

但是 Google 毕竟资源和人力雄厚，在上周从 WebKit 分支之前，大约 50% 的 WebKit 更改来自于 Google 的开发者，剩下的一半大多数来自于苹果，其余来自于第三方开发者，比如 KDE 的开发者。虽然 Google 的开发者开始提交大部分的 WebKit 更改，但是 WebKit 的最终决策权还是苹果的。据一些第三方的 WebKit 开发者透露，苹果和 Google 的开发者在交流时没有一般开源开发者的那种相互支持，反而更像两头相互打量的狮子，气氛比较紧张。

Blink 引擎的新闻爆出之后， Hacker News 上立刻开始有双方的开发者发表评论。多数评论认为苹果目前的 WebKit 更改提交政策对非苹果的开发者是有敌意的，尤其在 WebKit 2 这块。更有很多人认为 WebKit 2 完全是苹果单方推出的一个产品，而且根本就没有和 Google 以及其它参与 WebKit 开发的人进行协商。

苹果的开发者也对此给予了答复，苹果 WebKit 团队领头人 Maciej Stachowiak 说：

如果我们要讨论历史的话，我们开发 WebKit 2 的最主要原因是因为 Chromium（Chrome 的开源版）从来没有将它的多进程架构整合到 WebKit 里。这些代码一直在 Chromium 自己的目录中。

我们在写任何 WebKit2 代码前就问了 Google 的人，他们愿不愿意将多进程架构的支持整合到 WebKit 中，他们的答案是否定的。在这种情况下，我们面临的选择是做一个怀有敌意的 Chromium 分支，或者写我们自己的多进程架构，或者继续使用单进程架构。我们选择了写自己的多进程架构。

如果当时 Google 同意整合他们的多进程架构，那么我们肯定是会接受的，事情的发展可能也会和现在不太一样。

无论谁是谁非，苹果和 Google 这两家在 WebKit 中明显已经各走各的路有一段时间了。KDE 是一家完全开源，对苹果没有任何实质性威胁的开发团体。如果当年苹果和 KDE 都不能够维持良好的合作关系，它是不可能和 Google，一家在多个领域与苹果有你死我活级别竞争关系的公司，有什么良好合作的。虽然之前有很多人认为 WebKit 项目有点像柏林墙上的一个缺口，但这明显有点天真了。

谁将拥有未来

未来的事情我们谁也不知道，但是我们能够看到的有这几点：

• WebKit会比以前少50%的新代码提交。

• 绝大多数第三方WebKit开发者会加入Blink项目。

• Google的平台是互联网本身，它会将所有资源倾注到Blink的开发之中，而苹果目前最重要的平台是iOS。

• 当没有苹果这个“合作者”之后，Google可以用它自己的速度来推进浏览器科技。想在浏览器引擎中放一个Dart 虚拟器？没问题。Google Native Client？可以。所以Blink支持的网络科技很有可能很快超越WebKit。

如果我非要下赌注的话，我会赌 Blink 逐渐取代 WebKit，因为 Blink 对于 Google 是有战略性意义的，而 WebKit 对于苹果来说只是它封闭性花园中一只开源的黑羊。

从 WebKit 的这段历史，我们还看到了什么？第一，大公司永远以自己的利益为导向。第二就是，最牛掰的工程师是开源项目的工程师，尤其是 Unix 这个生态系统里的开源项目；Chrome 用的 WebKit 部分根本还是 KDE 写的 WebCore

========================================================================

浏览器开发相关的重要新闻：一个是Google和Opera支持WebKit的分支Blink；另一个是Samsung将与Mozilla合作，共同推动Servo。Blink和Servo均以并行架构为目标。

不久之前，Opera宣布放弃自己的浏览器引擎Presto，拥抱WebKit。当时有人还担心，少了一种多样性对Web会有何种不利影响。现在他们不必烦恼了，因为Google从WebKit创建了一个分支——即名为Blink的抽象浏览器引擎，其开发会与Chromium结合在一起，由后者提供该平台的一种实现。Opera的Web布道师Bruce Lawson宣布，Opera将与Google一起开发Blink。

WebKit渲染引擎现在势头很猛，而且或许有机会成为最重要的引擎，那Google为什么要创建一个分支呢？Google认为，尽管“只有一种选择看上去对开发者的效率有利”，但从长期来看，“只有一种选择不可避免地会导致停滞不前”，而“如果有更多的渲染引擎可以选择，这会带来更多创新，也会使Web生态系统更健康”。

据Google介绍，之所以创建WebKit分支，有两个主要的技术原因：

• 与其他基于WebKit的浏览器相比，Chrome使用了与众不同的多进程架构。此举给WebKit和Chrome都带来了一定的复杂性，延缓了创新的步伐。

• Blink提供了一种选择，Google可以根据自身需要改进其浏览器性能，引入并行处理机制也是一个主要方向。

简而言之，Google希望“像V8对JavaScript所做的改进一样，改进网络、渲染和布局。还记得V8之前的JS引擎吗？我们希望带来同样健康的创新，让使用各种浏览器的Web用户都能受益”。

看来Google希望能够根据自己的需要自由推动WebKit的开发，不必遵守WebKit的开发协议，而且能增强自己控制力更强的Chromium。要成为Blink的提交者（Committer）或所有者（Owner），其他开发者必须遵从Google制定的指导原则。

Google的第一步是重新组织所继承的WebKit代码，“移除了7个构建系统，删除了7000多个文件——包含的代码超过450万行”。从长期来看，Google希望向Blink中引入一系列改进，包括：

• 进程外的iframe，支持在单独的沙盒进程中运行不同的页面组件。

• 更快、更简洁的网络，目前受限于“旧的Mac WebKit API条款而无法修改”。

• 将文档对象模型（DOM）整个移到JavaScript中。这有可能大大加快JavaScript DOM访问速度。

Google还考虑了如下可能的改进：

• 让WebCore了解多个进程内的历史记录信息（目前假定的是同步访问同一进程内的历史记录信息）

• 删除Widget树（原来受到Mac WebKit1的限制）

• 将WebCore分到多个模块中

• 尽可能让代码直接使用沙盒Platform API，代替WebCore/Platform API

• 建立一种更简洁、更严格的tree-gardening系统，避免每天需要两个全职工程师参与的情况

• 尝试把DOM移到JS堆中

• 增加对多核的利用（比如，改进HTML解析器、样式引擎和JavaScript解析器等模块）

• 去掉DOM中不够清晰的部分，这些部分可以做一些向后不兼容的修改，这样有利于提高性能或降低复杂性

• 在Mac Chrome中全部使用现代的、速度更快的tcmalloc

• 尝试增量式布局或并行布局

• 因为现在只有一个JavaScript引擎，所以可以移除ScriptValue/ScriptState等抽象概念，以此来修复内存泄漏问题

• 使用WebIDL替换WebKitIDL，移除定制的JavaScript绑定代码

• 改进WebCore，使之赶上DOM3 Event/[DOM]UI Event

新浏览器引擎的出现引发了Web开发者的担忧，他们必须确保其代码能在新的浏览器上正确运行。为缓解开发者的焦虑，Google引入了与Mozilla开发Firefox类似的机制。

我们的目标是推动创新，改进兼容性，开放Web平台，同时避免加入很多特性，避免破坏与其他浏览器的兼容性。关于新特性的添加、厂商前缀（Vendor Prefix）的使用，以及新特性何时才算足够稳定进而可以交付等问题，我们面向开发者引入了强有力的策略。

Firefox今天所用的Gecko引擎并不是基于WebKit的，不过二者高度兼容。我们会采用与Mozilla类似的方式，提供一个独特但兼容的开源引擎。我们也会继续开放Bug跟踪和实现状态，开发者随时可以看到我们在干什么，并做出自己的贡献。

另一个重要策略与厂商前缀有关，Google不打算将其用于新特性中了：

与之相反，我们会暴露一个设置入口（在about:flags 中），以便支持实验性的DOM/CSS特性，用户可以在此看到新添加的特性，进而加以试用并提供反馈，很像目前使用的“Experimental WebKit Features”标记。只有当我们想看看这些特性能否稳定交付时，才会在dev/canary版本中默认启用。

对于遗留的与厂商前缀有关的特性，我们会继续使用-webkit-前缀，因为重命名所有前缀会给开发者带来不必要的麻烦。我们已经着手研究实际中应用的HTML5和CSS3特性，借助调研数据，可以更好地指导我们如何可靠地弃用相关前缀所指定的属性和API。至于从WebKit继承而来的任何非标准特性（如-webkit-box-reflect），我们希望具体问题具体分析，随着时间的推移，将其标准化或是弃用。

至于一般性的Android和移动开发，Google希望“整个移动Web平台与Blink同步，甚至走在Blink的前面”。

之后WebKit就主要由Apple掌控了，这是Blink带来的副作用之一。Apple能否快速推进WebKit，使其跟上其他浏览器的步伐？我们拭目以待。

就在Google宣布Blink几小时前，Mozilla宣布与Samsung合作，共同推进Servo的开发。这是用Rust开发的一个并行浏览器项目，作为“利用明天速度更快的多核异构计算架构”的一种尝试。Servo是“完全从头开始重新构建的Web浏览器”，纳入了安全机制，并支持高度并行的硬件。

第一步是让它运行在Android/ARM上，到目前为止，Samsung的主要贡献是“Rust的ARM后端，以及支持Android交叉编译所必需的构建基础设施”。

目前，Servo是运行在Mac OS X和64位Linux上的一个原型浏览器引擎，很可能还要承受成长之痛.