编译Chrome源代码

编译Chrome源代码

前几天下载了Chrome的源代码,源代码加上各种资源文件打包都有400多兆,展开有1G多,Build完需要有10G多的硬盘!但是Chrome的安装包又很轻巧,所以我想将来还是应该出一个简洁版的源代码包,至少可以只编译产生一种语言支持的结果,10G的build输出实在有点可怕。

因 为我的Vista上有Visual Studio 2008,就用VS2008来编译,失败了。官方文档上说只支持VS2005,没办法,只好再安装了VS2005,打开sln文件,居然报告说有. csproj项目文件无法识别,我以为所有的code都是C/C++,所以安装VS2005的时候为了省空间没有安装C#支持,没想到chrome源代码 里面居然也有C#项目。强行编译,当然还是失败,不过看出错提示说是我的Windows SDK没有和VS2005绑定,所以又安装VS2005的C#支持和一个Windows SDK 6.0,用它带的Visual Studio Registration工具将其和Visual Studio 2005挂上好,最后终于编译通过了。

面对打开的几百个项目文件和浩如烟海的源代码,都不知道从何看起,也就是编译着玩吧,别谈看了。

需要说明一下,Chrome中有个rlz模块的code不是open的,而这个rlz模块很有可能作的事情就是秘密向Google汇报一些你机器上的情况。

至 于Chrome不做提示自动更新,秘密Phone Home之类的功能,就是Google一贯的风格,安装的时候可以仔细看看EULA。在BBS上有人说如果你看不惯这些东西只能说Google的产品不适 合你,爱用不用,是你的问题,而不是Google的问题,我不确定说这样的话的人是Google的粉丝还是员工,从一个软件开发者的角度来看,这样的言论 和态度就是所谓的脑残,开发软件的目的是为用户服务,如果用户抱怨却反过来怪用户,这样的软件开发是没有意义的。


http://morganchengmo.spaces.live.com/blog/cns!9950CE918939932E!3371.entry


http://dev.chromium.org/developers



http://dev.chromium.org/developers/how-tos/getting-started


 谷歌浏览器的源码分析(26) 

http://blog.csdn.net/caimouse/archive/2008/10/14/3075665.aspx




Chrome源代码隐含的一些技术趣味

添加时间: 2008-9-12 12:12:19  作者: 不详  阅读次数:0   来源: CCW编译 <script src="http://www.d9soft.com/hits.asp?id=25769&t=4"></script>


        

  谷歌新的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

  --app=http://mail.google.com/mail

  JavaScript引擎: V8

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

  为开发人员提供的JavaScript

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

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

  Google Gears插件

  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<script type="text/javascript">AddFeedbackCountStack("3111601")</script>)|编辑|

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页