Android Build系统分析 一

闲来无事，分析一下Android的Build系统，希望对自己的工作有所助益；有可能对别人有所帮助。

 

Android无疑是一个很大的系统，目前看来也是还很年轻，又很有活力的一个系统。通过研究它的build子系统，至少可以看到一个大系统是怎样写出来的。

 

Makefile，很多人可能都觉得，这个东西太简单了，甚至很多时候都不需要，我直接gcc把源代码编出来就可以了。这种想法，在程序小的时候是可以的，但是要写一个大型的系统的话，如果还守着以前的手工作坊的模式，那只会给自己带来很大的困扰。

 

我们关注的不是Makefile的语法，偏僻的用法，而是学习一下，Android这个大系统里，关于build管理，它用Makefile解决了一些什么样的问题。

 

粉墨登场

 

产品，product。Android已经支持了好几款产品，比如有HTC的dream, hero, nexus，Motorola的droid等，还有Google自己的generic的android源码。

 

Variant。Android在build的时候，可以指定几个variant，比如，user, userdeubg, eng, tests。通过这些选项，可以编译出来不同的程序，eng是给工程师用的，user是给最终客户用的。

 

子系统。Android平台里有很多不同的程序。有跑在手机上的，有跑在PC上的。有程序，有库。有动态库，也有静态库。有代码，也有文档。有C，有C++，也有Java。还有键盘/字符映射表。这些都是需要编译的。

 

继承关系。针对很多产品的角色之间，是有继承关系的。比如，Google自己的产品，其实不是一个产品，只是一个参考设计。但是其他所有厂商的产品呢，又必须是从Google的参考设计继承下来的。如果每个厂商都需要从头定义很多自己的标准，那很费人力，又不好维护，就像人类造通天塔一样，是不可能成功的。Google定义出来了一套标准，就是要鼓励厂商们使用它的这套标准。

 

天狗吠日

 

好吧，让我们看一眼代码吧。

 

build/target/product底下有一些.mk文件，其格式是Makefile文件，其中：

 

core.mk定义了product_packages，也就是说，基本上所有基于Android的系统，都必须有这几个package。像browser啊，contacts啊，launcher啊，phone啊，都是这里面规定了的，其他厂商版本没有特殊情况，就不需要再自己去定义这几个package了。

 

generic.mk又定义了几个额外的package，同时继承了core.mk。

 

说到这儿，您可能会觉得奇怪，继承那不是面向对象的概念吗，怎么Makefile里还能“继承”呢？这样想的话就错了。Makefile一样能继承。即使是汇编语言，你都可以继承。语言只是提供一种方便而已，关键还是要看人怎么用。

 

C++提供了继承，但是它不是一个专门为build管理设计的语言啊。Makefile语言才是专门为build系统设计的语言。但是我们看到Android这样一个系统，它需要用到继承的概念时，有经验的开发者肯定不会那么死板，因为一种语言没有内在的某种特性就束手无策。他们会考虑两种方案

 

1。换语言。比如我自己重新写一个build的语言。Java里的ant，还有boost C++库的jam，就是这么来的。

 

2。自己用已有语言编程实现需要的特性。

 

一般来说，影响做出最后决定的因素，无疑应该是代价。专门发明一种新语言，代价还是很大的。所以我们看到，Android的开发者选择了后者。

 

待续。