解读Google Chrome
尽管Google进入浏览器市场的消息刚刚发布了两天，业界已经充斥了关于Chrome的新闻。大牌媒体如Wired，也在一天放出两篇报道和评论。Slashdot上两天三个新闻，很快就吸引了超过500条评论。Google浏览器很轻易的就成为暑假后无所事事的业界的头条新闻。
那么Google Chrome是什么？Google进入已经有四家主要竞争者的浏览器市场意欲何为？Chrome和它的竞争对手的未来将会是怎样的？Chrome会对用户产生怎样的影响？综合官方发布漫画，多家职业媒体的报道和slashdotter的评论，我就做一下大胆的说明和预测。
【WHAT】
Chrome是什么？从不同的就角度出发，有很多种不同的答案。对于一般用户来说，Chrome是来自全球访问量最高，有大量免费高质量服务的Google的浏览器；对于市场分析家来说，是Google商业模式的扩展；对于开发者来说，Chrome是开源的，符合W3C标准的多线程，多进程浏览器；对于Mozilla来说，Chrome是佃户主子自己种的一块地；对微软来说，Chrome是个坏消息；对苹果来说，好吧，对苹果来说似乎没什么重大意义，Google搞浏览器第一对他们的核心业务没什么影响；第二对他们来说也很难算得上是新闻——毕竟G家老早就宣布Android里会有一个基于Webkit，自主产权的移动浏览器；第三Apple需要忙的事情很多，例如九月份谣传的新产品，还有第四季度Android发布后iPhone的市场策略。
具象化的说，Chrome是一个基于WebKit渲染引擎的开源浏览器。WebKit是浏览器市场四种主流渲染引擎之一（其他三种分别为被Firefox使用的Gecko，被IE使用的Trident和被Opera使用的Prestp），WebKit最主要的产品包括Mac众使用的Safari和iPhone使用的MobileSafari，诺基亚的一系列手机浏览器，当然，还有现在的Chrome。
与大部分开源浏览器类似，Chrome是一个可扩展跨平台并且源码完全公开的软件。从标准的角度来说，基于WebKit的Chrome应当与同胞兄弟Safari类似，能够很好的支持W3C标准，处理一些没有明确解释的W3C条目时的行为也应当与Safari相近。
Chrome自然有它特殊的地方。
首先，从软件架构上讲，Chrome是一个多进程浏览器。
最近五年来，单进程多分支一直是浏览器开发的主流思想。所谓单进程是指对于操作系统来说，同一时间只有一个浏览器进程运行。多分支是指页面（tab）浏览。在这个策略中，单进程是为了节省系统资源，避免过多的进程和重复的Global data拖垮操作系统。多分支则是在UI上对单一进程的补偿，允许用户同时浏览多个页面。使用这种思想的浏览器有Firefox，Opera和Safari。IE7因为种种原因，则是一个多进程单进程混合体：每一个新窗口是一个新进程，在窗口里每一个tab是一个分支。因此用户可以在单进程和多进程之间切换，但微软没有把这个概念在UI上表现的很明白，并且有时候IE7的多个进程之间是共享数据的。
多进程浏览器则是浏览器的最初形态。在IE6以及IE6之前的时代，浏览器一直是多进程架构，每开一个新窗口就意味着向操作系统添加一个新进程。后面我会对比这两种架构的优缺点和Google使用多进程架构的原因。
另外一个Google强调的新功能是一个叫做V8的JavaScript渲染引擎。该引擎的亮点在于更快速更强壮的JavaScript解析。V8是一个非常反传统的JavaScript引擎，它能够在后台动态的对JS的对象进行分类——一个在其他高级语言中很常见但JS本身不支持的特性。V8对JS的解析不是基于反复loop源代码进行解释而是直接将JS代码编译成机器码运行。换句话说，V8引擎实际上可以看做是JS的扩展和编译器——而传统上类似于JS的解释型语言恰恰是不需要编译器的。最后，高级语言的内存管理效能一直是决定其运行效率的重要因素，而当前的JS虚拟机在这方面做的比较基本，对内存的回收也非常保守。V8使用的是非常强势的内存管理策略，一切在运行堆栈里无用的数据都会被强行回收，从而可以大大提高JS代码的运行效率。
【WHY】
浏览器市场并不是一个易与的地方。它的竞争很激烈——所有的玩家（或许除去Opera之外）都是行业巨头；它的直接收益有限——无论是开源还是闭源，这年头浏览器免费已经算是行规，虽然你可以说IE的费用算在了Windows里，但用户使用时不需要付出额外的费用，所以靠着软件收费是不可能了。而用户对浏览器内置广告或xx工具条之类的寄生软件也是100个不愿意，所以单纯靠一个浏览器是很难有财政上的直接收益；浏览器的开发成本高昂，浏览器本身虽然概念简单，功能也很单一，但它面对的则是有着无数种可能性的互联网。接近100%正确的渲染内容，保证稳定，强化用户安全都是挑战性很高的软件工程课题，需要很大的人力物力来支持。所以基本上来说，开发浏览器很是一个吃力不讨好的工作。
那么Google作为一个服务公司，为什么要来趟这潭浑水？
最重要的原因，恐怕就像Google在漫画里提到的，目前的浏览器已经无法跟上Google的WebApp的开发脚步。当前的浏览器已经成为更强大的WebApp诞生的瓶颈。传统的浏览器四大家族，IE, Firefox(Netscape), Safari和Opera都诞生于前Web 2.0时代，当时的网站还是完全基于超链接导航和服务器端运作的方式与用户交互，JavaScript是制造鼠标悬停动画或其他一些小功能的附属品，人们还没见识过Ajax，网站仍然是一系列网页组合成的文档集合。
然后是Web 2.0。几年之间，一系列新的概念和架构在传统网站的基础上落成。JavaScript不再是娱乐小品，它进而开始掌管更复杂的任务，表单验证，数据处理乃至控制整个客户端的行为。Ajax的兴起模糊了网页和网页之间的界限，服务器和客户端之间传输的内容不再是成型的一个一个的网页，而成为可以被客户端处理调用的一组组数据。通过超链接从一个页面进入另一个页面已经是昨日的概念，Ajax可以让用户在同一个页面上获得所有需要的信息。而云计算和数据海洋更是将传统互联网的分类－导航－浏览的模式战的支离破碎，一切用户活动都是在个人化的信息聚合，搜索的过程中进行。高速互联网接入进一步模糊了本地存储的数据和远程存储数据的界限。
Google，无疑是站在这场革命的风口浪尖上。Google是应用软件网络化的的拥护者和重要先行者之一。但随着WebApp的日益复杂，开发者频频撞上浏览器性能极限的大墙：尽管如今的计算机硬件平台已经大大提升，可浏览器仍然无法有效的利用这些硬件资源，一个复杂的WebApp虽然能写出来，但可能根本无法在用户的机器上以令人满意的速度运行。
更何况，当前浏览器都诞生于前WebApp时代，它们最底层的架构和策略仍然停留在网页－超链接－网页的橱窗式用户使用模型上，因此在面对更复杂的，拥有更大数据量，更多互动以及相应的更多bug的WebApp时，传统浏览器的底层策略开始变得力不从心。
因此，换句话说：Google能开发出更强的WebApp，但苦于没有足够强大的平台来发布这些它们。如此看来，Google推出浏览器也就不足为奇了。
那么Google的浏览器好在哪里？
Google对Chrome的着手方式与其他浏览器开发团体非常不同，Google与其说是开发一个浏览器，倒不如说是在开发一个WebApp使用的操作系统。因为从各种方面来说，Chrome的架构和策略都更接近OS，强调在使用Web Application时的性能，稳定和安全性。
首先是渲染引擎的选择。在四大渲染引擎中，Google的选项只有两个：驱动Firefox的Gecko和驱动Safari系列的WebKit。鉴于Google和Mozilla长期的合作关系（Google基本上是Firefox开发团队Mozilla的财主，银行），选择Gecko似乎是理所应当的。然而，无论是自己的移动平台Android还是新浏览器Chrome，Google都选择了WebKit。
技术上讲，传承自95年的Netscape，诞生于98年前后的Gecko已经是一个相当落后的核心，据一些开源社区的活跃者反映，Gecko的源码难以理解，管理困难，对新手很不友好，还有很多bug，即使是大获成功的Firefox，也长期被一些Gecko核心所固有的bug困扰。另外更重要的一点，Gecko的资源耗费很高，从根本上不符合移动浏览器或多进程浏览器的概念。
而多进程浏览器也是一个有意思的选择，特别是在单进程多分支架构大为流行的今天，如IE6般的多进程浏览器颇有点复辟的意味。然而事实上，单进程多分支尽管有着节省资源的优势，但却有着强壮程度不足的坏处。假如在使用过程中一个页面（tab）因为种种原因坏掉了，那么代价就是整个浏览器失去响应进而强行退出。估计不少人都有开了一堆tab其中有一个因为坏的代码之类死掉了，结果导致整个浏览器非法操作的经验吧。虽然现代浏览器都有恢复页面的功能，但这基本上只能保护橱窗式用户模型。恢复页面对于应用型操作却没有太大意义。想象一下假如你在论坛写一个帖子，这时后台有一个坏页面导致浏览器崩溃，那么即使恢复了页面，你写的帖子也都丢失了，这对于WebApp应用就是一个不可容忍的错误。
Google Chrome的多进程架构，就是意图从根本上解决这个问题，一个页面崩溃了，并不影响到整个浏览器，你在其他页面写的东西不会丢失，网页应用不会离线，一切照常使用。这种隔离开的多进程策略叫做Sandboxing，并非什么新发明，过去10年来的操作系统架构都是基于这种理念。
虽然从理论上讲多进程架构会耗费更多的资源，但今天的计算机硬件已经不是上世纪90年代可以比拟的了。多核处理器，2GB+内存逐渐已经成为主流，十几个甚至几十个优化过的浏览器进程通常是不会对你能玩Crysis的机器造成性能上的影响的。况且，单进程浏览器就一定节省资源吗？倒也未必。
单进程多分支浏览器有一个很重要的开发指标就是内存回收的能力，当用户关闭一个分支（tab）时，浏览器就要负责清空这个tab先前所占用的空间。理想状况下，单进程浏览器所耗费的资源等于浏览器核心所占内存＋当前所有打开的tab所占内存。然而，这仅仅时理想状态。在很多很多时候，浏览器没有办法完全回收你关闭的tab所占用的空间，毕竟判断，回收内存是一个很复杂的过程，更不可能100%准确。这些已经走人却没有交钥匙的tab会让单进程浏览器在内存的体积急剧膨胀起来。对于橱窗式用户造成的影响或许不会很厉害，但对于数据流量很大的应用型用户这些回收失败的空间可能很快就会拖垮哪怕是能玩Crysis的机器。
而多进程浏览器的废弃空间释放是交给OS来做的。你关闭一个进程，操作系统就会清空掉这个进程之前所占用的空间。由于操作系统直接掌管底层的硬件资源分配，它的内存管理远比进程内的内存回收来的有效。
多进程为WebApp提供了一个坚实的基础，V8引擎则是提高WebApp性能的终极武器。
JavaScript作为一种解释型语言，常年被一些解释型语言无法逾越的通病所困扰。其中最大的问题在于运行效率太低。你常常会发现即使在你的Crysis可玩的机器上，一些包含复杂JavaScript功能的页面也运行的磕磕绊绊。因为解释型语言是由虚拟机一条一条运行，而不是像编译型语言一样编译成机器码直接在CPU上跑，因此很难提高性能，而虚拟机本身的质量也对JS的运行效率有重大影响。Google Chrome使用的V8引擎，则绕过虚拟机这个概念，干脆把自己搞成一个JS编译器，将源代码编译成机器码，然后放到CPU上跑，如此将一个解释型语言强行搞成编译型语言运行，我不得不说佩服佩服。如此一来效率肯定是大幅提升，但也不是没有问题存在。
首当其冲的就是容错能力的问题。解释型语言相对于编译型语言的一个优势在于其对代码错误的容忍能力很好。一些语法不严格或算法结构不够好的代码可能不会对功能造成太致命的影响。然而一旦要编译这种代码，十有八九是要出错。所以在Chrome上运行的代码可能错误容忍度要比其他浏览器低一些。当然，对聚集顶尖开发人员的Google来说写写点正确的代码不是问题，但就怕苦了我这种半道出家写代码马马虎虎的人。而且毕竟互联网上符合标准的代码少，半道出家的代码写手多。
不过至于这个编译能力到底怎样，恐怕只能靠日后的实际测试来确定了。
动态分类是大部分高级语言都具备的功能，JS诞生之初没有想到有朝一日自己会担当客户端幕后主脑这一重任，因此出于简化结构易于开发的考量，没有植入这一能力，这也是导致其效率低下的原因之一。V8引擎通过在编译过程中动态将对象根据属性分类，（希望）可以解决这一问题。
最后V8还有强势的内存回收策略。与传统JS虚拟机较为保守的内存回收策略不同，在V8中，任何引擎不认识不了解的对象都会被清洗掉，这种屠杀式的内存回收风格当然会大大提高JS的内存应用效率，然而同样的，其对质量不高的代码的容忍能力尚待考验。
这三大特性证明了Google对于JS引擎的唯一目标：快速快速再快速。所以等Chrome发布了，Google就终于可以在上面推出基于JavaScript的Crysis了。
（未完待续）
“解读Google Chrome”