Chrome源码剖析、上
原著：duguguiyu。
整理：July。
时间：二零一一年四月二日。
出处：http://blog.csdn.net/v_JULY_v。
说明：此Chrome源码剖析很大一部分编辑整理自此博客：http://flyvenus.net/。我对写原创文章的作者向来是以最大的尊重的。近期想好好研究和学习下Chrome源码，正巧看到了此duguguiyu兄台的源码剖析，处于学习的目的，就不客气的根据他的博客整理了此文。若有诸多冒犯之处，还望海涵。
--------------------------------
前言：
1、之所以整理此文，有俩个目的：一是为了供自己学习研究之用；二是为了备份，以作日后反复研究。除此之外，无它。
2、此文的形式其实是有点俩不像的，既不是个人首创即原创，又非单纯的转载（有加工），无奈之下，权且称作翻译吧。有不妥之处，还望原作者，及读者见谅。
文中加入了我自己的一些见解，请自行辨别。顺便再说一句，duguguiyu写的这个Chrome源码剖析，真不错，勾起了偶对源码剖析的莫大兴趣。
顺便透露下：在此份Chrome源码剖析之后，互联网上即将，首次出现sgi stl v3.3版的源码剖析拉。作者：本人July。是的，本人最近在研究sgi stl v3.3版的源码，正在做源码剖析，个人首创，敬请期待（已经逐步散布于程序员面试题狂想曲系列之中。July、updated，2011.05.07）。
在本文具体针对源码剖析之前，再粗略回答一下网友可能关心的问题：chrome速度维护如此之快？据网上资料显示：有几个主要的关键技术：DNS预解析、Google自主开发的V8 Javacript引擎、DOM绑定技术以及多进程架构等等。但这不是本文的重点，所以略过不谈。
ok，激动人心的Chrome源码剖析旅程，即刻开始。
Chrome源码剖析【序】
此序成于08年末，Chrome刚刚推出之际。
duguguiyu：“有的人一看到Chrome用到多进程就说垃圾废物肯定低能。拜托，大家都是搞技术的，你知道多进程的缺点，Google也知道，他们不是政客，除了搞个噱头扯个蛋就一无所知了，人家也是有脸有皮的，写一坨屎一样的开源代码放出来遭世人耻笑难道会很开心？所谓技术的优劣，是不能一概而论的，同样的技术在不同场合不同环境不同代码实现下，效果是有所不同的。....”
Chrome对我来说，有吸引力的地方在于（排名分先后…）：
1、它是如何利用多进程（其实也会有多线程一起）做并发的，又是如何解决多进程间的一些问题的，比如进程间通信，进程的开销；
2、做为一个后来者，它的扩展能力如何，如何去权衡对原有插件的兼容，提供怎么样的一个插件模型；
3、它的整体框架是怎样，有没有很NB的架构思想；
4、它如何实现跨平台的UI控件系统；
5、传说中的V8，为啥那么快。
但Chrome是一个跨平台的浏览器，其Linux和Mac版本正在开发过程中，所以我把所有的眼光都放在了windows版本中，所有的代码剖析都是基于windows版本的。有错误请指正。
关于Chrome的源码下载和环境配置，大家可自行查找资料，强调一点，一定要严格按照说明来配置环境，特别是vs2005的补丁和windows SDK的安装，否则肯定是编译不过的。
最后，写这部分唯一不是废话的内容，请记住以下这幅图，这是Chrome最精华的一个缩影：
图1 Chrome的线程和进程模型
Chrome源码剖析【一】—— 多线程模型
【一】 Chrome的多线程模型
0. Chrome的并发模型
如果你仔细看了前面的图，对Chrome的线程和进程框架应该有了个基本的了解。Chrome有一个主进程，称为Browser进程，它是老大，管理Chrome大部分的日常事务；其次，会有很多Renderer进程，它们圈地而治，各管理一组站点的显示和通信（Chrome在宣传中一直宣称一个tab对应一个进程，其实是很不确切的…），它们彼此互不搭理，只和老大说话，由老大负责权衡各方利益。它们和老大说话的渠道，称做IPC（Inter-Process Communication），这是Google搭的一套进程间通信的机制，基本的实现后面自会分解。
Chrome的进程模型
Google在宣传的时候一直都说，Chrome是one tab one process的模式，其实，这只是为了宣传起来方便如是说而已，基本等同广告，实际疗效，还要从代码中来看。实际上，Chrome支持的进程模型远比宣传丰富，简单的说，Chrome支持以下几种进程模型：
1.Process-per-site-instance：就是你打开一个网站，然后从这个网站链开的一系列网站都属于一个进程。这是Chrome的默认模式。
2.Process-per-site：同域名范畴的网站放在一个进程，比如www.google.com（由于此文形成于08年，所以无法访问，你懂的）和www.google.com/bookmarks就属于一个域名内（google有自己的判定机制），不论有没有互相打开的关系，都算作是一个进程中。用命令行–process-per-site开启。
3.Process-per-tab：这个简单，一个tab一个process，不论各个tab的站点有无联系，就和宣传的那样。用–process-per-tab开启。
4.Single Process：这个很熟悉了吧，即传统浏览器的模式：没有多进程只有多线程，用–single-process开启。
关于各种模式的优缺点，官方有官方的说法，大家自己也会有自己的评述。不论如何，至少可以说明，Google不是由于白痴而采取多进程的策略，而是实验出来的效果。
大家可以用Shift+Esc观察各模式下进程状况，至少我是观察失败了（每种都和默认的一样…），原因待跟踪。
不论是Browser进程还是Renderer进程，都不只是光杆司令，它们都有一系列的线程为自己打理各种业务。对于Renderer进程，它们通常有两个线程：一个是Main thread，它负责与老大进行联系，有一些幕后黑手的意思；另一个是Render thread，它们负责页面的渲染和交互，一看就知道是这个帮派的门脸级人物。
相比之下，Browser进程既然是老大，小弟自然要多一些，除了大脑般的Main thread，和负责与各Renderer帮派通信的IO thread，其实还包括负责管文件的file thread，负责管数据库的db thread等等，它们各尽其责，齐心协力为老大打拼。它们和各Renderer进程的之间的关系不一样，同一个进程内的线程，往往需要很多的协同工作，这一坨线程间的并发管理，是Chrome最出彩的地方之一了。
闲话并发
单进程单线程的编程是最惬意的事情，所看即所得，一维的思考即可。但程序员的世界总是没有那么美好，在很多的场合，我们都需要有多线程、多进程、多机器携起手来一齐上阵共同完成某项任务，统称：并发（非官方版定义…）。在我看来，需要并发的场合主要是要两类：
1.为了更好的用户体验。有的事情处理起来太慢，比如数据库读写、远程通信、复杂计算等等，如果在一个线程一个进程里面来做，往往会影响用户感受，因此需要另开一个线程或进程转到后台进行处理。它之所以能够生效，仰仗的是单CPU的分时机制，或者是多CPU协同工作。在单CPU的条件下，两个任务分成两拨完成的总时间，是大于两个任务轮流完成的，但是由于彼此交错，给人的感觉更自然一些。
2.为了加速完成某项工作。大名鼎鼎的Map/Reduce，做的就是这样的事情，它将一个大的任务，拆分成若干个小的任务，分配个若干个进程去完成，各自收工后，再汇集在一起，更快地得到最后的结果。为了达到这个目的，只有在多CPU的情形下才有可能，在单CPU的场合（单机单CPU…），是无法实现的。
在第二种场合下，我们会自然而然的关注数据的分离，从而很好的利用上多CPU的能力；而在第一种场合，我们习惯了单CPU的模式，往往不注重数据与行为的对应关系，导致在多CPU的场景下，性能不升反降。
1. Chrome的线程模型
仔细回忆一下我们大部分时候是怎么来用线程的，在我足够贫瘠的多线程经历中，往往都是这样用的：起一个线程，传入一个特定的入口函数，看一下这个函数是否是有副作用的（Side Effect），如果有，并且还会涉及到多线程的数据访问，仔细排查，在可疑地点上锁伺候。
Chrome的线程模型走的是另一个路子，即，极力规避锁的存在。换更精确的描述方式来说，Chrome的线程模型，将锁限制了极小的范围内（仅仅在将Task放入消息队列的时候才存在…），并且使得上层完全不需要关心锁的问题（当然，前提是遵循它的编程模型，将函数用Task封装并发送到合适的线程去执行…），大大简化了开发的逻辑。
不过，从实现来说，Chrome的线程模型并没有什么神秘的地方，它用到了消息循环的手段。每一个Chrome的线程，入口函数都差不多，都是启动一个消息循环（参见MessagePump类），等待并执行任务。
而其中，唯一的差别在于，根据线程处理事务类别的不同，所起的消息循环有所不同。比如处理进程间通信的线程（注意，在Chrome中，这类线程都叫做IO线程）启用的是MessagePumpForIO类，处理UI的线程用的是MessagePumpForUI类，一般的线程用到的是MessagePumpDefault类（只讨论windows）。
不同的消息循环类，主要差异有两个，一是消息循环中需要处理什么样的消息和任务，第二个是循环流程（比如是死循环还是阻塞在某信号量上…）。下图是一个完整版的Chrome消息循环图，包含处理Windows的消息，处理各种Task（Task是什么，稍后揭晓，敬请期待），处理各个信号量观察者（Watcher），然后阻塞在某个信号量上等待唤醒。
图2 Chrome的消息循环
当然，不是每一个消息循环类都需要跑那么一大圈的，有些线程，它不会涉及到那么多的事情和逻辑，白白浪费体力和时间，实在是不可饶恕的。因此，在实际中，不同的MessagePump类，实现是有所不同的，详见下表：
2. Chrome中的Task
从上面的表不难看出，不论是哪一种消息循环，必须处理的，就是Task（暂且遗忘掉系统消息的处理和Watcher，以后，我们会缅怀它们的…）。刨去其它东西的干扰，只留下Task的话，我们可以这样认为：Chrome中的线程从实现层面来看没有任何区别，它的区别只存在于职责层面，不同职责的线程，会处理不同的Task。最后，在铺天盖地西红柿来临之前，我说一下啥是Task。
简单的看，Task就是一个类，一个包含了void Run()抽象方法的类（参见Task类…）。一个真实的任务，可以派生Task类，并实现其Run方法。每个MessagePump类中，会有一个MessagePump::Delegate的类的对象（MessagePump::Delegate的一个实现，请参见MessageLoop类…），在这个对象中，会维护若干个Task的队列。当你期望，你的一个逻辑在某个线程内执行的时候，你可以派生一个Task，把你的逻辑封装在Run方法中，然后实例一个对象，调用期望线程中的PostTask方法，将该Task对象放入到其Task队列中去，等待执行。我知道很多人已经抄起了板砖，因为这种手法实在是太常见了，就不是一个简单的依赖倒置，在线程池，Undo/Redo等模块的实现中，用的太多了。
但，我想说的是，虽说谁家过年都是吃顿饺子，这饺子好不好吃还是得看手艺，不能一概而论。在Chrome中，线程模型是统一且唯一的，这就相当于有了一套标准，它需要满足在各个线程上执行的几十上百种任务的需求，因此，必须在灵活行和易用性上有良好的表现，这就是设计标准的难度。为了满足这些需求，Chrome在底层库上做了足够的功夫：
1.它提供了一大套的模板封装（参见task.h），可以将Task摆脱继承结构、函数名、函数参数等限制（就是基于模板的伪function实现，想要更深入了解，建议直接看鼻祖《Modern C++》和它的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，你需要了解每一个数据对象所管辖的线程，不过这个事情，与纷繁的加锁相比，真是小儿科了不知道多少倍。
图3 Task的执行模型
如果你熟悉设计模式，你会发现这是一个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传来传去，想不会，都难了。
图4 Chrome的一种异步执行的解决方案
4. Chrome多线程模型的优缺点
一直在说Chrome在规避锁的问题，那到底锁是哪里不好，犯了何等滔天罪责，落得如此人见人嫌恨不得先杀而后快的境地。《代码之美》的第二十四章“美丽的并发”中，Haskell设计人之一的Simon Peyton Jones总结了一下用锁的困难之处，如下：
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源码剖析【二】—— 进程通信
【二】Chrome的进程间通信
1. Chrome进程通信的基本模式
进程间通信，叫做IPC（Inter-Process Communication）。Chrome最主要有三类进程，一类是Browser主进程，我们一直尊称它老人家为老大；还有一类是各个Render进程，前面也提过了；另外还有一类一直没说过，是Plugin进程，每一个插件，在Chrome中都是以进程的形式呈现，等到后面说插件的时候再提罢了。Render进程和Plugin进程都与老大保持进程间的通信，Render进程与Plugin进程之间也有彼此联系的通路，唯独是多个Render进程或多个Plugin进程直接，没有互相联系的途径，全靠老大协调。
进程与进程间通信，需要仰仗操作系统的特性，能玩的花着实不多，在Chrome中，用到的就是有名的管道（Named Pipe），只不过，它用一个IPC::Channel类，封装了具体的实现细节。Channel可以有两种工作模式，一种是Client，一种是Server，Server和Client分属两个进程，维系一个共同的管道名，Server负责创建该管道，Client会尝试连接该管道，然后双发往各自管道缓冲区中读写数据（在Chrome中，用的是二进制流，异步IO…），完成通信。
管道名字的协商
在Socket中，我们会事先约定好通信的端口，如果不按照这个端口进行访问，走错了门，会被直接乱棍打出门去的。与之类似，有名管道期望在两个进程间游走，就需要拿一个两个进程都能接受的进门暗号，这个就是有名管道的名字。在Chrome中（windows下…），有名管道的名字格式都是：//./pipe/chrome.ID。其中的ID，自然是要求独一无二，比如：进程ID.实例地址.随机数。通常，这个ID是由一个Process生成（往往是Browser Process），然后在创建另一个进程的时候，作为命令行参数传进去，从而完成名字的协商。
如果不了解并期待了解有关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方法。
图5 Chrome的IPC处理流程图
一图解千语，如上图所示，整个Chrome最核心的IPC流程都在图上了，期间，刨去了一些错误处理等逻辑，如果想看原汁原味的，可以自查Channel类的实现。当有消息被Send到一个发送进程的Channel的时候，Channel会把它放在发送消息队列中，如果此时还正在发送以前的消息（发送端被阻塞…），则看一下阻塞是否解除（用一个等待0秒的信号量等待函数…），然后将消息队列中的内容序列化并写道管道中去。操作系统会维护异步模式下管道的这一组信号量，当消息从发送进程缓冲区写到接收进程的缓冲区后，会激活接收端的信号量。当接收进程的消息循环，循到了检查Watcher这一步，并发现有信号量激活了，就会调用该Watcher相应的OnObjectSignaled方法，通知接受进程的Channel，有消息来了！Channel会尝试从管道中收字节，组消息，并调用Listener来解析该消息。
从上面的描述不难看出，Chrome的进程通信，最核心的特点，就是利用消息循环来检查信号量，而不是直接让管道阻塞在某信号量上。这样就与其多线程模型紧密联系在了一起，用一种统一的模式来解决问题。并且，由于是消息循环统一检查，线程不会随便就被阻塞了，可以更好的处理各种其他工作，从理论上讲，这是通过增加CPU工作时间，来换取更好的体验，颇有资本家的派头。
温柔的消息循环
其实，Chrome的很多消息循环，也不是都那么霸道，也是会被阻塞在某些信号量或者某种场景上的，毕竟客户端不是它家的服务器，CPU不能被全部归在它家名下。
比如IO线程，当没有消息来到，又没有信号量被激活的时候，就会被阻塞，具体实现可以去看MessagePumpForIO的WaitForWork方法。
不过这种阻塞是集中式的，可随时修改策略的，比起Channel直接阻塞在信号量上，停工的时间更短。
2. 进程间的跨线程通信和同步通信
在Chrome中，任何底层的数据都是线程非安全的，Channel不是太上老君（抑或中国足球？…），它也没有例外。在每一个进程中，只能有一个线程来负责操作Channel，这个线程叫做IO线程（名不符实真是一件悲凉的事情…）。其它线程要是企图越俎代庖，是会出大乱子的。
但是有时候（其实是大部分时候…），我们需要从非IO线程与别的进程相通信，这该如何是好？如果，你有看过我前面写的线程模型，你一定可以想到，做法很简单，先将对Channel的操作放到Task中，将此Task放到IO线程队列里，让IO线程来处理即可。当然，由于这种事情发生的太频繁，每次都人肉做一次颇为繁琐，于是有一个代理类，叫做ChannelProxy，来帮助你完成这一切。
从接口上看，ChannelProxy的接口和Channel没有大的区别（否则就不叫Proxy了…），你可以像用Channel一样，用ChannelProxy来Send你的消息，ChannelProxy会辛勤的帮你完成剩余的封装Task等工作。不仅如此，ChannelProxy还青出于蓝胜于蓝，在这个层面上做了更多的事情，比如：发送同步消息。
不过能发送同步消息的类不是ChannelProxy，而是它的子类，SyncChannel。在Channel那里，所有的消息都是异步的（在Windows中，也叫Overlapped…），其本身也不支持同步逻辑。为了实现同步，SyncChannel并没有另造轮子，而只是在Channel的层面上加了一个等待操作。当ChannelProxy的Send操作返回后，SyncChannel会把自己阻塞在一组信号量上，等待回包，直到永远或超时。从外表上看同步和异步没有什么区别，但在使用上还是要小心，在UI线程中使用同步消息，是容易被发指的。
3. Chrome中的IPC消息格式
说了半天，还有一个大头没有提过，那就是消息包。如果说，多线程模式下，对数据的访问开销来自于锁，那么在多进程模式下，大部分的额外开销都来自于进程间的消息拆装和传递。不论怎么样的模式，只要进程不同，消息的打包，序列化，反序列化，组包，都是不可避免的工作。
在Chrome中，IPC之间的通信消息，都是派生自IPC::Message类的。对于消息而言，序列化和反序列化是必须要支持的，Message的基类Pickle，就是干这个活的。Pickle提供了一组的接口，可以接受int，char，等等各种数据的输入，但是在Pickle内部，所有的一切都没有区别，都转化成了一坨二进制流。这个二进制流是32位齐位的，比如你只传了一个bool，也是最少占32位的，同时，Pickle的流是有自增逻辑的（就是说它会先开一个Buffer，如果满了的话，会加倍这个Buffer…），使其可以无限扩展。Pickle本身不维护任何二进制流逻辑上的信息，这个任务交到了上级处理（后面会有说到…），但Pickle会为二进制流添加一个头信息，这个里面会存放流的长度，Message在继承Pickle的时候，扩展了这个头的定义，完整的消息格式如下：
图6 Chrome的IPC消息格式
其中，黄色部分是包头，定长96个bit，绿色部分是包体，二进制流，由payload_size指明长度。从大小上看这个包是很精简的了，除了routing位在消息不为路由消息的时候会有所浪费。消息本身在有名管道中是按照二进制流进行传输的（有名管道可以传输两种类型的字符流，分别是二进制流和消息流…），因此由payload_size + 96bits，就可以确定是否收了一个完整的包。
从逻辑上来看，IPC消息分成两类，一类是路由消息（routed message），还有一类是控制消息（control message）。路由消息是私密的有目的地的，系统会依照路由信息将消息安全的传递到目的地，不容它人窥视；控制消息就是一个广播消息，谁想听等能够听得到。
消息的序列化
前不久读了Google Protocol Buffers的源码，是用在服务器端，用做内部机器通信协议的标准、代码生成工具和框架。它主要的思想是揉合了key/value的内容到二进制中，帮助生成更为灵活可靠的二进制协议。
在Chrome中，没有使用这套东西，而是用到了纯二进制流作为消息序列化的方式。我想这是由于应用场景不同使然。在服务端，我们更关心协议的稳定性，可扩展性，并且，涉及到的协议种类很多。但在一个Chrome中，消息的格式很统一，这方面没有扩展性和灵活性的需求，而在序列化上，虽然key/value的方式很好很强大，但是在Chrome中需要的不是灵活性而是精简性，因此宁可不用Protocol Buffers造好的轮子，而是另立炉灶，花了好一把力气提供了一套纯二进制的消息机制。
4. 定义IPC消息
如果你写过MFC程序，对MFC那里面一大堆宏有所忌惮的话，那么很不幸，在Chrome中的IPC消息定义中，你需要再吃一点苦头了，甚至，更苦大仇深一些；如果你曾经领教过用模板的特化偏特化做Traits、用模板做函数重载、用编译期的Tuple做变参数支持，之类机制的种种麻烦的话，那么，同样很遗憾，在Chrome中，你需要再感受一次。。。
不过，先让我们忘记宏和模板，看人肉一个消息，到底需要哪些操作。一个标准的IPC消息定义应该是类似于这样的：
class SomeMessage: public IPC::Message
{
public:
enum { ID = …; }
SomeMessage(SomeType & data)
: IPC::Message(MSG_ROUTING_CONTROL, ID, ToString(data))
{…}
…
};
大概意思是这样的，你需要从Message（或者其他子类）派生出一个子类，该子类有一个独一无二的ID值，该子类接受一个参数，你需要对这个参数进行序列化。两个麻烦的地方看的很清楚，如果生成独一无二的ID值？如何更方便的对任何参数可以自动的序列化？。
在Chrome中，解决这两个问题的答案，就是宏 + 模板。Chrome为每个消息安排了一种ID规格，用一个16bits的值来表示，高4位标识一个Channel，低12位标识一个消息的子id，也就是说，最多可以有16种Channel存在不同的进程之间，每一种Channel上可以定义4k的消息。目前，Chrome已经用掉了8种Channel（如果A、B进程需要双向通信，在Chrome中，这是两种不同的Channel，需要定义不同的消息，也就是说，一种双向的进程通信关系，需要耗费两个Channel种类…），他们已经觉得，16bits的ID格式不够用了，在将来的某一天，估计就被扩展成了32bits的。书归正传，Chrome是这么来定义消息ID的，用一个枚举类，让它从高到低往下走，就像这样：
enum SomeChannel_MsgType
{
SomeChannelStart = 5 << 12,
SomeChannelPreStart = (5 << 12) – 1,
Msg1,
Msg2,
Msg3,
…
MsgN,
SomeChannelEnd
};
这是一个类型为5的Channel的消息ID声明，由于指明了最开始的两个值，所以后续枚举的值会依次递减，如此，只要维护Channel类型的唯一性，就可以维护所有消息ID的唯一性了（当然，前提是不能超过消息上限…）。但是，定义一个ID还不够，你还需要定义一个使用该消息ID的Message子类。这个步骤不但繁琐，最重要的，是违反了DIY原则，为了添加一个消息，你需要在两个地方开工干活，是可忍孰不可忍，于是Google祭出了宏这颗原子弹，需要定义消息，格式如下：
IPC_BEGIN_MESSAGES(PluginProcess, 3)
IPC_MESSAGE_CONTROL2(PluginProcessMsg_CreateChannel,
int /* process_id */,
HANDLE /* renderer handle */)
IPC_MESSAGE_CONTROL1(PluginProcessMsg_ShutdownResponse,
bool /* ok to shutdown */)
IPC_MESSAGE_CONTROL1(PluginProcessMsg_PluginMessage,
std::vector<uint8> /* opaque data */)
IPC_MESSAGE_CONTROL0(PluginProcessMsg_BrowserShutdown)
IPC_END_MESSAGES(PluginProcess)
这是Chrome中，定义PluginProcess消息的宏，我挖过来放在这了，如果你想添加一条消息，只需要添加一条类似与IPC_MESSAGE_CONTROL0东东即可，这说明它是一个控制消息，参数为0个。你基本上可以这样理解，IPC_BEGIN_MESSAGES就相当于完成了一个枚举开始的声明，然后中间的每一条，都会在枚举里面增加一个ID，并声明一个子类。这个一宏两吃，直逼北京烤鸭两吃的高超做法，可以参看ipc_message_macros.h，或者看下面一宏两吃的一个举例。
多次展开宏的技巧
这是Chrome中用到的一个技巧，定义一次宏，展开多段代码，我孤陋寡闻，第一次见，一个类似的例子，如下：
首先，定义一个macro.h，里面放置宏的定义：
#undef SUPER_MACRO
#if defined(FIRST_TIME)
#undef FIRST_TIME
#define SUPER_MACRO(label, type) /
enum IDs { /
label##__ID = 10 /
};
#elif defined(SECOND_TIME)
#undef SECOND_TIME
#define SUPER_MACRO(label, type) /
class TestClass /
{ /
public: /
enum {ID = label##__ID}; /
TestClass(type value) : _value(value) {} /
type _value; /
};
#endif
可以看到，这个头文件是可重入的，每一次先undef掉之前的定义，然后判断进行新的定义。然后，你可以创建一个use_macro.h文件，利用这个宏，定义具体内容：
#include “macros.h”
SUPER_MACRO(Test, int)
这个头文件在利用宏的部分不需要放到ifundef…define…这样的头文件保护中，目的就是为了可重入。在主函数中，你可以多次define + include，实现多次展开的目的：
#define FIRST_TIME
#include “use_macro.h”
#define SECOND_TIME
#include “use_macro.h”
#include <iostream>
int _tmain(int argc, _TCHAR* argv[])
{
TestClass t(5);
std::cout << TestClass::ID << std::endl;
std::cout << t._value << std::endl;
return 0;
}
这样，你就成功的实现，一次定义，生成多段代码了。
此外，当接收到消息后，你还需要处理消息。接收消息的函数，是IPC::Channel::Listener子类的OnMessageReceived函数。在这个函数中，会放置一坨的宏，这一套宏，一定能让你想起MFC的Message Map机制（关于此消息机制原理更具体的介绍，可参考侯捷的深入浅出MFC一书。）：
IPC_BEGIN_MESSAGE_MAP_EX(RenderProcessHost, msg, msg_is_ok)
IPC_MESSAGE_HANDLER(ViewHostMsg_PageContents, OnPageContents)
IPC_MESSAGE_HANDLER(ViewHostMsg_UpdatedCacheStats,
OnUpdatedCacheStats)
IPC_MESSAGE_UNHANDLED_ERROR()
IPC_END_MESSAGE_MAP_EX()
这个东西很简单，展开后基本可以视为一个Switch循环，判断消息ID，然后将消息，传递给对应的函数。与MFC的Message Map比起来，做的事情少多了。
通过宏的手段，可以解决消息类声明和消息的分发问题，但是自动的序列化还不能支持（所谓自动的序列化，就是不论你是什么类型的参数，几个参数，都可以直接序列化，不需要另写代码…）。在C++这种语言中，所谓自动的序列化，自动的类型识别，自动的XXX，往往都是通过模板来实现的。这些所谓的自动化，其实就是通过事前的大量人肉劳作，和模板自动递推来实现的，如果说.Net或Java中的自动序列化是过山轨道，这就是那挑夫的骄子，虽然最后都是两腿不动到了山顶，这底下费得力气真是天壤之别啊。具体实现技巧，有兴趣的看看侯捷的《STL源码剖析》，或者是《C++新思维》，或者Chrome中的ipc_message_utils.h，这要说清楚实在不是一两句的事情。
总之通过宏和模板，你可以很简单的声明一个消息，这个消息可以传入各式各样的参数（这里用到了夸张的修辞手法，其实，只要是模板实现的自动化，永远都是有限制的，在Chrome的模板实现中，参数数量不要超过5个，类型需要是基本类型、STL容器等，在不BT的场合，应该够用了…），你可以调用Channel、ChannelProxy、SyncChannel之类的Send方法，将消息发送给其他进程，并且，实现一个Listener类，用Message Map来分发消息给对应的处理函数。如此，整个IPC体系搭建完成。
苦力的宏和模板
不论是宏还是模板，为了实现这套机制，都需要写大量的类似代码，比如为了支持0~N个参数的Control消息，你就需要写N+1个类似的宏；为了支持各种基础数据结构的序列化，你就需要写上十来个类似的Write函数和Traits。
之所以做如此苦力的活，都是为了用这些东西的人能够尽可能的简单方便，符合DIY原则。规约到之前说的设计者的职责上来，这是一个典型的苦了我一个幸福千万人的负责任的行为。在Chrome中，如此的代码随处可见，光Tuple那一套拳法，我现在就看到了使了不下三次（我曾经做过一套，直接吐血…），如此兢兢业业，真是可歌可泣啊。
【三】 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的个数，就相当于这个进程的引用计数…）。比如，你打开一个新标签页的时候，系统为你创造了一个进程来承载这个新标签页，你输入http://www.baidu.com/，于是新标签页进程死亡，承载http://www.baidu.com/的进程诞生。你用baidu搜索了一下，毫无疑问，你基本对它的搜索结果很失望，于是你重新输入http://www.google.com.hk/，老的承载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需要进一步在这个地方琢磨点方法的。
本文Chrome源码剖析、上，完。
本文版权归原著duguguiyu和译者July共同所有。转载，请以超链接形式注明出处。谢谢。