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

15,116 阅读11分钟

前言

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

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

本文主要包括以下内容

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

编译打包总体流程

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

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

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

编译打包主要步骤

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

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

资源与代码编译

资源文件编译

apk资源包含:

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

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

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

AAPT2做了什么优化?

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

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

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

  • 2、链接:合并所有已编译的文件并将它们打包到一个软件包中。
    首先,这一步会生成辅助文件,比如R.javaresources.arscR文件大家应该都比较熟悉,就是一个资源索引文件,我们平时引用也都是通过R.的方式引用资源id。而resources.arsc则是资源索引表,供在程序运行时根据id索引到具体的资源
    最后,会将R文件,ressources.arsc文件和之前的二进制文件进行打包,打包到一个软件包中。

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

AIDL文件编译

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

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

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

JavaKotlin文件编译

  • 通过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可以识别的二进制文件吗,为什么还要进行一次转化呢?

这就涉及到另一个问题:JVMDalvik(ART 的区别。

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

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

D8编译器与R8工具

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

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

AGP3.4.0版本中,R8desugaringshrinkingobfuscatingoptimizingdexing 都合并到一步进行执行。在 AGP3.4.0 以前的版本编译流程如下:

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

图片引用自:juejin.cn/post/697308…

生成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,而apksignerGoogle专门为Android提供的签名和签证工具。

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

V1签名

v1签名方式主要是利用META-INFO文件夹中以MFSFRSA 的三个文件,流程如下所示:

图片引用自:juejin.cn/post/711111…

首先,将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.javaresources.arsc,并合并所有已编译的文件并将它们打包到一个软件包中

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

总结

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

参考资料

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