Google Chrome：展望与分析

2008 年 9 月 1 日 Google发布了其新一代的开源浏览器—— Google Chrome 。所有人都认为 Google 发布的这个新一代的 web 浏览器将成为 web 角斗场上的一个主要竞争者，估计在一段时间内它都将成为大家关注、分析和预言的焦点。

早在官方宣布之前，网上就已经出现了不少小道消息，因为由 Google 创建的用来介绍 Chrome 的漫画早在官方发布前就透漏了关于Chrome 的消息，同时它也早于美国太平洋时区9 月2 日发布Chrome 的Windows beta 版的时间。

InfoQ 随即从社区、新闻媒体及博客中摘选出对它的展望与分析以便对 Google Chrome 的发布和影响进行全面的报道。

Chrome 简介

Google 通过一个漫画来介绍其浏览器，该漫画由 Scott McCloud （著名的 Making Comics 的作者）绘制，这个漫画站点主要面向新闻记者和博主。该手稿由 McCloud 和开发者们自己（McCloud 曾采访过他们）协作完成。该漫画说明了 Google 令 Chrome 区别于其竞争者的地方：集中于服务应用而不是内容、使用面向进程的方式以隔离独立的沙箱进程、使用简单的标签式界面、快速渲染以及 javascript 引擎和一个内建的私有浏览模式。

Chrome 使用了标签、地址 / 导航栏和一个可选的工具条来简化界面。尽管在现代的 web 浏览器中简化的界面是很常见的一个特性，但 Google 相比于其竞争者来说却更进一步。正如 Ars Technica所述：

Google 对 Chrome 的处理方式与众不同。他并没有移除现有 web 浏览器的特性，而是重新洗牌。忘记菜单分隔符吧；为什么还需要书签菜单呢？该死，为什么还有菜单条？开始时一无所有。什么都不用想。只添加需要的特性，并且只应用定义良好的概念。并不是说 Chrome 的所有特性都是好的，或者说这些特性加一起就将 Safari 打得体无完肤了。我们只是说现在除了 Apple 以外还有其他人能在该领域取得领导地位。Google Chrome 使得 Safari 的用户界面看起来很保守了；这会让 Apple 感到无地自容。当谈到革新时，从长远来看全面大胆的改革要优于个别地方的修修补补。

Chrome 简化的界面意味着无需从原来的内容中转移太多东西，这里的内容指的是与用户交互的 web 站点或者 web 应用。尤其对于 web 应用来说，Chrome 的界面甚至没有导航栏和专用链接，这样窗口看起来就更像是一个应用程序而不是 web 浏览器。Chrome 还带有 Google Gears ，其主要目的就是扩充 web 应用的能力，使其更像是桌面应用，比如说当用户与 internet 的连接断掉时它还能工作。

Google 将标签放到了浏览器的最上面以示强调，并使得用户不仅可以在框架内拖动标签，还可以将其拖到外面以创建新窗口或者将标签从一个窗口移到另一个窗口上。这些标签彼此间是独立的，这样它们就更像是独立的应用，一个标签的崩溃不会影响到整个 web 浏览器。尽管对 Chrome 的漫画介绍谈到了独立进程，Chromium 站点还是详细介绍了 Chromium 支持的 4 种进程模型及其优缺点：

对于该 beta 版，Chromium 支持 4 种不同的进程模型用来实验和度量，这将帮助我们从中选择一个最适合大多数用户的默认模型。默认情况下，Chromium 对用户所访问的每个 web 站点实例都使用了一个独立的 OS 进程。然而当启动 Chromium 时用户可以通过命令行选项来选择其他的模型：Chromium 可以对每个 web 站点使用一个进程、可以隔离每个连接标签组、还可以将所有东西都放到一个单独的进程中。这些模型的区别在于它们是否反映了内容的来源、浏览器的用户界面，或两者兼而有之。

关于进程和线程的话题每次都会引起争论，这次也不例外。

Chrome 还具有一个叫做 _Incognito_ 的私有浏览模式，它可以使用户以只读会话方式浏览，这种模式下浏览历史不会被记录，同时当窗口关闭时还会将 cookie 删除。

技术与内核

Chrome 浏览器是 Chromium 项目的成果，该项目将 WebKit web 浏览器引擎与新一代的 Google V8 JavaScript 引擎、 Skia 矢量图引擎及 Google Gears 结合在一起。

WebKit 浏览器引擎起始于 Apple 的 KDE 项目的 KHTML 与 KJS 引擎，后来成为 Safari 浏览器的基础。WebKit 随后被 KDE 重新采用。Google 已经在其 Android 移动电话平台中使用了 WebKit，并且它已经成为该平台事实上的解决方案。正如对 Chrome 的漫画介绍中所述：

它有效地使用内存，很容易被嵌入式设备所采用，并且新的浏览器开发者也很容易学习其代码。浏览器是复杂的。WebKit 做得很好的一点就是它保持了简单的方式。

最初的 Windows beta 版所用的 WebKit 版本似乎是 WebKit 525.13，这并不是其最新版本并且有一些安全问题（请看下面有关安全的内容）。一些用户发现 Safari 的 WebKit 渲染与 Chrome 的不同，包括反锯齿和阴影。这可能是由于使用了 Skia 图形引擎的原因。

关于与 WebKit 的集成问题，Chromium FAQ 上说到：

Chromium 源代码包含了 WebKit 源码的一份拷贝。根据发布的需要，我们常常会将快照映射到 WebKit 的树或者特定的分支上。 我们的目标是降低所维护的各个拷贝之间的差别以便更有效地参与 WebKit 社区同时平滑地进行定期更新。

V8 JavaScript 引擎是开源的，位于Google Code 上，它是为Chrome 编写的，而并没有采用现有的JavaScript 引擎。V8 是用C++ 编写的，代码行数超过了100,000 行，它可以独立运行，也可以嵌入到C++ 应用中。

创建V8 最重要的原因就是为了性能。 V8 设计文档中说：“V8 是…为快速执行大容量的 JavaScript 应用而设计的。”Chromium 博客中有一篇关于 V8 的博文——“需要速度”中说：

Google Chrome 的一个重要特性就是重新设计的全新 JavaScript 引擎——V8，其目的就是为了解决性能问题。特别是在我们想去掉一些 Web 应用使用 JavaScript 代码的数量和复杂度限制时，这种性能问题尤为重要。

V8 声称进行了大量的性能改进和创新：使用隐藏类快速访问属性，动态机器码生成和高效的垃圾收集（标记—收集、分代收集、精确收集、压缩收集），小对象读取，彻底地多线程。V8 团队是由 Lars Bak 领导的， Avi Bryant 说 Lars Bak 是“Strongtalk 和 HotSpot Java VM 的技术领导者，同时也是最初的 Self VM 的积极贡献者”，在其名下有大量 VM 相关的专利。

正如 Matthieu Riou 所指出的那样，在传统意义上 V8 并不是虚拟机，它并没有中间表示或者字节码。结果就是尽管你可以交叉编译为 JavaScript，但你不能将你自己的语言编译为“V8 字节码”。虽然有上述缺陷，Dave Griswold 依旧相信 V8 可以作为其他动态语言的引擎：

我相信这些特性会令 V8 很快成为动态语言的主要虚拟机。它应该为 Smalltalk 建立一个平台。

FAQ 指出 Google Gears 也迁移到了 Chromimum 项目中：

随着 Gears 成为 Chromium 的一个插件，我们拥有两份 sqlite 拷贝、两份 V8 拷贝。这也太蠢了吧。我们正在集成代码以便 Gears 可以在 Chromium 下顺利运行。我们打算在同一份代码外继续为其他浏览器构建 Gears。

尽管 Google Chrome 支持如 Flash 和 PDF 这样的内容处理插件，但它现在并不支持浏览器扩展，不过该功能已在计划中了。

历史

Niall Kennedy记录了 Google Chrome 的历史。他首先讲述了 Google 对浏览器增强所起的推动作用：Google 大量使用了 Ajax 并与 Ian Hickson 一起为 HTML5 及浏览器“acid”兼容性做出了巨大贡献，并进行了很多浏览器扩展如 Google Gears、浏览器同步及安全浏览。接下来他还谈到了 Google 的 Android 项目及 WebKit 浏览器，Android 上需要无线的、具有 Skia 矢量图库及 GreenBorder 安全沙箱的 WebKit 浏览器。最后他还提及了由 Ben Goodger 率领的 Chrome 团队及由 Lars Bak 率领的 V8 团队。

《连线》杂志的 Steven Levy 还在其文章“探秘 Chrome：挑战 IE 并重建 Web 的秘密项目”中谈到了 Chrome 开发背后的故事，一直追溯到 2001 年：

“浏览器很重要”，CEO Eric Schmidt 说到。他应该知道，因为他是 90 年代浏览器大战时期 Sun 的 CTO。Google 共同创始者 Larry Page 和 Sergey Brin 也很清楚这一点。Schmidt 说，“当我在 2001 年加入 Google 时，Larry 和 Sergey 就说我们应该创建我们自己的浏览器，但我拒绝了。”

Levy 创建了最初的原型——V8 团队，尽管有一些问题，但还是令人感到惊讶：

太难以置信了，Google 浏览器竟然已经悄悄开发 2 年了。直到 2007 年中期（也就是该项目开发 1 年后），该团队才让 Google 其他组的成员看到他们所做的成果。在针对当前原型的特性的一系列技术讨论后（目的是为了在 Google 内部找到适合该团队的新人），人们的反应很强烈。在展示完各种特性如将一个标签拖到新窗口中后，人们不由自主地报以热烈的掌声。随着知道 Chrome 的人越来越多，其信息就流传到一些 blog 上了，但也只是一些零散信息而已。并没有人将它们整合到一起。Upson 说，“我想这是因为关于 Google 浏览器的流传到处都是，它就像大脚的眼神或者尼斯湖海怪一样”。

开始：只限 Windows、地毯式轰炸、私密性及最终用户许可协议

当漫画发布一天后，Google 也就真的开始了，在其 beta 版发布前网上曾有一篇博文专门对其进行了描述。同时漫画本身也引起了人们的广泛关注。 Josh Evnin 不禁为漫画中对“实际的 Google 员工”的使用拍案叫绝，同时也很喜欢这种讲解技术主题的方式：

另外一个 Google 处理的比较好的地方就是在讲解技术时没有过于工程化。他们将内容简化为几个核心点，在读完该文档后我受到了启发。大多数技术文档都假定读者已经具备了基本的技能。Google 通过一种几乎人人都能理解的方式来讲解其新技术，这样就扫平了障碍。而这正是其他开源项目欠缺的地方。技术文档并不是简单的文档，而是让阅读的人能身处其中。 该文档的质量给我留下了深深的印象。我将全部文档都读完了，这比我用过的任何软件的文档写的都好。谁能知道我竟然觉得多线程和多进程的区别很有意思？

Google Chrome 目前只有 Windows Beta 版，不过其他平台版本也快了。Google 提到了 Mac 与 Linux 版，但其发布日期尚未确定。人们都期盼着 Chromium 的 Mac 版，当 Sergey Brin 说缺少 Mac 版将是“尴尬的”时，新闻中就报道了该版本。Chrome 的Mac 版得益于 Mike Pinkerton 的努力，他是该项目的领导者， Camino 的主力开发者，同时也是从事于 Google 的 Mac 桌面产品开发的 Google 员工。

Amanda Walker 注意到尽管 Chrome 团队拥有多名在特定操作系统上具有丰富经验的开发者，但他们仍然是同一个团队，每个人都向所有平台贡献代码。在当前的状态和过程下，Walker 说：

现在，状态和过程都在“分块构建并通过了测试，但尚未生成 Chromium 应用。”当我们努力工作并追赶 Windows 版时，我们并没有为其何时完成设定日期——我们无法做出估计，同时我们也期望能从 Windows beta 版中学到一些东西。此外，既然项目已经发布，你每周都可以看到（或许还可以对其作出贡献）进度。当这些版本稳定后，我们就要发布官方 beta 版了，就像我们对 Windows 版所做的一样。我们尚不能给出一个明确的日期，不过一旦我们完成了就会通知大家。

如果你对接下来的 Linux 和 Mac OS X 版的 Chromium 开发感兴趣，你可以登录 Chromium 开发站点来获取资源。

要不是提前泄漏了消息 Chrome 现在是不会发布的。Chrome 很容易遭受到 carpet-bombin 缺陷攻击，该缺陷已在 WebKit 的后续版本中得到了修正，然后 Google 并没有集成该已修正版本。尽管 Chrome 还仅仅是 beta 版，但对其的漫画介绍依然鼓吹它设计上的安全性。

类似的，一些人认为 Chrome 在用户隐私上做的有些过分。当你输入地址时，omnibox（就是人们常说的地址栏）会给你提示，这样做的目的通常是将数据发送到已选的搜索引擎中，而该引擎默认就是 Google。这使得一些人认为 Chrome 对隐私的保护比你想的还要差，尽管Google 已经就获取的这些数据对人们的担忧做出了回应。

Matt Cutts 采访了 Google Chrome 团队以了解 Chrome 何时会“向 Google 发送信息”，并总结到：

我知道当 Google Chrome 刚一发布一些读者就问了一些棘手的问题，这些问题是关于隐私及 Google Chrome 如何 / 何时会与 google.com 通信。因此我决定首先解决这些问题。我采访了 Chrome 团队以了解我们是否有必要担心。答案很简单——不需要。

尽管有这些保证，德国联邦信息安全局还是警告用户不要使用Chrome 。

Chrome 的服务条款也引发了口水战，因为它暗示Google 对通过Chrome 浏览的所有内容拥有保留权。Google Chrome 的高级产品律师Matt Cutts 和Rebecca Ward认为该条款是个错误；9 月3 日周三已经对其进行了修正，争论终于平息了。

浏览器大战与其它动机

很多人都认为Chrome 的发布标志着曾经在微软和Netscape/Mozilla（这些是主要竞争者，尽管每款浏览器都有其拥护者）之间爆发的_ 浏览器大战_ 又上演了。一些人已经不看好Chrome 了，而另一些人则采取了观望的姿态。

很多人说Google 并不想与其他浏览器竞争，而仅仅是想促进网络交付应用的发展，使其看起来与桌面应用差不多，这样一来就使操作系统隐居到了后台。

特别地，喜欢这么说的人热衷于把微软放到对立面，这样人们就能看到两大巨人之间的争斗了。

其他浏览器：比较和影响

有些人认为Chrome 仅仅是重新发明轮子。 Georgios Kasselakis 在 OSNews 上说 Chrome 的进程模型与 IE8 的没什么太大区别，它的标签与 Opera 的差不多，这是来自 Opera 用户的情感呼唤。

尽管 V8 声称根据基准它有非常快的速度，但其他浏览器制造商也做了类似的声明说改进了其产品的速度。

Mozilla 的 Firefox 3.1 有 TraceMonkey，它提供了速度改进，同时 Brendan Eich 也对其进行了一些测试。

他认为在某些情况下及其它情况的“游戏”中 TraceMonkey 的速度已经超越了 V8，但他说到：

V8 很棒并且工程化良好，其速度还有提升的空间。（Chrome 看起来很棒——其多进程架构很好，但你依然想从像我这样的老牌 Unix 黑客中得到赞扬） 大家需要认清的一点就是这场竞赛并不是最后的决赛，参加角逐的 VM 并不会遭到淘汰。我们认为 Franz 与 Galstyle 的追踪要比缺少攻势的投机方法具有更广阔的“空间”，这是由于其专注于代码的能力决定的，它可以在运行时让变量保持常量性，消除不会执行到的代码和条件，这基于大多数 JavaScript 程序中都会存在的隐式类型继承。如果我们说对了，我们就会在几周或者几个月后看到这一点，当然了你们也会看到的。

WebKit 团队已经在开发名为 Squirrelfish 的新的 JavaScript 解释器了，此前 InfoQ 曾对其进行了报道。John Resig 有一个详细的性能分析表，在该表中SquirrelFish 似乎处于领先地位，至少有几处是领先的。

大家都认为关注JavaScript 性能对最终用户来说是件好事，不管是谁构建的，只要用户能使用上更快的JavaScript 引擎就好。很多人想知道新出现的另一个web 浏览器会对市场上已有的浏览器产生何种影响。有些人觉得微软已经失利了，因为Internet Explorer 的市场份额正不断减少。其他人则对Firefox 表示出了担心，因为Internet Explorer 和Safari 已经预装在Windows 和Mac OS X 中了，很多用户就会一直使用他们而不会更换了，而Firefox 和Chrome 则要为更小的市场份额拼个你死我活。之前的一些数据有力地证实了这一点。Google 说不断增加的关注会提醒人们可以对其使用的浏览器进行选择。就连 Marc Andressen 都觉得Chrome 会让竞争愈演愈烈。

补充分析

尽管本篇新闻报道了关于 Google Chrome 的最常见的展望与分析，但还有一些关于 Chrome 及其影响的讨论值得我们关注：

• Carsten Knobloch 已经发布了 Google Chrome 的一个移植版本，非德语的读者可能想去阅读一份英文摘要。
• 一些 KDE 开发者觉得他们以前对 WebKit 的贡献未被承认。
• 由 Google 运作的 Chrome Help 组中已经包含了 1500 多个要求和建议的特性（如 FTP 支持、主题、以 icognito 方式启动 chrome 等等）。
• 很多 人都认为 Chrome 是 Google 云计算战略的下一步，信息周刊搜集了很多这方面的信息。
• Jesper 的第一印象是 WebKit inspector 不应该出现在 Chrome 中。
• Yakov Fain 注意到 Google Chrome 需要 Java 6 U 10，他觉得这会取悦JavaFX 开发者，他们已经通过一个 JavaFX/Chrome 示例用上 Chrome 了。
• 新的 chrome 用户可能会对一些小提示感兴趣，如特殊的 about 页面。
• Google 的 Android 可能会使用 Chrome 栈，尽管中间的细节还不是很清楚。
• 工具集爱好者可能想知道 Google 如何进行跨平台开发：

我们在这方面进行的太早了，导致无法形成一个工具集。大多数定制绘图都是通过 Skia 库完成的，该库与 Cairo 不相上下，因为它画的是线和矩形而不是按钮和复选框。很多人对工具集都有强烈的看法，导致分裂的部分原因在于这两个库都满足 Chromium 的需要。事实上，由于大部分 Chromium 仅仅是为显示 web 页面而进行的客户化渲染——就连 HTML select 控件的弹出都是由 WebKit 绘制的——我们希望工具集只出现在一些 form 控件的展示及各种对话框中如首选项及“另存为”对话框。

综上所述，我们打算使用 GTK。这并不代表我们不喜欢 Qt，仅仅是因为团队具有更多的 GTK 使用经验，并且它与 Linux 上现有的 Firefox 依赖相匹配。请保持冷静:-)

资源

由于上面已经列出了全部的链接、分析和展望，我将为那些对 Google Chrome 感兴趣并想进一步了解它的人提供一些常用资源：

• Google Chrome 站点
• Chromium 博客
• Chromium 站点
• Chromium 开发者文档

查看英文原文： Google Chrome: Perspectives and Analysis