存档

文章标签 ‘chrome’

说说Google的开源浏览器Google Chrome

2008年9月2日 2 条评论

Google今天在官方blog上面透露,他们“无意中”把Google自己的浏览器Google Chrome的漫画泄漏到了网上(看不懂E文的看这里)。这个漫画相当有趣,晚上发现cnbeta上面已经有人放出来了漫画的中文版,没看过的可以先看看。

说说几个吸引我的地方。因为我的经验主要是Firefox,对IE缺少研究,所以讨论也是基于对于Firefox的了解。

“现在的浏览器本质上是单线程的”

一针见血的论断,之前在研究Firefox插件的时候,发现了Firefox的这个设计缺陷(或者叫特性?)。Firefox虽然使用了多线程进行网络IO,但是界面的渲染仍然是单线程的,而这个单线程的本质原因是因为Javascript引擎是单线程的。单线程有一个好处就是编程简单,尤其对于插件来说,不需要头疼同步问题。但是单线程也有严重的问题,就如同在漫画中描述的那样,任何一个页面上的Javascript问题都会导致整个浏览器等待,表现就是界面停滞甚至死掉。现有的解决方案之一是异步模型,或者叫Event Driven的模型,例如Ajax就是对于网络IO的异步化,也有一些模拟的实现来实现Javascript的线程,比如使用SetInterval。但是因为Javascript规范缺少线程模型,引擎也很难做成多线程的,这个限制也极大地制约了浏览器和网络应用的性能和响应。

对于此问题,Google的解决方案是一个折衷:多进程。这样既不需要修改Javascript引擎,同时可以获取到并发的优点。其实我对于漫画当中对于多进程对于节省系统资源的论断持保留态度,对其他宣称的好处也是有保留的赞成,但是我承认这是一个正确的设计决定。用多进程的模式实现的浏览器,对于将来潜在的插件的实现者来说,是一个极大的模型简化。使用多线程的Javascript引擎(如果有的话),我相信带来的问题会比解决的问题更多。

多进程模型

接下来就是说另一个有趣的地方:多进程。从漫画当中透露出来的消息来看,这个多进程模型是1拖N的模式。每一个页面都将是一个单独的进程。因此我开始怀疑,Google Chrome如何实现标签页浏览。也许根本就没有实现,或者实现了一个假的。如果将标签页浏览实现在Chrome任务管理器当中,就必须有一种IPC机制来让管理器来将窗口共享给子进程来渲染,这个我还没有想到一种可以跨平台的实现方式。

Chrome任务管理器

非常cool,非常值得期待的组件,如果其功能真的如同其在漫画当中宣称的那样棒的话。

这个也是我对于Firefox最期待的功能之一。目前虽然有FireBug作为替代方案,但是FireBug仍然是内建在浏览器内部的。我希望的是一个非侵入式的任务管理器,一个独立于浏览器之外的组件来实现对于浏览器执行流程的监控。这样的好处之一就是可以在浏览器失去响应或者崩溃的时候仍然保留对于Javascript执行状况的监测。理想状况下我期望如同Windows的调试器一样,attach到一个失去响应的进程然后查看其调用栈或者执行时间,进而可以了解到浏览器各个组件的执行状况,发现引起问题的组件。

实现这种功能,需要Javascript引擎的协助。引擎必须提供一种机制来中断当前的执行流程,并能够使用某种机制将其内部状态导出。这是一个不小的工程。但是由于Google的介入,也许这个并非不可能之事。

名字和核心

Google Chrome。当我看到这个名字的时候,我就以为这个是基于Gecko的另一个版本——因为Gecko(Firefox所使用的核心)的核心组件之一就是Chrome。或者说,Firefox本身就是一个Chrome。

但是根据一些透漏的信息,Google Chrome使用的是WebKit内核——一个宣称比Gecko更快、更高效的内核。这个也比较靠谱,毕竟Google的Android上面使用的也是WebKit内核。

野心

随着浏览器的发布,Google用户联网占领桌面,并且试图逐渐替代桌面的野心昭然若揭(当然很早之前就已经是司马昭之心了)。一个中央管理组件协调各个网络应用;每个网络应用占用一个进程;可以查看任何一个应用的资源占用和响应时间;再加上从Google Doc到Google Mail的一条线的网络应用……

很好很强大的新桌面和新系统。


到了那个时候,你的所有安全,就全部寄托在了几个在网络上明文传送的Cookie。

标签: , , ,