为什么 Mozilla 要固守 Gecko 内核

随着 Google 推出 WebKit 内核的 Chrome 浏览器，一些技术狂热分子开始盘算 Mozilla 的 Gecko 内核是否即将走到尽头。然而尽管 WebKit 日渐流行，那些熟悉 WebKit 与 Gecko 的差异，并对 Gecko 大加赞赏的人还是认为，Mozilla 在未来版本的 Firefox 中使用 WebKit 内核的可能性尚无从谈起。

Webkit 的优势

Webkit 是一个开源的HTML 渲染引擎，由苹果公司基于 KDE 的 KHTML 项目开发而成。我们从 Chrome 的评测中已经看Webkit 是一个非常轻量的渲染引擎，因其紧凑干净的代码基础，出色的标准支持，以及很小的内存占用而备受赞誉。这些品质使得 Webkit 成为众多浏览器的热选内核。

Webkit 主要用于苹果的 Safari 浏览器与 iPhone，但一些重要的厂商如 Adobe，Nokia, Trolltech 也使用这个核心。Webkit 的用户中还包括一些不太知名的浏览器，包括 iCab, Omniweb, Shiira, 以及 Epiphany。在一些二线操作系统，如 Haiku, Syllable, 甚至 Amiga，Webkit 也大行其道。越来越多的开发者，使用 Webkit 开发富 Internte 应用（rich Internet applications）。Google 在对众多内核进行评估之后，为 Android 移动浏览器，以及 Chrome 桌面浏览器选择了 WebKit。

开发者对 Webkit 公认的评价是：这是一个非常出色的渲染引擎，可以用于众多场合，它的吸引力让很多开发者开始怀疑 Mozilla 的 Gecko 内核是否还有市场。

苹果为什么抵制 Gecko

Gecko 源自 Netscape，并早于 KHTML，Gecko 因庞大与复杂的代码基础而频遭诟病。Gecko 非常强大，但代价高昂，复杂，高内存占用。因此，在很多场合 Gecko 的众多功能反而成了负担。

Gecko 内核过于复杂的原因是 Gecko 意图提供除了 HTML 渲染之外的更多功能。Mozilla 早期的野心很大，Mozilla 最早的应用套件包括浏览器，邮件和新闻组程序，Web 设计工具，IRC 聊天工具。除了渲染 HTML，Gecko 还要提供一种应用广泛的，基于 XML 的用户界面生成引擎，XUL。XUL 被用在所有这些程序中。XUL 现在仍用在 Firefox 中，用来生成用户界面，因此造就了 Firefox 最有价值的重多扩展应用。

Gecko 过于复杂的另外一个原因是 XPCOM，一个强大的组件系统。虽然 XPCOM 为 Gecko 带来很多激动人心的功能，让这个渲染引擎实现组件化，然而，这个功能被一些开发者滥用，当 Ars Technica 2004年采访 Mozilla 开发者 Scott Collins 的时候，Scott Collins 说，对 XPCOM 的滥用是 Mozilla 犯的几个主要错误之一。

鉴于 XUL 和 XPCOM 所带来的复杂性，苹果自然要考虑为 Safari 选择一种更轻量的内核。苹果要设计一款可以和 Mac 操作系统紧密结合的浏览器，他们还预见到，这个引擎应该支持移动设备，他们因此认识到 KHTML 比 Gecko 更合适。

2003年，当苹果决定在 Safari 中使用 KHTML 的时候，Mozilla 的 Mike Shaver 曾在博客中承认 Gecko 的缺点。他同时预言，苹果会成为他们推广 Web 标准的联盟。他写道，

“小而精练曾是我们的苦苦追寻的目标，Gecko 的庞大与臃肿在各种评测中拉了我们的分数，如果我不得不写一个新浏览器，我会考虑 Mozilla 之外的选择。我希望 Mozilla 向 Safari/KHTML 学习，因为它们用 1/10 的代码实现了非常棒的功能。”

Gecko 洗心革面带来 Firefox 3 的火爆

2003年以来，发生了很多变化。Gecko 代码基础已经发展了很久，Gecko 依然复杂，然而它的很多历史遗留的缺陷正被一一攻破，Gecko 为 Firefox 3 带来众多革新，为整个 Web 浏览体验带来非常显著的改善。

Gecko 1.9 使用跨平台的 Cairo 渲染框架，对 SVG 的巨大改进简化了代码并引入一些非常 Cool 的功能，如全页缩放，同时，重构的 reflow 算法，让 Gecko 通过 Acid 2 测试成为可能。Mozilla 还非常显著地降低了对内存的占用，甚至超越了 Safari 和 Opera。

对 XPCOM 的使用被大大减少，XPCOM 对资源的占用通过一个新的循环回收器得到减低。这个工作仍在继续，Mozilla 将在 Firefox 4 中进一步减低 XPCOM 的负担。Gecko 的其它缺陷也在新的开发中被一一正视，比如，Firefox 3.1 的 Alpha 版中就已经加入对 CSS 3 的支持，另外一些性能的改进会让 Gecko 更具竞争性。Mozilla 的 TraceMonkey 引擎将可能包含在 Firefox 3.1 中，这将显著地提高 JavaScript 性能。

从技术的角度，Gecko 现在非常稳固，丝毫不比 Webkit 差。一些证据显示，Gecko 正在进军移动领域，这在不久前还是不可能的事。Mozilla 拥有资源，开发经验以及社区支持，这将引导 Gecko 进入任何 Webkit 所能进入的地盘。

这是 Ars Technica 2008年9月9日刊登的为什么 Mozilla 要固守 Gecko 内核的第二部分。该部分从 Webkit 与 Gecko 不同运作方式的角度，讲述为什么Mozilla 不会抛弃 Gecko。第一部分请参阅：为什么 Mozilla 要固守 Gecko 内核（上）。

为什么 Gecko 备受第三方青睐？

值得一提的是，Gecho 的诸多独特功能颇受第三方开发者青睐。业界已经出现不少基于 Mozilla XUL 的应用，例如，Songbird 音乐播放器，Miro 视频播放器，以及 ActiveState 的 Komodo IDE。这意味着，第三方开发者可以使用 XUL 和 JavaScript 在装有 Firefox 的机器上构建富 Internet 应用。同样，我们看到一些复杂的 XUL 程序正被设计成 Firefox 的扩展，例如，Pencil，一个 GUI 界面原型绘制程序，该程序最近曾荣获 Firefox 3 扩展设计大奖。

即使一些 Webkit 阵营的公司，也在 Gecko 和 Firefox 投入了非常客观的资源进行研究。例如，Nokia 正在投资一个 Firefox Qt port 项目，而 Adobe 也在同 Mozilla 合作开发 Tamarin，一个用于 Adobe Flash ActionScript 虚拟机的 JavaScript 引擎。

很明显，Gecko 拥有 Webkit 所有的功能，性能，以及低内存占用优势，同时拥有其它渲染引擎所不具备的高级功能。尽管 Webkit 的狂热者认为 Webkit 更好，但 Firefox 没有任何理由舍弃 Gecko。
解释为什么 Webkit 不是 Firefox 的未来

我们曾问过 Mozilla 的现任 VP 工程师 Mike Shaver，他对 Gecko 与 WebKit 之争有何看法，为什么他认为 Gecko 仍然重要。他在 Email 回复中说，

“我对开发 Webkit 的人充满敬意，也欣赏他们的工作。他们的努力让 Web 变得更好。而 Mozilla 本身也在这种竞争，以及同 Apple 在 Web 标准的合作中变得更好。”

虽然 Mike Shaver 尊重 Webkit 的技术贡献，但他相信，Webkit 的开发模型以及它的生态系统导致这个内核不适合 Firefox。

“我们的众多项目，从桌面，到移动设备，到 XUL，到雷鸟，都使用一个统一的引擎，这为我们带来诸多好处。如果你看一下 Webkit ，就会看到他们有很多不同的项目，这些项目最终是否会聚焦到一起还不得知。如果要启用 Webkit，我们需要对这个产品进行大量剖解，而让这样一个飞速发展的替代品加入进来未必是好事。同时维护多个引擎是很艰难的工作，我们不想找这个麻烦。”

同时，如果启用 Webkit，Webkit 的运作模式，以及苹果透明度的缺乏也将对 Firefox 带来负面影响。

“我觉得如果那样，我们的日子将非常难过，在我们的社区，补丁与评测都非常透明，比如，我们不会因为那些只能用于苹果的 Bug 跟踪系统而漏掉某个 Bug。对我们来说，引入 Webkit 并继续保持我们以前的透明度将降低我们的效率，而我们也不愿失去这些透明度。我们的体系在我们这边运转得很好，他们的体系在他们那边也运转得很好，我不认为有哪个体系可以在两边都如鱼得水。”
结论
客观地讲 Gecko 的技术优势非常明显，而向 Firefox 迁移 Webkit 的代价又很高，我们以前也讲过，拥有多样性的产品与竞争是一件好事。

Gecko 和 Webkit 之间有很多东西可以互相学习，但用 Webkit 替代 Gecko 并没有道理，Mike Shaver 最后提到，“我们象所有人一样关注 Webkit，也象所有人一样挑剔 Gecko，然而将二者互换既不现实也没有意义。 ”

本文国际来源：http://arstechnica.com/articles/paedia/mozilla-committed-to-gecko.ars/2
中文翻译：COMSHARP CMS