/ 今日科技快讯 /
特斯拉全球三地设厂，三座工厂今年二季度各自出现问题，导致当季特斯拉只生产 258580 辆电动车、环比减少约 15%，产能落后于先前预期（35 万辆）和马斯克预警后的数据（31 万辆）。同期比亚迪在 4-6 月份生产 182817 辆纯电动乘用车（小轿车、SUV）、环比增长超过 26%，与特斯拉的差距缩小到 75000 辆左右。但如果算上插电混动乘用车，当季比亚迪电动车产量和销量都超过了特斯拉，其中季度销量是第一次超过特斯拉。
/ 作者简介 /
本篇文章转自程序员江同学的博客，文章主要对Apk编译打包的整体流程进行了探索分析，相信会对大家有所帮助！
原文地址：
https://juejin.cn/post/7113713363900694565
/ 前言 /
作为一个Android开发，每天都会有相当一部分的时间花在编译打包上，如果项目比较大的话编译一次可能就要十几分钟。
那么在编译打包的过程中AGP到底做了什么？为什么编译那么耗时，又该怎么优化？要解决这些问题，首先就需要我们对编译打包的流程有个总体的了解。本文主要包括以下内容。
编译打包总体流程
编译打包主要步骤
编译打包过程中的Task
/ 编译打包总体流程 /
首先看下Android官网给出的编译打包总体流程。
典型 Android 应用的构建流程如图所示，主要分为以下几步：
编译器将您的源代码转换成 DEX 文件（Dalvik 可执行文件，其中包括在 Android 设备上运行的字节码），并将其他所有内容转换成编译后的资源。
打包器将 DEX 文件和编译后的资源组合成 APK 或 AAB（具体取决于所选的 build 目标）。
打包器使用调试或发布密钥库为 APK 或 AAB 签名。
在生成最终 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，我们精简一下，列出上面主要步骤中提到的。
//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。这些知识点在平常的开发中或许没有多大用处，但是如果你要做包体积优化，或者编译优化相关的一些工作的话，这些应该是需要了解的前置知识，希望对你有所帮助~
推荐阅读：
欢迎关注我的公众号
学习技术或投稿
长按上图，识别图中二维码即可关注
扫一扫
1111
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
