Chrome学习整理

2012 年 12 月 05 日
learning
chromium

由于工作需要我需要分析Chrome的图片解码流程。众所周知，Chrome是建立在开源的Chromium项目上的。最近的一个多月时间里，我基本把所有心思都放在Chromium上了，而且不得不说，学习并分析开源项目的代码对一个程序员的提高确实蛮大的。这篇博文我会记录一下学习过程中我遇到的一些问题，并分享学习中我所参考的几篇优秀的Chromium代码分析文章。

构建的一点吐槽和官方的方法文档摘录

不看不知道，编译好的Chromium可执行文件虽然只有40+M，但打包好的源码文件包竟然高达3G之多（也许是我孤陋寡闻了，但是这个反差确实让我吓我一跳）。 Chromium的构建方法就不多说了，推荐官方安装帮助文档。

值得一提的是，一定要按照他所提供的办法严格的执行，不然可能会遇到各种编译错误。编译过程很可能会长达数小时之久 (在我的笔记本上构建了一整晚才完成)。为了加速编译过程，推荐使用多核CPU，64位windows，至少8G内存和60G硬盘空间，这些要求应该都不难达到。还有其他的几点：

尽量使用Visual Studio 2010 SP1 版本，不然precompiled headers模式可能会出现很多问题。由于Chromium中有大量的头文件，使用此选项大概能加速25%。
关闭杀毒软件，或者把.ilk, .pdb, .cc, .h文件加入白名单。再或者，把Chromium源代码目录加入杀毒软件白名单。
在一个没有虚拟内存交换的硬盘上构建Chromium。或者固态硬盘，如果可能的话。
使用ninja构建Chromium。这是Google专门为Chromium项目开发的构建工具链，笔者没有尝试，文档称使用ninja会让incremental linking过程快很多。
修改Visual Studio选项，减少同时链接的项目数量，以减少Chromium链接时所需要的内存。因为Chromium链接需要大量的内存，如果内存不足，大量的分页操作会大大降低系统的反应速度。”maximum number of parallel project builds”可以在Tools/Options/Projects and Solutions/Build and Run页面找到。这个选项可以减少Visual Studio启动的VCBuildHelper.exe实例数目。
修改include.gypi文件，减少同时执行的cl.exe的数目。默认情况下，Visual Studio会开启/MP选项，动用系统一切资源生成多个编译进程加速编译。但是由于Chromium项目过大，最差情况下一个cl.exe（链接器）可能会占用大约1G内存。

Visual Studio中调试Chromium浅谈

分析Chromium源码，为了快速的在代码海洋中找到自己所需要的部分，不可避免的要调试的Chromium项目。比如说，我们想知道，Chromium是如何从页面上下载一张图片，经过渲染，最后显示在页面上的呢？这个流程实际上的要比看起来复杂不少：一个页面内的WebKit分析出DOM树，发现一个<img>元素里的图片需要显示；WebKit发送一个URL下载的IPC消息给主进程Browser Process，然后WebKit根据返回数据的MIME类型标签进行解析，发现这个资源是个图片，再根据编码方式调用相应的WebCore::ImageDecoder类进行解码，最后还要进行一系列的渲染，把需要绘制的东西交给RenderWidget，这样我们才能看到图片。这个过程如果单纯的去浏览代码找到对应的类和方法调用关系，效率低下不说，还很容易出错，这时候我们就需要在Chromium中进行代码调试和追踪了。

有个关键问题，Chromium不同于普通的单进程程序，默认情况下它是多进程模式的。比如，新打开的只有一个首页的Chrome程序，至少有3个相关进程，分别是Browser进程（管理所有的UI框架，全局消息传递，资源下载等等），GPU进程（提供WebGL渲染，绕过沙盒机制调用3D API），和渲染进程Renderer（包括首页响应用户操作的content和负责渲染的WebKit实例等等），甚至还可能还有其他的进程外运行的插件进程，等等。具体的Chrome进程模型还有不同进程之间如何用IPC消息进行交互的，请参考本文推荐的阅读源。如果直接通过visual studio进行调试，只有主进程（Browser）被调试，而负责渲染的renderer进程则像是其他程序一样，表示一切跟我没有关系。最直观的表现就是，使用Chrome浏览器时，Windows任务管理器中会出现多个chrome.exe进程实例。

调试多进程的Chromium，其实利用visual studio自带的工具就完全可以进行: 调试开始后，只要把已经运行起来的子进程附加到debugger上就可以了。具体操作是，开始调试，选择Tools > Attach to Process，然后按住ctrl选择多个你想要调试的chrome.exe进程，附加到debugger上。另外，最好用debug构建的Chromium进行调试，不然release的编译器优化问题会产生一些很诡异的情况（比如取不到特定变量的值，跳过了一些被优化过的函数什么的。。。）附加进程到debugger的界面如图所示：

附加到debugger后，你可以在process窗口看到正在调试的进程:

另外，刚才说过，Chromium默认情况下是多进程模式（Process-per-site-instance，一个网站打开的所有页面属于同一进程）。你还可以提供运行时参数–single-process，强制让Chromium只用一个进程运行。这种模式可以通过传统的方式进行调试，但是这种模式属于实验性质的，可能会有这样和那样的bug出现，导致页面崩溃。

Chromium project官网还提供了多个调试办法，不过直接利用visual studio的附加到进程方式最简便。http://dev.chromium.org/developers/how-tos/debugging

不过实际开发调试中，开发者并不需要每次都要打开庞大的Chromium项目。Chromium源码目录还包含了2个供测试开发用的项目，分别是content_shell和test_shell，默认情况下这两个项目可以从src\content\content.sln和src\webkit\webkit.sln中打开。test_shell主要展示了chromium webkit API，包含了大部分的webkit渲染引擎核心的chrome移植接口（不包括HTML5，GPU加速，沙箱模型），注意，它是单进程的。对于content_shell，这个程序主要用来展示content shell API，它几乎包含了所有的浏览器的功能，像是一个没有华丽Chrome外壳的浏览器。跟test_shell不同，content_shell是多进程的，进程模型与chromium相同。如果你愿意，完全可以在content_shell上加一个外壳变成自己自主开发的浏览器，就像是360那样。。。开发者可以根据自己的需要（比如，单独测试Webkit部分，或是要研究不同浏览器部件之间如何进行交互）选择不同的程序调试或开发。

下图是一个content_shell在windows下运行的效果。注意，这个东西处理HTTP请求很慢（content API并不包括完整的资源下载功能，Chrome的所有资源下载都是通过Browser进程负责的），最好只用来测试本地的页面。