　　谷歌新的Chrome浏览器提供了许多新技术。谷歌承认应该做一些事情赶上Web应用程序目前发展的状态。在阅读了Chrome浏览器的说明文件和查看了这个软件的开源软件代码之后，业内人士Jeff Cogswell提出了他发现的Chrome浏览器中一些有趣的技术方面的概况。

　　终于实现了多处理！

　　虽然Chrome浏览器没有完全解决内存尺寸问题，但是，它通过减少碎片来控制这个问题。在传统的浏览器中，浏览器为一个线程分配一套虚拟内存。当然，每一个标签都占用这个总内存集中的一个内存块。随着你打开更多的标签，系统将分配更多的内存。但是，在你关闭标签的时候，内存没有完全恢复，不足以运行未来的标签。你最终将遇到标准的内存碎片问题。

　　但是，在Chrome浏览器中，每一个标签都有自己的线程。你没有看错，不是每一个Chrome的窗口，而是每一个标签。Cogswell说，我做了20多年的开发工作。我从来没有看到一个窗口能够托管多个线程。但是，Chrome浏览器确实做到了。

　　Cogswell说，如果我目前的标签上有一个网页，我在地址栏输入一个新的URL地址的时候，与那个网页有关的 chrome.exe命令请求就关闭了，并且开始一个新的chrome.exe命令请求。这样做是很完美的：不用输入命令清除分配给已经关闭的网页的内存，Chrome浏览器将完全消除整个线程，然后开始一个新的线程。这是Chrome浏览器阻止内存碎片以及保护和隔离每一个网页的又一种方法。

　　更有趣的是在我装载雅虎网站www.yahoo.com的时候发现了一个奇怪的现象。我看到启动了两个线程。但是，对于谷歌搜索引擎 www.google.com那种比较小的网页，我仅看到了一个流程。当我查看命令行的时候我发现原来输入命令行参数设置了一个插件。那是一个叫做插件路径的额外的参数，设置是c:/windows/system32/macromed/flash/npswf32.dll

　　那是Flash播放器。Chrome为嵌入在网页的Flash播放器启动了另一个线程。当我在Chrome浏览器中保持雅虎网页处于打开状态并且关闭分配给Flash播放器的线程的时候，Chrome在雅虎网页上面显示一个提示并且用一个Flash标识取代了那个 Flash窗口，Flash标识上面有一个失望的面孔。见图1。

　　可以肯定的是雅虎的网页仍然可以使用。换句话说，一个插件崩溃了不会造成浏览器崩溃。对于一次只喜欢打开少量标签的用户来说，这是很好的。为了保证测试的完整性，测试人员关闭了雅虎网页的线程。这一次，整个网页都变黑了，并且网页上有一个失望的表情和信息。见图2

　　同时，其它网页仍在运行。实际上，Chrome浏览器有自己的任务管理器。当在Chrome浏览器中的时候，按下Shift+Esc键可以打开这个任务管理器。这个任务管理器甚至能够让你关闭Chrome浏览器中的线程。

　　编写浏览器软件最困难的部分是渲染引擎。谷歌在这方面做出了正确的选择。谷歌没有重头开始编写渲染引擎，而是选择成熟的和拥有许多优秀功能的现有的开源软件渲染引擎。谷歌选择的是WebKit。有趣的是WebKit是由苹果开发的。苹果自己开发的这个渲染引擎作为其Safari浏览器的基础，然后开放了这个引擎的源代码。现在，谷歌选择了WebKit。

　　这就意味着谷歌Chrome浏览器的渲染引擎没有瑕疵和速度问题。这个渲染引擎速度快并且很好用。测试人员还在chrome浏览器中直接打开了一个SVG（可缩放矢量图形）文件，并且运行得很好。这是很有趣的。因为包括微软和Adobe在内的业内各种力量都在排斥SVG，迫使许多人放弃了SVG的开发。很难说谷歌chrome浏览器会对SVG领域有什么影响。另外，许多人说chrome浏览器的SVG不支持动画。这是一个主要缺陷。我们期待着谷歌解决这个问题。

　　谷歌chrome浏览器支持一种形式的“桌面应用程序”。当你在一个网站上的时候，那就是一个Web应用程序。你可以再桌面上存储一个快捷方式以便打开那个网页。

　　看看这个快捷方式，我可以看到这个启动谷歌的方式，输入一个地址作为一个“应用程序”的参数，像这样：C:/Users/Jeff/AppData/Local/Google/Chrome/Application/chrome.exe

　　Chrome浏览器支持新的名为V8的JavaScript引擎。V8是一个开源软件项目，是谷歌在丹麦的一个开发团队开发的。V8能够把JavaScript汇编成本地的代码。这些代码能够在虚拟机上运行。这些虚拟机甚至能够实施优化的垃圾搜集算法和进行多线程的处理。这远远超出了脚本语言的功能。这是一个全面的运行时间。此外，V8还能够利用名为JSCRE的第三方开源软件库。

　　测试人员称，Chrome浏览器内置了几个很好的工具来帮助Web开发人员。对于入门者来说，Chrome包含了一个全面的JavaScript控制台。见图3

　　Chrome浏览器还有一个JavaScript调试程序。下面是这个调试程序的截屏图像，见图4

　　Google Gears是用于各种浏览器的一个插件，给网站提供隐私存出空间。例如，在过去，在线字处理程序的最大问题是文件存储在服务器的某个地方。如果你使用笔记本电脑或者乘坐飞机，你在有互联网接入能力之前是不能访问这些文件的。

　　Google Gears为这种Web应用程序提供了本地存储从能从而解决了这个问题。除了支持本地存储之外，Google Gears还提供帮助Web开发的更多功能，如本地缓存文件等。

　　Cogswell说，Chrome浏览器给他留下了深刻的印象。谷歌认识到目前Web应用程序的开发已经超过了浏览器的技术水平。需要做一些事情赶上来。竞争的力量将迫使IE和火狐浏览器也这样做。如果是这样，我们将为来的一两年里将从新的浏览器技术进步中受益。

Chrome源码剖析【三】

【三】 Chrome的进程模型

1. 基本的进程结构

Chrome是一个多进程的架构，不过所有的进程都会由老大，Browser进程来管理，走的是集中化管理的路子。在Browser进程中，有xxxProcessHost， 每一个host，都对应着一个Process，比如RenderProcessHost对应着RenderProcess，PluginProcessHost对应着PluginProcess，有多少个host的实例，就有多少个进程在运行。。。

这是一个比较典型的代理模式，Browser对Host的操作，都会被Host封装成IPC消息，传递给对应的Process来处理，对于大部分上层的类，也就隔离了多进程细节。。。

2. Render进程

先不扯Plugin的进程，只考虑Render 进程。前面说了，一个Process一个tab，只是广告用语，实际上，每一个web页面内容（包括在tab中的和在弹出窗口中的...），在 Chrome中，用RenderView表示一个web页面，每一个RenderView可以寄宿在任一一个RenderProcess中，它只是依托 RenderProcess帮助它进行通信。每一个RenderProcess进程都可以有1到N个RenderView实例。。。

Chrome支持不同的进程模型，可以一个tab一个进程，一个site instance一个进程等等。但基本模式都是一致的， 当需要创建一个新的RenderView的时候，Chrome会尝试进行选择或者是创建进程。比如，在one site one process的模式下，如果存在此site，就会选择一个已有的RenderProcessHost，让它管理这个新的RenderView，否则，会创建一个RenderProcessHost（同时也就创建了一个Process），把RenderView交给它。。。

在默认的one site instance one process的模式中，Chrome会为每个新的site instance创建一个进程（从一个页面链开来的页面，属于同一个site instance），但，Render进程总数是有个上限的。这个上限，根据内存大小的不同而异，比如，在我的机器上（2G内存），最多可以容纳20个 Render进程， 当达到这个上限后，你再开新的网站，Chrome会随机为你选择一个已有的进程，把这个网站对应的RenderView给扔进去。。。

每一次你新输入一个站点信息，在默认模式下， 都必然导致一个进程的诞生，很可能，伴随着另一个进程的死亡（如果这个进程没有其他承载的RenderView的话，他就自然死亡了，RenderView的个数，就相当于这个进程的引用计数...）。比如，你打开一个新标签页的时候，系统为你创造了一个进程来承载这个新标签页，你输入www.baidu.com，于是新标签页进程死亡，承载 www.baidu.com的进程诞生。你用baidu搜索了一下，毫无疑问，你基本对它的搜索结果很失望，于是你重新输入 www.google.com，老的承载baidu的进程死亡，承载google的进程被构建出来。这时候你想回退到之前baidu的搜索结果，乐呵乐呵的话，一个新的承载baidu的进程被创造，之前Google的进程死亡。同样，你再次点击前进，又来到Google搜索结果的时候，一个新的进程有取代老的进程出现了。。。

以上现象，你都可以自己来检验，通过观察about:memory页面的信息，你可以了解整个过程（记得每做一步，需要刷新一下about:memory页面）。我唧唧歪歪说了半天，其实想表达的是， Chrome并没有像我YY的一样做啥进程池之类的特殊机制，而是简单的履行有就创建、没有就销毁的策略。我并不知道有没有啥很有效的多进程模型，这方面一点都没玩过，猜测Chrome之所以采取这样的策略，是经过琢磨的，觉得进程生死的代价可以承受，比较可行。。。

3. 进程开销控制算法

说开销无外乎两方面的内容，一为时间，二则空间。Chrome没有在进程创建和销毁上做功夫，但是当进程运行起来后，还是做了一些工作的。。。

节约工作首先从CPU耗时上做起，优先级越高的进程中的线程，越容易被调度，从而耗费CPU时间，于是，当一个页面不再直接面对用户的时候，Chrome会将它的进程优先级切到Below Normal的级别，反之，则切回Normal级别。通过这个步骤，小节约了一把时间。。。

进程的优先级
在windows 中，进程是有优先级的，当然，这个优先级不是真实的调度优先级，而是该进程中，线程优先级计算的基准。在《Windows via C/C++》（也就是《windows核心编程》的第五版）中，有一张详细的表，表述了线程优先级和进程优先级的具体对应关系，感觉设计的很不错，我就不罚抄了，有兴趣的自行动手翻书。。。

当然这只是一道开胃小菜，满汉全席是控制进程的工作集大小，以达到降低进程实际内存消耗的目的（Chrome为了体现它对内存的节约，用了“更为精确”的内存消耗计算方法...）。提到这一点， Chrome颇为自豪，在文档中，顺着道把单进程的模式鄙视了一下，基本意思是：在多进程的模式下，各个页面实际占用的内存数量，更容易被控制，而在单进程的模式下，几乎是不能作出控制的，所以，很多时候，多进程模式耗费的内存，是会小于多线程模式的。这个说法靠不靠谱，大家心里都有谱，就不多说了。。。

具体说来，Chrome对进程工作集的控制算法还是比较简单的。首先，在进程启动的时候，需要指明进程工作的内存环境，是高内存，低内存，还是中等内存，默认模式下，是中等内存（我以为Chrome会动态计算的，没想到竟然是启动时指定...）。在高内存模式，不存在对工作集的调整，使劲用就完事了；在低内存的模式下，调整也很简单，一旦一个进程不再有页面面对观众了，尝试释放其所有工作集。相比来说，中等模式下，算法相对复杂一些，当一个进程从直接面对观众，沦落到切换到后台的悲惨命运，其工作集会缩减，算法为： TargetWorkingSetSize = (LastWorkingSet/2 + CurrentWorkingSet) /2；其中，TargetWorkingSetSize指的是预期降到的工作集大小，CurrentWorkingSet指的是进程当前的工作集（在 Chrome中，工作集的大小，包含私有的和可共享的两部分内存，而不包含已经共享了的内存空间...），LastWorkingSet，等于上一次的 CurrentWorkingSet除以DampingFactor，默认的DampingFactor为2。而反之，当一个进程从幕后走向台前，它的工作集会被放大为 LastWorkingSet * DampingFactor * 2，了解过LastWorkingSet的含义，你已经知道，这就是将工作集放大两倍的另类版写法。。。

Chrome的Render进程工作集调整，除了发生在tab切换（或新页面建立）的时候，还会发生在整个Chrome的idle事件触发后。Chrome 有个计时器，统计Chrome空闲的时长，当时长超过30s后（此工作会反复进行...），Chrome会做一系列工作，其中就包括，调整进程的工作集。被调整的进程，不仅仅是Render进程，还包括Plugin进程和Browser进程，换句话描述，就是所有Chrome进程。。。

这个算法导致一个很悲凉的状况，当你去蹲了个厕所回到电脑前，切换了一个Chrome页面，你发现页面一片惨白，一阵硬盘的骚动过后，好不容易恢复了原貌。如果再切，相同的事情又会发生，孜孜不倦，直到你切过每一个进程。这个惨案发生的主要原因，就是由于所有Chrome进程的工作集都被释放了，页面的重载和Render需要不少的一坨时间，这就大大影响了用户感受，毕竟，总看到惨白的画面，容易产生不好的情绪。强烈感觉这个不算一个很出色的策略，应该有一个工作集切换的底限，或者是在Chrome从idle中被激活的时候，偷偷摸摸的统一扩大工作集，发几个事件刺激一下，把该加载的东西加载起来。。。

整体感觉，Chrome对进程开销的控制，并不像想象中的有非常精妙绝伦的策略在里面，通过工作集这总手段并不算华丽，而且，如果想很好的工作的话，有一个非常非常重要的前提，就是被切换的页面，很少再被继续浏览。个人觉得这个假设并不是十分可靠，这就使得在某些情况下，产生非常不好的用户体验，也许Chrome需要进一步在这个地方琢磨点方法的。。。

Tag标签: Chrome

posted on 2008-10-12 00:34 duguguiyu 阅读(1673) 评论(2) 编辑收藏网摘所属分类: C++

#1楼 2008-10-12 10:16 Zhuang miao

详细回复引用查看

#2楼 2008-10-13 12:50 bzero [未注册用户]

不错，
我也打算写一个系列，目前还在研究源码中。
乱乱的写了点。
下面是我的BLOG
http://blog.csdn.net/bzero1982

2008年10月20日

chrome源码解析系列:Chrome消息系统(1)收藏

chrome 中有很多闪光点地方,它的消息系统就一快纯金，要看chrome 源码，必须要过消息系统这关。本来这本部打算写在上一章的,考虑内容涵盖范围太广的,打算另开一章来写 chrome的消息系统，回头在去上一章做个比较有概括力的总结。本章的思路是按照一下逻辑来展开的： 1：消息系统的概述(消息系统静态模型和动态模型的一个简单的介绍) 2：一个消息系统的生死因果（细说MessageLoopUI类） 3：消息系统的分类（对chrome的几种消息做消息介绍）这是消息系统的第一个部分，先看看和消息相关的静态类图:(图片画的太大了，这张看的不是很清楚，需要大图片，可以去我的新浪空间去看大图片)上面那张图片涉及到设计软件时几种采用的伎俩，下面会一一分析：伎俩一：handle-body,pimpl, 桥接MessageLoop基本就是MessagePump的一个代理类，扩充了一些MessagePump没阅读全文>

发表于 @ 2008年10月20日 19:11:00|评论(3)|编辑|

编译Chrome源代码