【专业技术】Chromium浏览器组件是咋设计出来的？

在文章开始之前，我要叽歪几句，一上来就看chrome的代码，简直晕头转向，摸来摸去摸不着头脑，好不容易看了一点点代码，却宛如瞎子摸象，无法众观全局，下面这篇小文，简单介绍其中一个重要的模块--content的设计，为我们阅读google的代码打开思路。

概述

Chrome浏览器组件是一个google的一个项目，google用它来不断的模块化Chrome的代码。把整个content模块从src/chrome目录下抽取出来，尽管组件项目付出了不少努力，到目前为止，这个目录(src/chrome)仍然是最大的互相依赖的模块。因此，抽取src/chrome子模块仍然是google团队下一步的工作之一。

目标

众所周知，Chrome项目在过去几年中，无论是代码还是复杂度都增长了许多。对这个项目贡献代码的人员数量也增加了许多，而且，google也增加了许多目标平台以及配置，这些并没有在项目启动初期被他们预见到得到。对每个人来说，要理解整个架构变得越来越难，更别说所有代码了。

Chrome浏览器组件的目标如下：

• 按比例增大架构，使得浏览器更适合需求变更，比如：使用src/chrome/browser模块的浏览器希望关掉或者重新实现某些模块，例子就是安卓上的Chrome;
• 通过进一步实现依赖关系图，他们想要让实现的架构变得更清晰。那些依赖规则指出哪些子模块是允许的，哪些是不允许的。
• 大大简化了src/chrome子模块的依赖关系图，使他们不循环依赖;
• 通过增加许多独立的组件比如单元测试可执行程序，以此加速开发者的浏览器构建过程。减少最大组件的链接时间，例如browser组件，单元测试程序更小了，这有利于大家用gdb调试代码，或者通过printf快速遍历代码。
• 上面提到的方法应该可以减少我们的担忧、也让google团队更容易合作，使得架构更不容易误解，同时不容易写出不好的架构来，通常也会使google更高效。

设计

概览

1 把src/chrome目录提取出一个个的组件，这些组件变成了一个个的目标，他们有自己独立的单元测试目标，明确指定他们的依赖，没有循环依赖。

2 没有循环依赖

指的是组件并不认识自己的使用者（embedder）--嵌入组件的模块例如src/chrome。如果组件需要获得自己使用者的信息和服务，他们可以在初始化的时候获得，或者运行时通过抽象的client接口获得，这个client接口由组件定义、使用者(embedder)来实现。

3 组件在哪里？ 在src/components/的子目录里。

• 注意: 一些模块更像一个抽象层--比如src/content、或者更像一个产品--比如src/chrome，这些模块应该有自己的顶级目录，而不应该放到src/components目录下。

4 Client接口在哪里? 他们的声明在每一个组件里，而实现在组件的使用者那里。

5 组件有必要提供API给组件的使用者调用吗？

通常说来，如下用法是没问题的：组件的使用者采用C++类的具体类来使用组件，这种情况下，API是很简单的，无论组建类是什么--组件收到指针，实现来自使用者的委托接口。某些情况下，google引入了完全抽象的API给组件的使用者调用，这些API隐藏了组件的实现细节，就像他们给src/content组件做的一样。某些其他情况下，他们给组件的C++具体类分分类，一部分分到内部类，一部分分到public类里。无论是内部类还是外部类，他们都应该存在于组件目录下，例如：src/components/mycomponent/public/。 如果一个组件的public分类存在，组件的client接口应该存在那里。

参考：http://www.chromium.org/developers/design-documents/browser-components