Android Apk 编译打包流程，了解一下~

前言

作为一个Android开发，每天都会有相当一部分的时间花在编译打包上，如果项目比较大的话编译一次可能就要十几分钟。

那么在编译打包的过程中AGP到底做了什么？为什么编译那么耗时，又该怎么优化？要解决这些问题，首先就需要我们对编译打包的流程有个总体的了解

本文主要包括以下内容

1. 编译打包总体流程
2. 编译打包主要步骤
3. 编译打包过程中的Task

编译打包总体流程

首先看下Android官网给出的编译打包总体流程

典型 Android 应用的构建流程如图所示，主要分为以下几步：

1. 编译器将您的源代码转换成 DEX 文件（Dalvik 可执行文件，其中包括在 Android 设备上运行的字节码），并将其他所有内容转换成编译后的资源。
2. 打包器将 DEX 文件和编译后的资源组合成 APK 或 AAB（具体取决于所选的 build 目标）。
3. 打包器使用调试或发布密钥库为 APK 或 AAB 签名。
4. 在生成最终 APK 之前，打包器会使用 zipalign 工具对应用进行优化，以减少其在设备上运行时所占用的内存

编译打包主要步骤

关于Android编译打包还有一张更加复杂的图

这个看起来是相当复杂的，但其实我们也可以把这些步骤做一个分类，跟总体流程的四个步骤做一个对应

资源与代码编译

资源文件编译

apk资源包含:

• 工程中res目录下的所有文件
• assets目录下的文件
• AndroidManifest.xml

apk的资源编译是编译过程中的一项主要工作，AGP3.0.0之后默认通过AAPT2来编译资源。

AAPT2（Android Asset Packaging Tool2）是一种构建工具，Android Studio 和 Android Gradle 插件使用它来编译和打包应用的资源。AAPT2 会解析资源、为资源编制索引，并将资源编译为针对 Android平台进行过优化的二进制格式。

AAPT2做了什么优化?

为什么AGP3.0.0之后默认通过AAPT2来编译资源呢？它又做了什么优化呢?

AAPT2 支持通过启用增量编译实现更快的资源编译。这是通过将资源处理拆分为两个步骤来实现的：

• 1、编译：将资源文件编译为二进制格式。

把所有的Android资源文件进行解析，生成扩展名为.flat的二进制文件。比如是png图片，那么就会被压缩处理，采用.png.flat的扩展名。可以在build/intermediates/merged_res/文件下查看生成的中间产物

• 2、链接：合并所有已编译的文件并将它们打包到一个软件包中。

首先，这一步会生成辅助文件，比如R.java与resources.arsc，R文件大家应该都比较熟悉，就是一个资源索引文件，我们平时引用也都是通过R.的方式引用资源id。而resources.arsc则是资源索引表，供在程序运行时根据id索引到具体的资源
最后，会将R文件，ressources.arsc文件和之前的二进制文件进行打包，打包到一个软件包中。

这种拆分方式有助于提高增量编译的性能。例如，如果某个文件中有更改，您只需要重新编译该文件。

AIDL文件编译

对于AIDL，大家应该都很熟悉，它是一种用于进程间通信的接口文件。

其实它是Google为了帮助我们进行进程间通信的简便写法，最后还是需要被解析编译为java文件，而做这个工作的就是aidl工具，存在于sdk/build-tools目录。

这个阶段的主要的工作就是将项目中的aidl文件编译为java文件。

Java与Kotlin文件编译

• 通过Java Compiler 编译项目中所有的Java代码，包括R.java、.aidl文件生成的.java文件、Java源文件，生成.class文件。在对应的build目录下可以找到相关的代码
• 通过Kotlin Compiler编译项目中的所有Kotlin代码，生成.class文件

注解处理器(APT,KAPT)生成代码也是在这个阶段生成的。当注解的生命周期被设置为CLASS的时候，就代表该注解会在编译class文件的时候生效，并且生成java源文件和Class字节码文件。

Class文件打包成DEX

这一步就是将.class文件打包成dex文件。

有人可能会奇怪了，.class文件不就是JVM可以识别的二进制文件吗，为什么还要进行一次转化呢？

这就涉及到另一个问题：JVM 和 Dalvik（ART 的区别。

其中一个重要的区别就是Dalvik（ART）有自己的二进制文件，也就是.dex文件，所以需要将class文件进行再一次转换。

你可以把dex文件理解为一个class文件包，里面装着很多的class文件，让这些类能够共享数据，类似这种关系：

D8编译器与R8工具

在 AGP 3.X 以后，Google 分别引入 D8 编译器和 R8 工具作为默认的 DEX 编译器和混淆压缩工具。

• 在AGP3.0.1之后,D8编译器取代了Dx，用于将class文件打包成DEX，D8编译器编译更快、时间更短；DEX 编译时占用内容更小；生成的dex文件大小更小；同时拥有相同或者是更好的运行时性能；
• 在AGP3.4.0之后，默认开启R8，R8 是 ProGuard 的替代工具，用于代码的压缩（shrinking）和混淆（obfuscation）

在 AGP3.4.0版本中，R8 把 desugaring、shrinking、obfuscating、optimizing 和 dexing 都合并到一步进行执行。在 AGP3.4.0 以前的版本编译流程如下：

在AGP3.4.0之后的编译流程如下：

生成APK包

在资源文件与代码文件都编译完成后，接下来就是生成apk包了，将manifest文件、resources文件、dex文件、assets文件等等打包成一个压缩包，也就是apk文件。

在老版本使用的工具是apkbuilder，但是在最新的版本我发现没有这个工具了，sdk目录下也找不到了。

在AGP3.6.0之后，使用zipflinger作为默认打包工具来构建APK，以提高构建速度

zipalign（对齐处理）

zipalign 是一种归档对齐工具，可对 Android 应用 (APK) 文件提供重要的优化

zipalign会对apk中未压缩的数据进行4字节对齐，对齐的主要过程是将APK包中所有的资源文件距离文件起始偏移为4字节整数倍，对齐后就可以使用mmap函数读取文件，可以像读取内存一样对普通文件进行操作。如果没有4字节对齐，就必须显式的读取，这样比较缓慢并且会耗费额外的内存。

有的同学可能会有疑问，这个对齐处理不是应该放在签名之后吗？其实这里就涉及到了签名工具的不同带来的对齐处理的顺序不同：

• 如果使用的是 apksigner，只能在为 APK 文件签名之前执行 zipalign。
• 如果使用的是 jarsigner，只能在为 APK 文件签名之后执行 zipalign。

对APK进行签名

在生成APK文件之后，必须对该apk文件进行签名，否则无法被安装。

之前大家比较熟知的签名工具是JDK提供的jarsigner，而apksigner是Google专门为Android提供的签名和签证工具。

其区别就在于jarsigner只能进行v1签名，而apksigner可以进行v2、v3、v4签名。下面我们简单介绍下V1签名和V2签名的区别，关于V3,V4签名的内容可参考：Android开发应该知道的签名知识！

V1签名

v1签名方式主要是利用META-INFO文件夹中以MF、SF 和 RSA 的三个文件，流程如下所示：

首先，将apk中除了META-INFO文件夹中的所有文件进行进行摘要写到 META-INFO/MANIFEST.MF；然后计算MANIFEST.MF文件的摘要写到CERT.SF；最后计算CERT.SF的摘要，使用私钥计算签名，将签名和开发者证书写到CERT.RSA。

所以META-INFO文件夹中这三个文件就能保证apk不会被修改。但是V1签名方案主要有两个问题

• 一是签名校验慢，在签名校验时要针对 Apk 中所有的文件进行校验，这会拖累老设备的安装时间。
• 二是META-INFO文件夹不会被签名，存在一定安全隐患

V2签名

Android7.0之后，Google推出了V2签名，解决V1签名速度慢以及签名不完整的问题。

apk本质上是一个压缩包，而压缩包文件格式一般分为三块：

文件数据区，中央目录，中央目录结束节。

而V2要做的就是，在文件中插入一个APK签名分块，位于中央目录部分之前，如下图：

这样处理之后，文件签名完成就无法修改了，这也是为什么ZipAlign对齐只能在ApkSigner签名之前执行的原因。

编译打包过程中的Task

上面介绍了Apk编译打包过程的主要步骤，这些步骤也都是通过AGP插件实现的，那么这些主要步骤又对应AGP中的哪些Task呢

当我们在Android Studio中点击Run时，便可以在控制台看到一系列的Task执行

Executing tasks: [:app:assembleDebug] in project
> Task :app:preBuild UP-TO-DATE
> Task :app:preDebugBuild UP-TO-DATE
> Task :app:mergeDebugNativeDebugMetadata NO-SOURCE
> Task :app:compileDebugAidl NO-SOURCE
> Task :app:compileDebugRenderscript NO-SOURCE
> Task :app:dataBindingMergeDependencyArtifactsDebug UP-TO-DATE
> Task :app:dataBindingMergeGenClassesDebug UP-TO-DATE
> Task :app:generateDebugResValues UP-TO-DATE
> Task :app:generateDebugResources UP-TO-DATE
> Task :app:mergeDebugResources UP-TO-DATE
> Task :app:packageDebugResources UP-TO-DATE
> Task :app:parseDebugLocalResources UP-TO-DATE
> Task :app:dataBindingGenBaseClassesDebug UP-TO-DATE
> Task :app:generateDebugBuildConfig UP-TO-DATE
> Task :app:checkDebugAarMetadata UP-TO-DATE
> Task :app:mapDebugSourceSetPaths UP-TO-DATE
> Task :app:createDebugCompatibleScreenManifests UP-TO-DATE
> Task :app:extractDeepLinksDebug UP-TO-DATE
> Task :app:processDebugMainManifest UP-TO-DATE
> Task :app:processDebugManifest UP-TO-DATE
> Task :app:processDebugManifestForPackage UP-TO-DATE
> Task :app:processDebugResources UP-TO-DATE
> Task :app:javaPreCompileDebug UP-TO-DATE
> Task :app:mergeDebugShaders UP-TO-DATE
> Task :app:compileDebugShaders NO-SOURCE
> Task :app:generateDebugAssets UP-TO-DATE
> Task :app:mergeDebugAssets UP-TO-DATE
> Task :app:compressDebugAssets UP-TO-DATE
> Task :app:processDebugJavaRes NO-SOURCE
> Task :app:checkDebugDuplicateClasses UP-TO-DATE
> Task :app:desugarDebugFileDependencies UP-TO-DATE
> Task :app:mergeExtDexDebug UP-TO-DATE
> Task :app:mergeLibDexDebug UP-TO-DATE
> Task :app:mergeDebugJniLibFolders UP-TO-DATE
> Task :app:mergeDebugNativeLibs NO-SOURCE
> Task :app:stripDebugDebugSymbols NO-SOURCE
> Task :app:validateSigningDebug UP-TO-DATE
> Task :app:writeDebugAppMetadata UP-TO-DATE
> Task :app:writeDebugSigningConfigVersions UP-TO-DATE
> Task :app:compileDebugKotlin
> Task :app:compileDebugJavaWithJavac
> Task :app:mergeDebugJavaResource UP-TO-DATE
> Task :app:dexBuilderDebug UP-TO-DATE
> Task :app:mergeProjectDexDebug
> Task :app:packageDebug
> Task :app:createDebugApkListingFileRedirect UP-TO-DATE
> Task :app:assembleDebug

BUILD SUCCESSFUL in 2s
35 actionable tasks: 4 executed, 31 up-to-date

上面就是点击运行过程中运行的所有Task，我们精简一下，列出上面主要步骤中提到的Task

//aidl 转换aidl文件为java文件
> Task :app:compileDebugAidl

//生成BuildConfig文件
> Task :app:generateDebugBuildConfig

//获取gradle中配置的资源文件
> Task :app:generateDebugResValues

// merge资源文件，AAPT2 编译阶段
> Task :app:mergeDebugResources

// merge assets文件
> Task :app:mergeDebugAssets
> Task :app:compressDebugAssets

// merge所有的manifest文件
> Task :app:processDebugManifest

//生成R文件 AAPT2 链接阶段
> Task :app:processDebugResources

//编译kotlin文件
> Task :app:compileDebugKotlin

//javac 编译java文件
> Task :app:compileDebugJavaWithJavac

//转换class文件为dex文件
> Task :app:dexBuilderDebug

//打包成apk并签名
> Task :app:packageDebug

上面这些Task就对应于上面说的编译过程中的主要步骤，比如mergeDebugResources就对应于AAPT2的编译阶段，在Task结束后，会在build/intermediates/merged_res/文件夹中生成Flat文件
而processDebugResources则对应于AAPT2的链接阶段，会生成R.java与resources.arsc，并合并所有已编译的文件并将它们打包到一个软件包中

关于其他Task内容也都比较多，感兴趣的同学可以自行查看相关源码，这里就不缀述了

总结

本文主要详细介绍了Android APK打包编译的总体流程，主要步骤，以及AGP中相关的Task。这些知识点在平常的开发中或许没有多大用处，但是如果你要做包体积优化，或者编译优化相关的一些工作的话，这些应该是需要了解的前置知识，希望对你有所帮助~

参考资料

Android&Kotlin编译速度原理剖析（上）
从构建工具看 Android APK 编译打包流程
Android D8 编译器 和 R8 工具
Android开发应该知道的签名知识！