Chrome源码剖析

Chrome源码剖析序开源是口好东西，它让这个充斥着大量工业垃圾代码和教材玩具代码的行业，多了一些艺术气息和美的潜质。它使得每个人，无论你来自米国纽约还是中国铁岭，都有机会站在巨人的肩膀上，如果不能，至少也可以抱一把大腿。。。现在我就是来抱大腿的，这条粗腿隶属于Chrome（开源项目名称其实是Chromium，本来Chrome这个名字就够晦涩了，没想到它的本名还更上一层楼...），Google那充满狼子野心的浏览器。每一个含着金勺子出生的人都免不了被仰慕并被唾骂，Chrome也不例外。关于Chrome的优劣好坏讨论的太多了，基本已经被嚼成甘蔗渣了，没有人愿意再多张一口了。俗话说，内行看门道外行看热闹，大部分所谓的外行，是通过使用的真实感受来评定优劣的，这无疑是最好的方式。但偏偏还是有自诩的内行，喜欢说内行话办外行事，一看到Chrome用到多进程就说垃圾废物肯定低能。拜托，大家都是搞技术的，你知道多进程的缺点，Google也知道，他们不是政客，除了搞个噱头扯个蛋就一无所知了，人家也是有脸有皮的，写一坨屎一样的开源代码放出来遭世人耻笑难道会很开心？所谓技术的优劣，是不能一概而论的，同样的技术在不同场合不同环境不同代码实现下，效果是有所不同的。既然Chrome用了很多看上去不是很美的技术，我们是不是也需要了解一下它为什么要用，怎么用的，然后再开口说话？（恕不邀请，请自行对号入座...）。。。人说是骡子是马拉出来遛遛，Google已经把Chrome这匹驴子拉到了世人面前，大家可以随意的遛。我们一直自诩是搞科学的，就是在努力和所谓的艺术家拉开，人搞超女评委的，可以随意塞着屁眼用嘴放屁，楞把李天王说是李天后，你也只能说他是艺术品位独特。你要搞科学就不行，说的不对，轻的叫无知，重的叫学术欺诈，结果一片惨淡。所以，既然代码都有了，再说话，就只能当点心注点意了，先看，再说。。。我已经开始遛Chrome这头驴了，确切一点，是头壮硕的肥驴，项目总大小接近2G。这样的庞然大物要从头到脚每个毛孔的大量一遍，那估计不咽气也要吐血的，咱又不是做Codereview，不需要如此拼命。每一个好的开源项目，都像是一个美女，这世界没有十全十美的美女，自然也不会有样样杰出的开源项目。每个美女都有那么一两点让你最心动不已或者倍感神秘的，你会把大部分的注意力都放在上面细细品味，看开源，也是一样。Chrome对我来说，有吸引力的地方在于（排名分先后...）：1.它是如何利用多进程（其实也会有多线程一起）做并发的，又是如何解决多进程间的一些问题的，比如进程间通信，进程的开销；2.做为一个后来者，它的扩展能力如何，如何去权衡对原有插件的兼容，提供怎么样的一个插件模型；3.它的整体框架是怎样，有没有很NB的架构思想；4.它如何实现跨平台的UI控件系统；5.传说中的V8，为啥那么快。但Chrome是一个跨平台的浏览器，其Linux和Mac版本正在开发过程中，所以我把所有的眼光都放在了windows版本中，所有的代码剖析都是基于windows版本的。话说，我本是浏览器新手、winapi白痴以及并发处理的火星人，为了我的好奇投身到这个溜驴的行业中来，难免有学的不到位看的走眼的时候，各位看官手下超生，有错误请指正，实在看不下去，回家自己牵着遛吧。。。扯淡实在是个体力活，所以后面我会少扯淡多说问题。。。关于Chrome的源码下载和环境配置，大家看这里（windows版本），只想强调一点，一定要严格按照说明来配置环境，特别是vs2005的补丁和windowsSDK的安装，否则肯定是编译不过的。。。最后，写这部分唯一不是废话的内容，请记住以下这幅图，这是Chrome最精华的一个缩影，如果你还有空，一定要去这里进行阅读，其中重中之重是这一篇。。。随着Web浏览器重要性的日益突出，恶意软件、木马、间谍软件等网络攻击也呈现逐渐的上升。而面对如此众多的潜在威胁，为了确保用户的安全性和稳定性，浏览器不得不改进浏览器的性能，其中之一就是向用户提供多进程浏览。在浏览器中添加多进程浏览功能之后，即使是浏览器其中的一个进程出现了崩溃现象，其他的进程也不会受到影响。例如，如果一个网站中有漏洞或包含恶意代码，它就有可能摧毁当前运行在这个网站上的标签，但是它却不会影响其他的进程或整个浏览器。据国外媒体报道，随着时代的进步，互联网已经成为人们生活的重要组成部分，而Web浏览器也理所应当地成为计算机等设备中最为重要的软件。不过，随着Web浏览器重要性的日益突出，恶意软件、木马、间谍软件等网络攻击也呈现逐渐的上升。而面对如此众多的潜在威胁，为了确保用户的安全性和稳定性，浏览器不得不改进浏览器的性能，其中之一就是向用户提供多进程浏览。在浏览器中添加多进程浏览功能之后，即使是浏览器其中的一个进程出现了崩溃现象，其他的进程也不会受到影响。例如，如果一个网站中有漏洞或包含恶意代码，它就有可能摧毁当前运行在这个网站上的标签，但是它却不会影响其他的进程或整个浏览器。目前，有很多的浏览器厂商采用了多进程标签浏览的概念，其中包括谷歌Chrome、微软IE8和MozillaFirefox，而众多基于WebKit的浏览器也将在不久之后采用多进程标签浏览这个功能，例如苹果的Safari浏览器。不过，虽然上述浏览器都采用多进程标签浏览概念，但是他们在浏览器中执行多进程标签浏览的方法却是不同的。#1、谷歌Chrome/Chromium的多进程架构谷歌Chrome是首款采用多进程浏览概念的浏览器，它还具备最为复杂的用于隔离浏览器各个组成部分的系统。在Chrome中，谷歌通过outofprocessplugins（OOPP）功能将所有的插件进程（如Flash、Java、PDF阅读器等）与的浏览器进程隔离，进而提升Chrome浏览器的安全性。也就是说，即使是Chrome中有插件出现崩溃现象，也并不会影响整个浏览器的运行总得来讲，谷歌Chrome和Chromium中包含以下4中主要的进程类型：*浏览器进程——用于处理用户界面和管理所有其他的进程，其运行在浏览器的最顶级；*渲染进程——用于处理独立浏览器标签中的渲染，值得注意的是，一个渲染进程能够处理多个标签；*插件进程——每个浏览器插件如AdobeFlash或Java都运行在它们自己的独立进程中，这些插件进程能够与各自的渲染进程互通；*扩展进程——浏览器中的扩展也拥有各自的独立进程，以避免互相干扰。图1：谷歌Chrome多进程架构#2、微软IE8Loosely-CoupledIE（LCIE）在最新一代浏览器IE8中，微软添加了被称为“Loosely-CoupledIE（LCIE）”的架构。通过Loosely-CoupledIE（LCIE）架构，IE8将主要的浏览进程与渲染进程相隔离。主要的进程处理浏览器、用户界面和框架（窗口），用于存储选项卡。在IE8中，多个选项卡是运行在相同的进程中的，不过不同安全级别的选项卡是相互分开的。ActiveX空间是通过选项卡进程进行处理的。图2：微软IE8多进程架构图（3）#3、MozillaElectrolysis和Out-of-process插件相较于谷歌Chrome和微软IE8，MozillaFirefox是步入多进程行列中较晚的一款浏览器，其中所包含的多进程架构也不如Chrome或IE复杂。Mozilla基金会在Firefox中添加多进程架构的目的就是隔离浏览器插件和浏览器的主要进程，项目代号为“Electrolysis”，正处于早期的测试阶段。目前，Firefox3.6.4betabuilds中已经包含了多进程处理能力。图4：Firefox中的多进程架构#4、WebKit2中的多进程前段时间，WebKit团队宣布，在即将发布的WebKit2中将会包含多进程浏览能力。换句话也就是说，采用WebKitWeb渲染引擎的大量浏览器中都将会引进多进程浏览功能。虽然谷歌Chrome/Chromium使用的是WebKit引擎，不过他们的多进程架构是不同的。在Chrome中，谷歌在每个渲染进程中都包含一个WebKit渲染引擎，而WebKit小组则计划将WebKit2渲染引擎自身分裂到多个进程中。在WebKit2采用多进程浏览模型之后，网页的内容（JavaScript，HTML，以及布局等）将各自拥有独立的进程，这一机制是通过两个主要的子系统（CoreIPC和DrawingArea）来支持的。WebKit2中的多进程浏览模型和GoogleChrome的最大不同在于，WebKit直接把独立进程模型放进了一个框架中，因此也能被其他客户端使用。事实上，历史上除了浏览器之外，苹果的邮件客户端和微软的个人信息管理软件都使用过WebKit内核。WebKit还是其它几个移动浏览器的基础，包括iPhone操作系统、谷歌的Android、Symbian手机使用的S60Web浏览器和PalmPre。图1：WebKit中的多进程架构Chrome的多线程模型(一)0.Chrome的并发模型如果你仔细看了前面的图，对Chrome的线程和进程框架应该有了个基本的了解。Chrome有一个主进程，称为Browser进程，它是老大，管理Chrome大部分的日常事务；其次，会有很多Renderer进程，它们圈地而治，各管理一组站点的显示和通信（Chrome在宣传中一直宣称一个tab对应一个进程，其实是很不确切的...），它们彼此互不搭理，只和老大说话，由老大负责权衡各方利益。它们和老大说话的渠道，称做IPC（Inter-ProcessCommunication），这是Google搭的一套进程间通信的机制，基本的实现后面自会分解。。。Chrome的进程模型Google在宣传的时候一直都说，Chrome是onetaboneprocess的模式，其实，这只是为了宣传起来方便如是说而已，基本等同广告，实际疗效，还要从代码中来看。实际上，Chrome支持的进程模型远比宣传丰富，你可以参考一下这里，简单的说，Chrome支持以下几种进程模型：1.Process-per-site-instance：就是你打开一个网站，然后从这个网站链开的一系列网站都属于一个进程。这是Chrome的默认模式。2.Process-per-site：同域名范畴的网站放在一个进程，比如就属于一个域名内（google有自己的判定机制），不论有没有互相打开的关系，都算作是一个进程中。用命令行--process-per-site开启。3.Process-per-tab：这个简单，一个tab一个process，不论各个tab的站点有无联系，就和宣传的那样。用--process-per-tab开启。4.SingleProcess：这个很熟悉了吧，传统浏览器的模式，没有多进程只有多线程，用--single-process开启。关于各种模式的优缺点，官方有官方的说法，大家自己也会有自己的评述。不论如何，至少可以说明，Google不是由于白痴而采取多进程的策略，而是实验出来的效果。。。大家可以用Shift+Esc观察各模式下进程状况，至少我是观察失败了（每种都和默认的一样...），原因待跟踪。。。不论是Browser进程还是Renderer进程，都不只是光杆司令，它们都有一系列的线程为自己打理各种业务。对于Renderer进程，它们通常有两个线程，一个是Mainthread，它负责与老大进行联系，有一些幕后黑手的意思；另一个是Renderthread，它们负责页面的渲染和交互，一看就知道是这个帮派的门脸级人物。相比之下，Browser进程既然是老大，小弟自然要多一些，除了大脑般的Mainthread，和负责与各Renderer帮派通信的IOthread，其实还包括负责管文件的filethread，负责管数据库的dbthread等等（一个更详细的列表，参见这里），它们各尽其责，齐心协力为老大打拼。它们和各Renderer进程的之间的关系不一样，同一个进程内的线程，往往需要很多的