Chrome源码剖析精编版.docx

Chrome源码剖析精编版.docx

《Chrome源码剖析精编版.docx》由会员分享，可在线阅读，更多相关《Chrome源码剖析精编版.docx（29页珍藏版）》请在冰豆网上搜索。

Chrome源码剖析精编版

另有”GoogleChrome浏览器架构解析”

Chrome源码剖析【一】

2009-10-1615:

17

【序】 

开源是口好东西，它让这个充斥着大量工业垃圾代码和教材玩具代码的行业，多了一些艺术气息和美的潜质。

它使得每个人，无论你来自米国纽约还是中国铁岭，都有机会站在巨人的肩膀上，如果不能，至少也可以抱一把大腿。

。

。

现在我就是来抱大腿的，这条粗腿隶属于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最精华的一个缩影，如果你还有空，一定要去这里进行阅读，其中重中之重是这一篇。

。

。

图1Chrome的线程和进程模型

【一】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：

同域名范畴的网站放在一个进程，比如和自己的判定机制），不论有没有互相打开的关系，都算作是一个进程中。

用命令行--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进程的之间的关系不一样，同一个进程内的线程，往往需要很多的协同工作，这一坨线程间的并发管理，是Chrome最出彩的地方之一了。

。

。

闲话并发

单进程单线程的编程是最惬意的事情，所看即所得，一维的思考即可。

但程序员的世界总是没有那么美好，在很多的场合，我们都需要有多线程、多进程、多机器携起手来一齐上阵共同完成某项任务，统称：

并发（非官方版定义...）。

在我看来，需要并发的场合主要是要两类：

1.为了更好的用户体验。

有的事情处理起来太慢，比如数据库读写、远程通信、复杂计算等等，如果在一个线程一个进程里面来做，往往会影响用户感受，因此需要另开一个线程或进程转到后台进行处理。

它之所以能够生效，仰仗的是单CPU的分时机制，或者是多CPU协同工作。

在单CPU的条件下，两个任务分成两拨完成的总时间，是大于两个任务轮流完成的，但是由于彼此交错，更人的感觉更为的自然一些。

2.为了加速完成某项工作。

大名鼎鼎的Map/Reduce，做的就是这样的事情，它将一个大的任务，拆分成若干个小的任务，分配个若干个进程去完成，各自收工后，在汇集在一起，更快的得到最后的结果。

为了达到这个目的，只有在多CPU的情形下才有可能，在单CPU的场合（单机单CPU...），是无法实现的。

在第二种场合下，我们会自然而然的关注数据的分离，从而很好的利用上多CPU的能力；而在第一种场合，我们习惯了单CPU的模式，往往不注重数据与行为的对应关系，导致在多CPU的场景下，性能不升反降。

。

。

1.Chrome的线程模型

仔细回忆一下我们大部分时候是怎么来用线程的，在我足够贫瘠的多线程经历中，往往都是这样用的：

起一个线程，传入一个特定的入口函数，看一下这个函数是否是有副作用的（SideEffect），如果有，并且还会涉及到多线程的数据访问，仔细排查，在可疑地点上锁伺候。

。

。

Chrome的线程模型走的是另一个路子，即，极力规避锁的存在。

换更精确的描述方式来说，Chrome的线程模型，将锁限制了极小的范围内（仅仅在将Task放入消息队列的时候才存在...），并且使得上层完全不需要关心锁的问题（当然，前提是遵循它的编程模型，将函数用Task封装并发送到合适的线程去执行...），大大简化了开发的逻辑。

。

。

不过，从实现来说，Chrome的线程模型并没有什么神秘的地方（美女嘛，都是穿衣服比不穿衣服更有盼头...），它用到了消息循环的手段。

每一个Chrome的线程，入口函数都差不多，都是启动一个消息循环（参见MessagePump类），等待并执行任务。

而其中，唯一的差别在于，根据线程处理事务类别的不同，所起的消息循环有所不同。

比如处理进程间通信的线程（注意，在Chrome中，这类线程都叫做IO线程，估计是当初设计的时候谁的脑门子拍错了...）启用的是MessagePumpForIO类，处理UI的线程用的是MessagePumpForUI类，一般的线程用到的是MessagePumpDefault类（只讨论windows,windows,windows...）。

不同的消息循环类，主要差异有两个，一是消息循环中需要处理什么样的消息和任务，第二个是循环流程（比如是死循环还是阻塞在某信号量上...）。

下图是一个完整版的Chrome消息循环图，包含处理Windows的消息，处理各种Task（Task是什么，稍后揭晓，敬请期待...），处理各个信号量观察者（Watcher），然后阻塞在某个信号量上等待唤醒。

。

。

图2Chrome的消息循环

当然，不是每一个消息循环类都需要跑那么一大圈的，有些线程，它不会涉及到那么多的事情和逻辑，白白浪费体力和时间，实在是不可饶恕的。

因此，在实现中，不同的MessagePump类，实现是有所不同的，详见下表：

MessagePumpDefault

MessagePumpForIO

MessagePumpForUI

是否需要处理系统消息

否

是

是

是否需要处理Task

是

是

是

是否需要处理Watcher

否

是

否

是否阻塞在信号量上

否

是

是

2.Chrome中的Task

从上面的表不难看出，不论是哪一种消息循环，必须处理的，就是Task（暂且遗忘掉系统消息的处理和Watcher，以后，我们会缅怀它们的...）。

刨去其它东西的干扰，只留下Task的话，我们可以这样认为：

Chrome中的线程从实现层面来看没有任何区别，它的区别只存在于职责层面，不同职责的线程，会处理不同的Task。

最后，在铺天盖地西红柿来临之前，我说一下啥是Task。

。

。

简单的看，Task就是一个类，一个包含了voidRun（）抽象方法的类（参见Task类...）。

一个真实的任务，可以派生Task类，并实现其Run方法。

每个MessagePump类中，会有一个MessagePump:

:

Delegate的类的对象（MessagePump:

:

Delegate的一个实现，请参见MessageLoop类...），在这个对象中，会维护若干个Task的队列。

当你期望，你的一个逻辑在某个线程内执行的时候，你可以派生一个Task，把你的逻辑封装在Run方法中，然后实例一个对象，调用期望线程中的PostTask方法，将该Task对象放入到其Task队列中去，等待执行。

我知道很多人已经抄起了板砖，因为这种手法实在是太常见了，就不是一个简单的依赖倒置，在线程池，Undo\Redo等模块的实现中，用的太多了。

。

。

但，我想说的是，虽说谁家过年都是吃顿饺子，这饺子好不好吃还是得看手艺，不能一概而论。

在Chrome中，线程模型是统一且唯一的，这就相当于有了一套标准，它需要满足在各个线程上执行的几十上百种任务的需求，因此，必须在灵活行和易用性上有良好的表现，这就是设计标准的难度。

为了满足这些需求，Chrome在底层库上做了足够的功夫：

1.它提供了一大套的模板封装（参见task.h），可以将Task摆脱继承结构、函数名、函数参数等限制（就是基于模板的伪function实现，想要更深入了解，建议直接看鼻祖《ModernC++》和它的Loki库...）；

2.同时派生出CancelableTask、ReleaseTask、DeleteTask等子类，提供更为良好的默认实现；

3.在消息循环中，按逻辑的不同，将Task又分成即时处理的Task、延时处理的Task、Idle时处理的Task，满足不同场景的需求；

4.Task派生自tracked_objects:

:

Tracked，Tracked是为了实现多线程环境下的日志记录、统计等功能，使得Task天生就有良好的可调试性和可统计性；

这一套七荤八素的都搭建完，这才算是一个完整的Task模型，由此可知，这饺子，做的还是很费功夫的。

。

。

3.Chrome的多线程模型

工欲善其事，必先利其器。

Chrome之所以费了老鼻子劲去磨底层框架这把刀，就是为了面对多线程这坨怪兽的时候杀的更顺畅一些。

在Chrome的多线程模型下，加锁这个事情只发生在将Task放入某线程的任务队列中，其他对任何数据的操作都不需要加锁。

当然，天下没有免费的午餐，为了合理传递Task，你需要了解每一个数据对象所管辖的线程，不过这个事情，与纷繁的加锁相比，真是小儿科了不知道多少倍。

。

。

图3Task的执行模型

如果你熟悉设计模式，你会发现这是一个Command模式，将创建于执行的环境相分离，在一个线程中创建行为，在另一个线程中执行行为。

Command模式的优点在于，将实现操作与构造操作解耦，这就避免了锁的问题，使得多线程与单线程编程模型统一起来，其次，Command还有一个优点，就是有利于命令的组合和扩展，在Chrome中，它有效统一了同步和异步处理的逻辑。

。

。

Command模式

Command模式，是一种看上去很酷的模式，传统的面向对象编程，我们封装的往往都是数据，在Command模式下，我们希望封装的是行为。

这件事在函数式编程中很正常，封装一个函数作为参数，传来传去，稀疏平常的事儿；但在面向对象的编程中，我们需要通过继承、模板、函数指针等手法，才能将其实现。

。

。

应用Command模式，我们是期望这个行为能到一个不同于它出生的环境中去执行，简而言之，这是一种想生不想养的行为。

我们做Undo/Redo的时候，会把在任一一个环境中创建的Command，放到一个队列环境中去，供统一的调度；在Chrome中，也是如此，我们在一个线程环境中创建了Task，却把它放到别的线程中去执行，这种寄居蟹似的生活方式，在很多场合都是有用武之地的。

。

。

在一般的多线程模型中，我们需要分清楚啥是同步啥是异步，在同步模式下，一切看上去和单线程没啥区别，但同时也丧失了多线程的优势（沦落成为多线程串行...）。

而如果采用异步的模式，那写起来就麻烦多了，你需要注册回调，小心管理对象的生命周期，程序写出来是嗷嗷恶心。

在Chrome的多线程模型下，同步和异步的编程模型区别就不复存在了，如果是这样一个场景：

A线程需要B线程做一些事情，然后回到A线程继续做一些事情；在Chrome下你可以这样来做：

生成一个Task，放到B线程的队列中，在该Task的Run方法最后，会生成另一个Task，这个Task会放回到A的线程队列，由A来执行。

如此一来，同步异步，天下一统，都是Task传来传去，想不会，都难了。

。

。

图4Chrome的一种异步执行的解决方案

4.Chrome多线程模型的优缺点

一直在说Chrome在规避锁的问题，那到底锁是哪里不好，犯了何等滔天罪责，落得如此人见人嫌恨不得先杀而后快的境地。

《代码之美》的第二十四章“美丽的并发”中，Haskell设计人之一的SimonPeytonJones总结了一下用锁的困难之处，我罚抄一遍，如下：

1.锁少加了，导致两个线程同时修改一个变量；

2.锁多加了，轻则妨碍并发，重则导致死锁；

3.锁加错了，由于锁和需要锁的数据之间的联系，只存在于程序员的大脑中，这种事情太容易发生了；

4.加锁的顺序错了，维护锁的顺序是一件困难而又容易出错的问题；

5.错误恢复；

6.忘记唤醒和错误的重试；

7.而最根本的缺陷，是锁和条件变量不支持模块化的编程。

比如一个转账业务中，A账户扣了100元钱，B账户增加了100元，即使这两个动作单独用锁保护维持其正确性，你也不能将两个操作简单的串在一起完成一个转账操作，你必须让它们的锁都暴露出来，重新设计一番。

好好的两个函数，愣是不能组在一起用，这就是锁的最大悲哀；

通过这些缺点的描述，也就可以明白Chrome多线程模型的优点。

它解决了锁的最根本缺陷，即，支持模块化的编程，你只需要维护对象和线程之间的职能关系即可，这个摊子，比之锁的那个烂摊子，要简化了太多。

对于程序员来说，负担一瞬间从泰山降成了鸿毛。

。

。

而Chrome多线程模型的一个主要难点，在于线程与数据关系的设计上，你需要良好的划分各个线程的职责，如果有一个线程所管辖的数据，几乎占据了大半部分的Task，那么它就会从多线程沦为单线程，Task队列的锁也将成为一个大大的瓶颈。

。

。

设计者的职责

一个底层结构设计是否成功，这个设计者是否称职，我一直觉得是有一个很简单的衡量标准的。

你不需要看这个设计人用了多少NB的技术，你只需要关心，他的设计，是否给其他开发人员带来了困难。

一个NB的设计，是将所有困难都集中在底层搞定，把其他开发人员换成白痴都可以工作的那种；一个SB的设计，是自己弄了半天，只是为了给其他开发人员一个长达250条的注意事项，然后很NB的说，你们按照这个手册去开发，就不会有问题了。

。

。

从根本上来说，Chrome的线程模型解决的是并发中的用户体验问题而不是联合工作的问题（参见我前面喷的“闲话并发”），它不是和Map/Reduce那样将关注点放在数据和执行步骤的拆分上，而是放在线程和数据的对应关系上，这是和浏览器的工作环境相匹配的。

设计总是和所处的环境相互依赖的，毕竟，在客户端，不会和服务器一样，存在超规模的并发处理任务，而只是需要尽可能的改善用户体验，从这个角度来说，Chrome的多线程模型，至少看上去很美。

。

。

Chrome源码剖析【二】

2009-10-1615:

12

【二】Chrome的进程间通信

1.Chrome进程通信的基本模式

进程间通信，叫做IPC（Inter-ProcessCommunication），在Chrome不多的文档中，有一篇就是介绍这个的，在这里。

Chrome最主要有三类进程，一类是Browser主进程，我们一直尊称它老人家为老大；还有一类是各个Render进程，前面也提过了；另外还有一类一直没说过，是Plugin进程，每一个插件，在Chrome中都是以进程的形式呈现，等到后面说插件的时候再提罢了。

Render进程和Plugin进程都与老大保持进程间的通信，Render进程与Plugin进程之间也有彼此联系的通路，唯独是多个Render进程或多个Plugin进程直接，没有互相联系的途径，全靠老大协调。

。

。

进程与进程间通信，需要仰仗操作系统的特性，能玩的花着实不多，在Chrome中，用到的就是有名管道（NamedPipe），只不过，它用一个IPC:

:

Channel类，封装了具体的实现细节。

Channel可以有两种工作模式，一种是Client，一种是Server，Server和Client分属两个进程，维系一个共同的管道名，Server负责创建该管道，Client会尝试连接该管道，然后双发往各自管道缓冲区中读写数据（在Chrome中，用的是二进制流，异步IO...），完成通信。

。

。

管道名字的协商

在Socket中，我们会事先约定好通信的端口，如果不按照这个端口进行访问，走错了门，会被直接乱棍打出门去的。

与之类似，有名管道期望在两个进程间游走，就需要拿一个两个进程都能接受的进门暗号，这个就是有名管道的名字。

在Chrome中（windows下...），有名管道的名字格式都是：

\\.\pipe\chrome.ID。

其中的ID，自然是要求独一无二，比如：

进程ID.实例地址.随机数。

通常，这个ID是由一个Process生成（往往是BrowserProcess），然后在创建另一个进程的时候，作为命令行参数传进去，从而完成名字的协商。

。

。

如果不了解并期待了解有关Windows下有名管道和信号量的知识，建议去看一些专业的书籍，比如圣经级别的《Windows核心编程》和《深入解析Windows操作系统》，当然也可以去查看SDK，你需要了解的API可能包括：

CreateNamedPipe,CreateFile,ConnectNamedPipe,WaitForMultipleObjects, WaitForSingleObject, SetEvent,等等。

。

。

Channel中，有三个比较关键的角色，一个是Message:

:

Sender，一个是Channel:

:

Listener，最后一个是MessageLoopForIO:

:

Watcher。

Channel本身派生自Sender和Watcher，身兼两角，而Listener是一个抽象类，具体由Channel的使用者来实现。

顾名思义，Sender就是发送消息的接口，Listener就是处理接收到消息的具体实现，但这个Watcher是啥？

如果你觉得Watcher这东西看上去很眼熟的话，我会激动的热泪盈眶的，没错，在前面（第一部分第一小节...）说消息循环的时候，从那个表中可以看到，IO线程（记住，在Chrome中，IO指的是网络IO，*_*）的循环会处理注册了的Watcher。

其实Watcher很简单，可以视为一个信号量和一个带有OnObjectSignaled方法对象的对，当消息循环检测到信号量开启，它就会调用相应的OnObjectSignaled方法。

。

。

图5Chrome的IPC处理流程图

一图解千语，如上图所示，整个Chrome最核心的IPC流程都在图上了，期间，刨去了一些错误处理等逻辑，如果想看原汁原味的，可以自查Channel类的实现。

当有消息被Send到一个发送进程的Channel的时候，Channel会把它放在发送消息队列中，如果此时还正在发送以前的消息（发送端被阻塞...），则看一下阻塞是否解除（用一个等待0秒的信号量等待函数...），然后将消息队列中的内容序列化并写道管道中去。

操作系统会维护异步模式下管道的这