Chromium浏览器组件设计意图

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

 

概述

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

目标

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

        Chrome浏览器组件项目引入了模块化并强制执行，目标如下：

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

设计

概览

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

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

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

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

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

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

部分参考：http://www.chromium.org/developers/content-module

本文属原创，转载请注明出处，违者必究

关注chromium群480089700，或者微信公众平台:程序员互动联盟(coder_online)，你可以第一时间获取原创技术文章，和（java/C/C++/Android/Windows/Linux）技术大牛做朋友，在线交流编程经验，获取编程基础知识，解决编程问题。程序员互动联盟，开发人员自己的家。