作为一个Android开发，每天都会有适当一部分的时刻花在编译打包上，假如项目比较大的话编译一次或许就要十几分钟。

那么在编译打包的过程中AGP究竟做了什么？为什么编译那么耗时，又该怎样优化？要解决这些问题，首要就需求咱们对编译打包的流程有个整体的了解。本文首要包含以下内容。

  1. 编译打包整体流程
  2. 编译打包首要过程
  3. 编译打包过程中的Task

/ 编译打包整体流程 /

首要看下Android官网给出的编译打包整体流程。

Android APK编译打包流程【解析】

Android APK编译打包流程【解析】

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

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

/ 编译打包首要过程 /

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

Android APK编译打包流程【解析】

这个看起来是适当杂乱的，但其实咱们也能够把这些过程做一个分类，跟整体流程的四个过程做一个对应。

资源与代码编译

资源文件编译

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文件，让这些类能够共享数据，类似这种关系：

Android APK编译打包流程【解析】

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之后的编译流程如下：

Android APK编译打包流程【解析】

生成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 的三个文件，流程如下所示：

Android APK编译打包流程【解析】

首要，将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签名分块，位于中心目录部分之前，如下图：

Android 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，咱们精简一下，列出上面首要过程中说到的。

//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内容也都比较多，感兴趣的同学能够点击这儿检查更多> 能够> 前往

传送直达↓↓↓ ：www.6hu.cc/go//?target=htt…

/ 总结 /

本文首要具体介绍了Android APK打包编译的整体流程，首要过程，以及AGP中相关的Task。这些常识点在平常的开发中或许没有多大用处，可是假如你要做包体积优化，或许编译优化相关的一些作业的话，这些应该是需求了解的前置常识