做过 Android 平台开发的朋友对make，mm或make clean命令应该很熟悉，但也许大家只是熟知这些命令的作用却不知道这些命令底下有些什么原理？那么今天我就带着大家推开Android编译系统的大门，探索一下这片未知的恐怖之森(问啥要用恐怖之森后面大家就知道了)。

Makefile入门

在讲解Android编译系统之前首先来了解一下什么是Makefile：

简单的说，Makefile提供了一种机制，让使用者可以有效的组织工作。

注意这里用的是“工作”而非“编译”，这是因为Makefile并不是用来完成编译工作的，它只是一种规则的执行者，而使用者用它来执行什么规则没有任何限制。如既可以用它来编译系统，也能用它备份文档或只是打印log。

既然它是用来执行规则的，那么我们就来看看Makefile的规则。

TARGET:PREREQUISITES

COMMANDS

注意：COMMANDS前面必须有一个TAB制表符

在 Makefile 的规则中TARGET是需要生成的目标文件，PREREQUISITES是目标的先决条件，也是另一个规则中的target。COMMANDS是生成目标文件的命令，当 prerequisites 中的任何一个文件比 target 文件要新的时候就会触发 commands。commands 的具体内容取决于使用者的需求，如调用 gcc 编译器。

下面我们用一个简单的例子说明一下Makefile规则的用法。

涉及到的文件如下：

文件名

描述

mian.c

主函数所在文件

test.h

提供一个测试函数getNumber的声明

test.c

提供getNumber的函数实现，用于返回一个值

Makefile

我们的主角，用于编译整个例子

文件内容如下：

(1)test.h对getNumber进行声明。

int getNumber();

(2)test.c实现getNumber函数

#include "test.h"

int getNumber()

{

return 2333;

}

(3)main.c打印getNumber的返回值

#include

#include "test.h"

int main()

{

printf("Hello,getNumber=%d\n",getNumber());

return 0;

}

(4)Makefile文件，用于组织这个小例子的编译工作

MakefileTest : main.o test.o

gcc -o MakefileTest main.o test.o

main.o : main.c

gcc -c main.c

test.o : test.c

gcc -c test.c

对上面这段代码简单解释一下，MakefileTest为TAEGET即目标产物，main.o和test.o是MakefileTest的先决条件。gcc -o MakefileTest main.o test.o则是MakefileTest对应的COMMANDS,这条命令使用gcc命令将main.o和test.o编译成MakefileTest可执行文件。

最后通过使用make命令就会在当前目录生成一个MakefileTest可执行文件，运行结果如下：

这里写图片描述

上面这个是一个非常简单的Makefile的示例，但“麻雀虽小，五脏俱全”，它清晰的展示了一个Makefile的编写过程。另外Make工具本身是非常强大的，它有很多隐含的规则来帮助开发者快速搭建复杂的编译体系。如利用它的自动推导功能可以简化对象间的依赖关系，还可以加入变量来减少重复输入。

上面的Makefile还可以写成这样：

OBJECT = main.o test.o

MakefileTest : $(OBJECT)

gcc -o MakefileTest $(OBJECT)

关于Makefile的更多用法可以查看how to write makefile。希望大家多了解一下makefile的用法，这有助于理解Android的编译系统。

Android编译系统入门

像我这样从事过Android平台开发的开发人员对make，mm等命令应该很熟悉，同样也知道Android.mk文件，用它结合mm命令来编译单个的Android模块。如果这就是你对Android编译系统的全部了解，那只能说你是一个普通的Android平台开发人员。想要在Android平台开发界混的话，学习和掌握Android编译系统的原理将是必不可少的。前面说道Android编译系统是一个恐怖之森，应为它真好符合恐怖之森的两个特点，让人望而却步和容易迷失方向。这么说一点也不过分，在学习Android编译系统的时候，如果缺少很明确的指引很容易迷失方向，或者让你根本就不敢去试着闯一闯。

makefile依赖树的概念

不难发现在makefile中的target的依赖关系实际上可以组成一棵树，我将其称为makefile依赖树，仍然以上一个MakefileTest为例，给出它的makefile依赖树：

这里写图片描述

只要照个这个树形结构顺藤摸瓜，那么分析Android编译系统也就变得有目的性了。

恐怖之森里的树

有了上面的知识做铺垫，我们也就可以大胆的往恐怖之森闯了。

这里写图片描述

根节点

既然是树，肯定有它的根节点，我们就来找一找Android编译系统的根节点。

如果make命令没有指定文件的话默认会在当前目录寻找Makefile这个文件，所以先看看Android源码根目录的那个Makefile文件：

### DO NOT EDIT THIS FILE ###

include build/core/main.mk

### DO NOT EDIT THIS FILE ###

原来这里只是指路牌，真正的文件是build/core/main.mk。

在 Makefile 使用 include 关键字可以把别的 Makefile 包含进来,这很像 C 语言的

\#include,被包含的文件会原模原样的放在当前文件的包含位置。

打开main.mk发现它有上千行代码，并且在其中又包含了很多其他makefile脚本，所以整个文件的内部结构让人感觉杂乱无章，无法入手。这时候我们就不能一行行的去读这个文件，这样很可能会事倍功半。我们需要找出它其中依赖树的根节点，以此为突破口。但往往大型的工程中不止一棵依赖树，这时候如果没有指定依赖树的话make命令会以从上至下第一个target作为默认依赖树的根节点。其实大家非常熟悉的make clean中的clean就是这些依赖树中的一棵。

.PHONY: clean

clean:

@rm -rf $(OUT_DIR)/*

@echo "Entire build directory removed."

clean是一个伪目标，伪目标一般没有目标文件。且使用.PHONY显示声明。

从上面clean的COMMANDS知道它的作用是删除\$(OUT_DIR)下的所有目录和文件，而\$(OUT_DIR)就是out目录。

OK，那么我们就跟着上面的思路找寻那棵默认依赖树，对照main.mk代码很快就发现了它的默认依赖树根节点：

# This is the default target. It must be the first declared target.

.PHONY: droid

DEFAULT_GOAL := droid

$(DEFAULT_GOAL):

从注释中可以看出来droid就是我们找的依赖树的根节点，不过这里只是定义了一下，没有给出真正的规则。根据关键字搜索的话会发现main.mk中有几处对droid规则的定义：

ifneq ($(TARGET_BUILD_APPS),)

# If this build is just for apps, only build apps and not the full system by default.

...

.PHONY: apps_only

apps_only: $(unbundled_build_modules)

droid: apps_only

...

else # TARGET_BUILD_APPS

...

# Building a full system-- the default is to build droidcore

droid: droidcore dist_files

上面会根据TARGET_BUILD_APPS变量的值是否为空来走不同的分支，如果不为空，则droid的先决条件是apps_only，如果为空droid的先决条件是droidcore和dist_files，我们使用默认的make命令编译android系统的话这里的TARGET_BUILD_APPS的值为空，所以走下面这个分支。TARGET_BUILD_APPS何时不为空，感兴趣的朋友可以自行分析一下。

main.mk总览

在分析droidcore和dist_files两个先决条件之前先来看一下main.mk的一个文件结构，它除了构建droid等依赖树外，有一大半内容是在做一下这些事情。

对编译环境的检测

比如java环境是否符合要求，当前是linux系统还是mac系统。如果这些检测中有任何一项不符合要求，则会终止编译。

进行一些必要的前期处理

比如整个项目工程是否要进行清理操作，部分工具的安装等。

引用其他Makefile文件

比如引用config.mk,cleanbuild.mk等。

设置全局变量

各种函数的实现

Android编译系统中定义了很多实用的函数，它们提供了整个编译系统的统一解决方案。比如my-dir这个在Android.mk中出镜率最高的函数，就是用来获得当前的路径。

下表是对Android编译系统中涉及的主要Makefile文件的解释，可供参考。

Name

Description

main.mk

整个编译系统的主导文件

config.mk

产品配置的主导文件

base_rules.mk

编译系统需要遵循的基础规则定义

build_id.mk

版本id号的定义

cleanbuild.mk

clean操作的定义

clear_vars.mk

LOCAL开头的相关系统变量

definitions.mk

提供了大量实用的函数定义

envsetup.mk

配置编译时的环境变量

executable.mk

负责BUILD_EXECUTABLE的具体实现

host_executable.mk

负责BUILD_HOST_EXECUTABLE的具体实现

host_static_library.mk

负责BUILD_HOST_STATIC_LIBRARY的具体实现，其他类型的BUILD_XX这里不再赘述

product_config.mk

产品级别的配置，属于config的一部分

version_defaults.mk

负责生成版本信息，如版本号BUILD_NUMBER := eng.$(USER).$(shell date +%Y%m%d.%H%M%S)

droidcore节点

droid规则的定义如下：

# Build files and then package it into the rom formats

.PHONY: droidcore

droidcore: files \

systemimage \

$(INSTALLED_BOOTIMAGE_TARGET) \

$(INSTALLED_RECOVERYIMAGE_TARGET) \

$(INSTALLED_USERDATAIMAGE_TARGET) \

$(INSTALLED_CACHEIMAGE_TARGET) \

$(INSTALLED_VENDORIMAGE_TARGET) \

$(INSTALLED_FILES_FILE)

可以看出来droidcore有如下几个先决条件，

Prerequisite

Description

files

代表其所依赖的先决条件的集合，没有实际意义

systemimage

将生成system.img

INSTALLED_BOOTIMAGE_TARGET

将生成boot.img

INSTALLED_RECOVERYIMAGE_TARGET

将生成recovery.img

INSTALLED_USERDATAIMAGE_TARGET

将生成userdata.img

INSTALLED_CACHEIMAGE_TARGET

将生成cache.img

INSTALLED_VENDORIMAGE_TARGET

将生成vendor.img

INSTALLED_FILES_FILE

将生成install-files.txt,用于记录当前系统中预装的程序、库等模块

这几个先决条件的生成原理类似，这里挑几个做重点分析。

1.files

定义如下：

```mk