既然客栈已给IE7，Firefox 2/3，Opera 9和Safari for Windows等等浏览器做过评测，支持平等机会的我们没理由放过Google Chrome，这款10岁网络霸主的新beta产品。为增加娱乐性，我们决定通过各浏览器亲卫队最喜欢也最鄙视的大乱斗解决：Google Chrome 0.2 vs Firefox 3.0.1 vs Internet Explorer 7 vs Opera 9.52 vs Safari 3.1.2 for Windows！高潮迭起，请勿错过！¹⁾

回归正题，相信浏览器爱好者们已经非常清楚几位老选手的底细了，这里只介绍新人“股沟鸽”的内涵配置。

Google Chrome （ver0.2.149.27）

• 页面渲染引擎：WebKit/525.13（Safari 3.1.2使用WebKit/525.21）

• 图像渲染引擎：Skia（Google自行开发，还缺乏部分功能，例如text-shadow和border-radius）²⁾

• Javascript引擎：V8（Google自行研发，适合运行结构性强的JS代码） ³⁾

FF，IE，Opera和Safari的支持者，看清楚对手的嘴脸了吗？让我们进入第一个环节。

技术测试

中文网络上的用户体验实在是多如牛毛，个人感想到底没什么说服力，还是先上测试大餐对得起观众。

Javascript 引擎测试

Google Chrome浏览器内最前卫的莫过于他们独立开发的Javascript引擎：V8。在他们自己制作的速度测试上Chrome以超过Firefox 3和Opera 9.52数倍的成绩完成任务，更不用提众矢之的的IE7了。

然而V8的benchmark是否有足够代表性？Google有没有刻意夸大V8的实力呢？让我们用客栈自食其力的实证主义精神来判断。我们选择了如下几个Javascript引擎测试——

• 来自mootools开发者的Slickspeed，测试浏览器运行主流JS库各种selector的速度。与DOM有关。

• 来自Celtic Kane的JS Benchmark，测试运行简单对象，内置函数与DOM的速度。

• 来自Google的V8 Benchmark，有大量的递归函数，纯粹JS引擎测试，无DOM。

• 来自WebKit的SunSpider，测试各类函数运行，纯粹JS引擎测试，无DOM。

• 来自PPK的DOM vs. innerHTML Benchmark，本用于研究不同元素生成方法的速度，这里用于测试浏览器的DOM渲染能力。

• 来自Mozilla和jQuery开发者的Dromaeo V2，测试从内置函数到主流函数库等等实际浏览时会遇到的运算问题，包括大量有关DOM操作的测试。

Slickspeed

对于轻量级网站的JS代码开发者来说，如今几个主流JS库的速度决定着网站的速度，因此在JS库DOM最基本的组成部分——selector上下点功夫测试绝非奇怪之事。

详细测试数据

在该测试中Google Chrome并没有什么优势（和Firefox3相近），反而让传统的强者JavaScriptCore（Safari）和Opera的新引擎 Futhark拿到头彩。各位自行做测试就会发现，每款浏览器都有自己特别不擅长的selector模式，这和对应JS库的具体实现方式有关（因此不同浏览器的返回值出现分歧的selector也不同）。

JS Benchmark

只包含少数几个对象/函数的loop检查，缺乏实际应用性；测试Javascript引擎运算能力和特定的DOM。

详细测试数据

Google Chrome再次败阵，原因在于V8引擎就算对简单的函数构造也会毫不含糊的重复新建/修正“隐藏类”，导致速度大大减慢。使用内存字典搜索的Safari，Opera乃至Firefox会更快。

V8 Benchmark

详细测试数据

回到Google自己制作的benchmark上，4个测试的统一特质：递归函数。只要指定类型的对象属性没有被更改过，V8就能再利用与之挂钩的隐藏类，直接生成machine code stack，免去耗时的搜索内存的步骤。V8 Benchmark就是在假设甚少对象属性变更的基础上设计的，因此对Google Chrome相当有利。

SunSpider

详细测试数据

SunSpider是一款相当出名的Javascript引擎性能测试，由于它囊括了各方面的纯引擎测试，是许多浏览器开发者的首选。Google Chrome二次夺冠，但这次它的领先幅度缩小很多，V8的杀手锏“隐藏类”为它在前四个部分（尤其是测试递归的controlflow）取得了决定性胜利，但在其他区域Chrome的优势明显较弱，甚至被其他浏览器反超。

DOM vs innerHTML

详细测试数据

这时我们猜测Google Chrome的弱点可能在于它DOM Manipulation的速度。遂选择了PPK制作的“内容生成”测试。简单的DOM测试证明Chrome的速度介乎Firefox 3与Opera 9.5之间，V8的优势在重复利用对象的JS运算上才能得到充分体现。

IE7的数据有点惨不忍睹。

Dromaeo V2

最后这个测试围绕着Web 2.0时代进行，不管是内置函数还是外挂函数库，都少不了为DOM服务的，而DOM也是大多数浏览器最慢的部分。因此除了纯粹的引擎测试，Dromaeo V2还有大量的DOM和渲染被加入（IE7实在太慢，没法完成测试）。

详细测试数据

Chrome没能获得第一，但表现得比Firefox和Opera要稳定（后两者都有特别慢部分，导致得分偏低）。

引擎测试小结

Google Chrome的V8是个相当独特而优秀的引擎，它考虑到了Javascript代码开发的趋势，为复杂的JS框架/Web2.0服务量身定做。它目前问题是DOM渲染并不突出，这就好比欠了东风，让Chrome还是火不起来。对于国内的用户来说，Gears插件节省的页面读取时间或许比V8的优势明显得多，不过这是题外话了。

Flash插件，启动速度，内存与CPU占用

在网速较慢的中国，对Javascript运行速度的要求或许不如国外高（JS上争取到的1-2秒相对网速的缓慢不过是小巫见大巫）；在国内，对Flash插件的兼容性，浏览器耗费内存与CPU的度或许才是用户最注重的项目。

Flash

Flash插件的好坏一直评判是浏览器流行程度的指标，IE的ActiveX插件始终比其他使用NPAPI插件的浏览器要快，这也是为什么IE还在嚣张的原因之一。

Google Chrome也和多数开源浏览器一样，使用npswf32.dll作为插件。有鉴于Safari for Windows是个电脑杀手，我们特别在意Flash插件与谷歌浏览器的资源消耗。

测试一号

Google Chrome vs 所有使用npswf32.dll的浏览器；我们使用禁用了ActiveX插件的IE7作为基准。

上图中的所有浏览器都打开了1个主窗口，5个标签页分别运行着纯文字页面、多图片页面、Javascript高需求页面、Flash影片页面和我们自己的标准站。结果是Chrome的多进程系统耗费最多内存，133MB；Safari以107MB紧随其后，Opera和Firefox只是使用了 80MB左右；没有Flash插件的IE7更是用了不到56MB。

接着我们关闭了使用Flash的页面，让浏览器自行释放内存。这时Safari for Windows的问题显露无遗：它无法释放Flash插件占用的内存，这也解释了用Safari上新浪网（Flash广告海）就假死的原因。所幸的是 Google Chrome并没有类似的问题，但它仍比其余两款浏览器使用更多的内存——Chrome为避免单一标签页崩溃就殃及整个浏览器的问题，将每个标签页的内存单独处理，间接导致内存占用增加。Firefox/Opera表现正常。

最后是将所有标签页关闭，清空缓存后的结果。Google Chrome的Sandbox表现相当出色，配合V8的垃圾回收，基本恢复热启动时的内存占用量；Firefox的内存管理不比Chrome逊色，也接近了冷启动时的初始值（30MB左右）。Opera 9.52的73MB可以接受，虽然远超过20MB的启动内存，但它在浏览页面的过程中一直只占用70~90MB内存的特性让我们猜测它有独特的内存管理。最后是Safari，呃，也就是如你所见了。值得一提的是IE7的内存也迅速降下来了，微软毕竟不是白吃饭的。

测试二号

将Flash ActiveX插件与npswf32.dll平行对比，Google Chrome vs IE7的战斗。参照浏览器为Firefox 3。

同样的环境中，IE7果然比Google Chrome少占用内存，算上IE与explorer.exe共用的内存，谷歌的浏览器还是超出10MB有余。

作为对比，以上分别是在浏览无Flash页面和热启动时的内存监视，Firefox和IE7的内存占用都与Chrome相近……可预见今后浏览器性能大战的获胜条件将少不了来自Flash插件的良好支持。

小结

我们认为Google Chrome对Flash插件的支持达到或超过了Firefox/Opera的水准，代价是运行时的内存耗费比较大；另一方面Flash的ActiveX插件版仍有绝对的性能优势，有鉴于Google扼杀AIR和Sliverlight的决心，我们不认为Adobe会特别关照Google Chrome。

启动速度

准确测试有难度，只凭我们的观察为准。

冷启动耗时：Opera 9.52 < Google Chrome 0.2 < Safari 3.1.2 « IE7 < Firefox 3.0.1

热启动耗时：Google Chrome 0.2 =< Opera 9.52 =< Safari 3.1.2 < Firefox 3.0.1 < IE7

内存和CPU

为排除Flash插件和Chrome多进程的干扰，我们选择之前使用过的Dromaeo V2测试，因为它很耗CPU和内存，而且无需Flash支持。结果如下——

首先是空闲时的内存占用，220MB。

Google Chrome一度使用接近400MB内存，因为Sandbox的关系单个进程（标签页）的CPU占用不会到50%以上。双核使用不平均的问题估计在实际浏览中不明显。

Firefox的CPU分配很平均，减低了单独CPU的压力，但在CPU吃紧时会影响到其他程序的运行。Firefox 3在Javascript上的内存管理已经有长足进步，最多时只使用200MB内存，没有发现leak（这些JS库也有避免内存溢出的预防措施）。

Opera是相当奇怪的浏览器，它在运行JS时基本只使用一个CPU（会完全占用，即50%），我相信这是它速度较慢的原因。它在运行繁重JS时的内存占用较高，一度上升到450MB。我们的Opera 9.52在渲染Dromaeo V2页面时有bug，所以无法判断这个测试的准确性。

Safari for Windows 3.1.2的内存管理很糟，全无下调的趋势，最后停滞在500MB；相反它运行JS时的CPU占用率很低，我们甚至可以开个Winamp听歌兼用 Thunderbird收发邮件。另外别忘了，JavaScriptCore在本测试轻松获胜。

小结

Google Chrome用内存换速度做法在beta阶段会很受欢迎，相信不少人会成为Chrome的用户；而它的快速启动和每个进程只占用5~15%的CPU的特性，也比其他浏览器更为讨好（在我们的系统上没发现稳定性问题）；但要作为用户每天使用的浏览器，Google Chrome还需要考虑得更多。

使用体验

Google Chrome的不少独特设计都是双刃剑，我们会从多方面考虑。

菜单

Chrome是5款浏览器中唯一一款完全没有顶部菜单的，这对于熟悉浏览器通用快捷键的用户来说是亮点（例如Ctrl+B的收藏夹/书签，Ctrl+H的浏览历史等等），对于没这么擅长浏览器操作，喜欢通过顶部菜单寻找功能的用户来说则是烦恼。我们估计早期换用Chrome的用户会相当喜欢这种设计（这种设计类似IE7隐藏菜单栏后的设计）。

另外由于没有顶部菜单，Chrome不得不将所有功能置入右侧仅有的两个菜单按钮里，目前的还不算拥挤，今后Chrome功能增多时该怎么办，还需开发者挖空心思去解决。

标签页

Google Chrome的标签页与地址栏的位置关系与大多数浏览器相反，处于最顶部。习惯了各种标签页设计的我们并不觉得陌生，加上Chrome的标签页操作和其他浏览器几乎一致，早期使用者不应感到特别不适。

此外，Chrome从Safari身上学会了经典的标签页/新窗口互换技能，两款浏览器都能将标签页拖成新窗口，也允许新窗口之前互换标签页；Google Chrome可以将新窗口逐个恢复成标签，Safari则有融合所有窗口为一个的功能。

导航/地址栏

这大概是任何浏览器最显眼的部分，Chrome的设计没啥特别，一键添加书签的功能也与Firefox3雷同。另外Chrome的地址栏为减少页面欺骗，会突出显示页面的所在域名；IE8也已加入这种显示。

莫名其妙的是右侧箭头——Google假设用户知道如何输入地址，却不知道地址栏可以回车确认？这明显是为IE6的最初级用户设计的。

边侧栏和状态栏

Google Chrome没有边侧栏，他们的书签只使用顶部空间，类似其他浏览器的书签栏；其他功能均使用整个标签页。它亦没有状态栏，链接会以渐入渐出的方式在右下角提示；可预见今后的插件控制是个问题。

此外Google Chrome是不会完整显示长页面标题的，这可能会造成一定困扰。

有趣的新功能

以下是我们没能在其他浏览器找到的新功能，他们不一定都有用，但至少给用户耳目一新的感觉。

内置任务管理器

不少浏览器都有自己的内存/CPU占用/带宽检测功能，但Google Chrome是第一个提供内置GUI任务管理器的浏览器。对于浏览器性能痴迷者来说是一大喜事。

搜索定位

一般的浏览器只会在页面上高亮（通常是黄色）搜索文字，Google Chrome更进一步，在右侧滚动条上显示搜索关键词出现的大概位置，这对于长页面和Ctrl+U的代码浏览器来说很有帮助。

隐身窗口的幽默感

隐身窗口并不是Google的创意，基本所有浏览器都有控制Cookie，密码和浏览历史加载的方法，Chrome只是将这个功能作为重要功能摆上台罢了（Google Chrome缺乏用户的管理和保护，对于公共浏览器来说提供隐身窗口功能是满足基本需要）。不过隐身窗口的对自己解释却给我们网络小公司的幽默感，让人暂时忘记了站在浏览器身后的渐渐满口官腔，越发渴求利益的Google。

明显弱项

1. 缺乏高级书签管理，就算能导入书签还是不好用。

2. 长页面的文字选取很慢，说起来，页面滚动也不怎么流畅。

3. 默认保护过强，当页面有链接指向或图片来自受感染的域名，该页面也会被禁止。

4. 无可切换全屏模式。

5. 任何杀广告的插件，用本地proxy过滤不算；谷歌在这方面一点都不急。

6. 通过GUI禁用特定插件，而不是要用快捷方式的启动参数。

7. 清除浏览数据时不会记忆上次的选项。

Google Chrome FAQ

Google Chrome虽然是开源，缺乏记录的部分却很多，这里我们把客栈整理到的信息归纳一下。

关于隐私

Chrome与Google服务器通信的方式很多——

• rlz.dll

• Metric_Service

• 搜索建议(Omnibox)

• 其他

由于Google拥有的用户信息已经多得吓人，随着他们逐渐变味的隐私保护⁴⁾，让人不禁怀疑Chrome是否成为Google的开源后门，为此我们也专门去看看了源码的解释。

rlz.dll

这个位于0.2.149.27(版本号)文件夹下的dll负责记录/发送Google合作产品的信息（通过访问特定的注册表位置），目前它只会每间隔 24小时发送Chrome自身的升级情况，首页和默认搜索是否为Google等信息到Google的服务器；至于今后rlz是否会发展到收集其他 Google软件的信息，只能拭目以待（代码设计预留了扩展空间）。

由于rlz会用这些注册表信息生成一条字符串，并在默认Google搜索时加入到查询语法中（rlz=），也让人怀疑Google是否在收集用户习惯，即便Google声称这些信息不能用于分辨用户身份。

rlz.dll并非浏览器进程必须的库，可以移除。

Metric_Service

这个服务并不是Google的原创，它一直是Firefox的官方扩展之一，只是不包括在下载包之中罢了。Google Chrome借用了Mozilla的Browser Metrics代码，打造了自己的Metric_Service，将收集到的信息发送到这个地址（直接访问会出现无效SSL证书的问题，强行接受证书就可以看到使用以下namespace的XML回应）

http://www.mozilla.org/metrics

这符合Mozilla官方的数据规格。按照Mozilla自己的说法，这个服务可以收集从浏览器设置，安装插件，特定URL到硬件设备等等基本信息，某种程度上是对用户隐私的侵犯。因此Chrome不用安装Google Toolbar也能达到统计用户使用数据的目的。

目前Metric Service可以通过禁止Chrome发送统计信息和崩溃报告来阻止（在高级选项中）。

搜索建议(Omnibox)

只要不关闭搜索建议，并使用Google为默认搜索引擎，Chrome就会尝试建议关键词，这是通过向Google服务器提交信息得到的结果，自然也会让Google得到你输入的关键词（即便没有回车输入）。

搜索建议可到“选项”的“基本信息”的默认搜索中关闭。

其他

Google Chrome会定时更新不安全网站列表，下载拼写检查字典等等……

另外，跟随Google Chrome一起安装的Google Update会长期进驻系统（作为Win32服务），定时检查软件更新和提供一键安装的功能；没有正常的反安装功能，移除该程序比较困难。

使用免安装版Chrome可以省去移除GoogleUpdate的麻烦。

关于移动版

制作绿色/免安装版Google Chrome非常简单，只需要复制位于以下文件夹的所有内容即可。

Documents and Settings\username\Local Settings\Application Data\Google\Chrome\

制作Portable（可携带版）的Google Chrome比较麻烦，由于Google Chrome缺乏用户管理，目前它的默认用户被锁定在

Documents and Settings\username\Local Settings\Application Data\Google\Chrome\User Data\

必须新建快捷方式，加入–user-data-dir参数来设置用户账户的位置。 ⁵⁾

或者等待专业人员编译使用相对路径的Chrome。

关于谷歌的计谋

普遍认为Google Chrome的目的首先是打击IE的市场份额，让Google在提升基于Javascript的服务的复杂性时少些阻碍。^{6) 7)}

让Google花这么多人力去开发新浏览器的理由有不少。

减缓AIR和Sliverlight的崛起

javascript毫无疑问当今Web 2.0时代的网络服务的重要组成部分，以提供网络服务吸纳用户的Google绝对希望这种趋势维持下去。无论JS作为客户端语言的路还有多长，V8引擎的出现必定会掀起又一次浏览器JS引擎提速战，这对javascript的延年益寿很有帮助。

相同道理，javascript的持续流行将打击其他商业化产品，例如Adobe的AIR和微软的Sliverlight。网络服务还要依赖装机量为生有很大的风险，当大多数网站都选择了javascript，对AIR和Sliverlight的普及自然造成影响。

至于今后javascript是否能成为主方向，就得看标准的发展和Google Gears的应用范围了。

对微软的将军抽车

微软讨厌今天的javascript，这是毫无疑问的，它灭了vbscript占领网络的美梦，还老是给IE带来负面新闻。但Google Chrome将成为微软的下一个心病——如果微软选择维持IE8的JS引擎速度，则Chrome的傻瓜设计有可能对IE今后的市场占有率造成严重打击；即便他们将JS引擎速度提升到Chrome的水准，和Google打浏览器大战，也会间接帮助了Google的网络服务（尤其是和MS Office与Live服务争锋相对的服务，Google Docs，GMail等等）。

和Google Chrome对战这并非微软的意愿，他们最大的市场——企业局域网，并不需要这么平凡的浏览器升级。

为保IE和Office这些老将不死，微软的车——“漫长的开发期”和“践踏网络标准”两张王牌必须倒下，微软也将不得不在网络上与Google决胜。

真正的“云”，是用户群

我们曾经说过，任何用户信息对于Google来说都是宝贵的。随着互联网发展，要从用户得到涉及隐私的信息越来越难，随着各大开源浏览器的崛起，Google工具栏的吸引力日渐降低，Analytics则是以“站”为中心的服务，Google排名需要新的用户数据来填补这片空白。Google 的答案是发布开源浏览器，再次打开用户上缴个人信息的渠道，事实上，没什么比获得用户的第一手数据对排名和创新更价值了。

Google花费了不少心血，从开源的Firefox与Safari上习得了经典的技能，配合自己的名气，刚出炉就迅速抢占浏览器市场，也算是他们支持Mozilla多年得到的回报之一；今后Firefox的增长是否也会因为Chrome的出现而减缓，我们只能等待结果到来。

杂项

一些与谷歌浏览器有关的小知识⁸⁾

关于标签页

同网站打开的标签通常共享内存，这是为了让javascript能跨页面响应。同时Google Chrome并不能关闭标签页功能。

关于Google Update

安装Google Chrome时一并装入的Google Update还会在Firefox内加插一键更新的插件，如果你不喜欢Google这种走后门的做法，可到注册表的以下地方删除它。

HKEY_CURRENT_USER\Software\MozillaPlugins

或

HKEY_LOCAL_MACHINE\SOFTWARE\MozillaPlugins

删除@google的那个插件即可。

尾声

Google Chrome的确是浏览器市场的一股新风，性能和操作简易性上已让不少人折服，再加上可总结为Hey, it’s from Google!的用户信任度，这热潮恐怕得再刮一阵。

至于客栈，我们已经习惯了Firefox的强大延展性，加上Chrome缺乏书签管理的这个弱势⁹⁾，谷歌还不能成为我们首选。另一方面，别忘了Firefox 3.1和Safari 4都将各自有新的JS引擎，想超越V8并不困难¹⁰⁾，而Opera 10和IE8的出炉又会给这场战斗带来更多不可预计的因素^{11) 12) 13)}……Google还不能笑得太早。

暂时只有这么多，如果有什么新信息会继续加入。

---

¹⁾ 不使用IE8 beta2的主要原因是它的内存占用太夸张了。 – IE8 Beta 2 Fatter Than Firefox and XP

²⁾ Flickr – Google Chrome vs Safari 3.1

³⁾ V8 – Design Elements

⁴⁾ Google and Privacy: A History

⁵⁾ 谷歌浏览器 Google Chrome 免安装绿色版！

⁶⁾ Mozilla’s Thoughts On Google’s Chrome

⁷⁾ Inside Chrome: The Secret Project to Crush IE and Remake the Web

⁸⁾ Google Chrome Tips and Pointers

⁹⁾ 谷歌有“将功能留给网络服务，浏览器不应太复杂的解释” – A fresh take on the browser

¹⁰⁾ JavaScript Performance Rundown

¹¹⁾ Beta Browser Speed Tests: Which Is Fastest?

¹²⁾ Chrome Vs. IE 8

¹³⁾ Google Chrome, Day 2

---

原Wiki版地址（需要登录）：Google Chrome « 捏它营 / NetaInn

难得写一篇与本人正业有关系的文章——你有权说“用某某浏览器的飘”，但你说的话将成为Akismet的Spam证供。