作为个Android developer ,对APK(AndroidPackage)想必是再熟悉不过的了。我们在 Gradle 中点击下 build 或者通过命令行 gradlew tasks
,AndroidStudio 就会开始执行构建流程,最终输出APK文件。 这件事我经常干,也习以为常了,但是有时也会偶尔想想,那一串串代码是如何变成 apk 的呢,期间经历了那些流程呢?
构建流程总览
先放张官网的构建流程图
典型 Android 应用模块的构建流程通常依循下列步骤:
1.编译器将您的源代码转换成 DEX(Dalvik Executable) 文件(其中包括 Android 设备上运行的字节码),将所有其他内容转换成已编译资源。
2.APK 打包器将 DEX 文件和已编译资源合并成单个 APK。 不过,必须先签署 APK,才能将应用安装并部署到 Android 设备上。
3.APK 打包器使用调试或发布密钥库签署您的 APK:
a.如果您构建的是调试版本的应用(即专用于测试和分析的应用),打包器会使用调试密钥库签署您的应用。 Android Studio 自动使用调试密钥库配置新项目。
b.如果您构建的是打算向外发布的发布版本应用,打包器会使用发布密钥库签署您的应用。 要创建发布密钥库,请阅读在 Android Studio 中签署您的应用。
4.在生成最终 APK 之前,打包器会使用 zipalign 工具对应用进行优化,减少其在设备上运行时占用的内存。
复制代码
官网给出的流程图还是比较抽象的,很多细节都隐藏了,以下是Google官方发布的一张非常经典的Apk打包流程图。接下来会将基于下图的流程进行简单分析。
1. 打包资源文件
资源文件(res文件夹下的文件)通过 AAPT(Android Asset Packaging Tool)打包生成R.java
类(资源索引表)以及.arsc
资源文件。
经过aapt生成的R文件占4个字节
public static final int design_appbar_state_list_animator=0x7f020000;
- 第一位字节
0x7f
表示packageID,用来限定资源的来源。系统资源包是ox01,SharedLibrary类型资源包是0x00, 普通App包则是0x7f; - 次一位字节
02
表示typeID,用来表示资源类型,如drawable、layouts、anims、color、menu等; - 后2字节
0000
表示EvtryID,指的是每一个资源在对应的TypID中出现的顺序。
aapt生成的.arsc
资源文件对应我们将apk解压(apk本质是一个zip压缩包)得到的Resources.arsc,它实际上就是App的资源索引表。简单来说,通过R.java文件与Resources.arsc就可以定位到资源的内存地址。感兴趣的可以看看这篇博客
aapt 编译源码的入口在 frameworks/base/tools/aapt/Main.cpp
,其中对 assert文件夹路径、res文件夹路径、AndroidManifest文件等会采取不同的策略
对asset目录下的资源不进行编译,assets目录下的资源会被原封不动的打入apk中,也就是说assets不会被压缩;aapt会对res下drawable资源进行压缩处理(raw目录下除外)
aapt将文本xml资源文件编译成二进制资源文件的方法buildResources函数在frameworks/base/tools/aapt/Resource.cpp
可以找到,这里着重关注了下overlay特性。
overlay是android中用来处理编译时替换资源的一种方式。比如说我们通过 aapt -S 命令指定了一个res路径res1,这时候我们再使用 -S 命令指定另一个res路径res2,如果res1 和res2 下的values/string.xml 都有对同一个String ID ,最后只会使用前面的(res1)描述。可以理解为overlay会以最先定义的路径作为基准包。
有一种情况,假如我们在res2下定义了一个资源Sting a,但是基准包没有定义它,那么就会报错,这时候就可以需要加入 --auto-add-overlay
,把新的资源都添加进去。
以下是aapt源码中会进行buildResources的流程
status_t buildResources(Bundle* bundle, const sp<AaptAssets>& assets, sp<ApkBuilder>& builder)
{
// First, look for a package file to parse. This is required to
// be able to generate the resource information.
sp<AaptGroup> androidManifestFile =
assets->getFiles().valueFor(String8("AndroidManifest.xml"));
if (androidManifestFile == NULL) {
fprintf(stderr, "ERROR: No AndroidManifest.xml file found.\n");
return UNKNOWN_ERROR;
}
status_t err = parsePackage(bundle, assets, androidManifestFile);
if (err != NO_ERROR) {
return err;
}
...
// apply the overlay files to the base set
if (!applyFileOverlay(bundle, assets, &drawables, "drawable") ||
!applyFileOverlay(bundle, assets, &layouts, "layout") ||
!applyFileOverlay(bundle, assets, &anims, "anim") ||
!applyFileOverlay(bundle, assets, &animators, "animator") ||
!applyFileOverlay(bundle, assets, &interpolators, "interpolator") ||
!applyFileOverlay(bundle, assets, &transitions, "transition") ||
!applyFileOverlay(bundle, assets, &xmls, "xml") ||
!applyFileOverlay(bundle, assets, &raws, "raw") ||
!applyFileOverlay(bundle, assets, &colors, "color") ||
!applyFileOverlay(bundle, assets, &menus, "menu") ||
!applyFileOverlay(bundle, assets, &fonts, "font") ||
!applyFileOverlay(bundle, assets, &mipmaps, "mipmap")) {
return UNKNOWN_ERROR;
}
...
//preProcess & makeFileResources
...
// compile resources
// Finally, we can now we can compile XML files
}
复制代码
在Gradle中可以通过aaptOptions
的DSL来对aapt进行配置,在 Android.mk
语法中则有LOCAL_AAPT_FLAGS
配置项
这里只是对aapt流程简单的说明了下,具体的细节还是蛮多的,从xml解析到具体类型的编译流程、到二进制Manifest生成等细节都未展开,由于本人c++能力有限,很多东西也没看懂,也就不误人子弟了。
2. 处理 aidl files
如果有aidl文件,会通过aidl工具(源碼位于system/tools/aidl)打包成java接口类
AIDL(Android Interface Definition Language),是Android接口定义语言。目的是为了方便实现进程间通信,尤其是在涉及多进程并发情况下的进程间通信。它的本质是对Binder通信的封装,对Binder通信感兴趣的同学可以看看Gityuan的Binder系列文章彻底理解Android Binder通信架构
3. 编译(Compilers)
R.java+工程源码+aidl.java通过javac生成.class文件。
Javac 编译过程大致可以分为3个阶段
- 解析与填充符号表过程
解析的步骤包括词法分析与语法分析两个过程词法分析
是将源代码的字符串流转变为标记(Token)集合,单个字符是程序编写过程的最小元素,而标记是编译过程的最小元素。关键字、变量名、运算符等都可以成为标记语法分析
是根据 Token 序列构造抽象语法树的过程,抽象语法树是一种用来描述程序代码语法结构的树形表示方式,语法树的每一个节点都代表程序中的一个语法结构,如包、类型、修饰符、接口等 - 插入式注解处理器的注解处理过程
插入式注解处理器,可以读取、修改、添加抽象语法树中的任意元素。Android中的APT(Annotation Processing Tool)就是在这个阶段工作的。 - 语义分析与字节码生成过程
语法分析后,编译器获得了程序代码的抽象语法树表示,语法树能表示一个结构正确的源程序抽象,但是无法保证源程序是符合逻辑的。而语义分析主要是对结构正确的进行上下文有关性质的审查。语义分析一般要经历标注检查、数据及控制流分析、解语法糖等过程,然后才会走到javac编译的最后一个阶段:字节码生成。大致流程如下:
标注检查 -> 数据及控制流分析 -> 解语法糖 -> 字节码生成
Javac 编译动作的入口是 com.sun.tools.javac.main.JavaCompiler
类,主要逻辑集中在 compile()和 compile2()方法中,感兴趣的可以去看看
4. dex(生成dex文件)
源码.class文件和第三方jar或者library通过dx工具打包成dex文件。
上面生成的 .class 文件虽然已经可以在 JVM 环境中运行,但是如果要在 Android 运行时环境中执行还需要特殊的处理,那就是 dx 处理,它会对 .class 文件进行翻译、重构、解释、压缩等操作。
关于dex的操作,我们了解最多的可能就是 Tinker 的热修复方案了,Tinker 的基本思想是利用双亲委派原则,将patch的相关dex放在数组前端,保证classloader先到patch中查找加载。如果想要对细节更一步了解,如如何保证资源id不变,资源Diff是怎么做的,对dex文件格式有所了解是必不可少的。关于dex的文件格式,官网有详细介绍,这里就不做说明了。
AndroidStudio有提供 proguard、D8、R8等工具来处理这一流程。Android 还会针对 Dalvik 虚拟机和 Art 虚拟机对dex进行优化
- dexopt 是对 dex 文件 进行 verification 和 optimization 的操作,其对 dex 文件的优化结果变成了 odex 文件,这个文件和 dex 文件很像,只是使用了一些优化操作码(譬如优化调用虚拟指令等)。
- dex2oat 是对 dex 文件的 AOT 提前编译操作,其需要一个 dex 文件,然后对其进行编译,结果是一个本地可执行的 ELF 文件,可以直接被本地处理器执行。
5. apkbuilder(生成未签名apk)
apkbuilder工具会将所有没有编译的资源、.arsc资源、.dex文件打包到一个完成apk文件中
6. Jarsigner(签名)
jarsigner工具会对未签名的apk验证签名。得到一个签名后的apk(signed.apk)
可以通过在命令行中输入jarsigner来获取详情信息,如果沒有特殊需求,使用下面命令即可完成签名
jarsigner -verbose -keystore [私钥存放路径] -signedjar [签名后文件存放路径] [未签名的文件路径] [您的证书名称]
7. zipalign(对齐)
zipAlign工具对6中的signed.apk进行对齐处理
所谓对齐,主要过程是将APK包中所有的资源文件距离文件起始偏移为4字节整数倍,这样通过内存映射访问apk文件时的速度会更快。对齐的作用主要是为了减少运行时内存的使用。
工具列表
名称 | 功能介绍 | 路径 |
aapt | Android资源打包工具 | ${ANDROID_SDK_HOME}/platform-tools/appt |
aidl | Android接口描述语言转化为.java文件的工具 | ${ANDROID_SDK_HOME}/platform-tools/aidl |
javac | Java Compiler | ${JDK_HOME}/javac |
dex | 转化.class文件为Davik VM能识别的.dex文件 | ${ANDROID_SDK_HOME}/platform-tools/dx |
apkbuilder | 生成apk包 | ${ANDROID_SDK_HOME}/tools/opkbuilder |
jarsigner | .jar文件的签名工具 | ${JDK_HOME}/jarsigner |
zipalign | 字节码对齐工具 | ${ANDROID_SDK_HOME}/tools/zipalign |