阅读 659

Android打包相关知识整理(一)

Android打包相关知识整理(一)

整理Android打包相关的一些知识点,内容包括了一些基础概念,apk打包、安装的流程。

JVM Dalvik ART

JVM & DVM

DVM,即Dalvik,是Google开发的用于Android平台的Java虚拟机,JVM则是传统的Java虚拟机,有很多具体的版本,是跨平台的。那么他们的区别主要体现在以下几点:

  1. 从架构上看,JVM是基于栈的,DVM是基于寄存器的。
  2. JVM执行的是由Java文件编译的.class文件,而DVM则执行的是有Java文件编译为.class文件后,再次编译得到的.dex文件。
  3. JVM只能运行一个实例,若干应用程序都在同一个虚拟机中。而DVM则可以运行多个虚拟机实例,每一个app都运行在单独的虚拟机进程中。

DVM & ART

ART,即Android Runtime,也算是Dalvik虚拟机的升级版。从Android 4.4版本开始,系统就已经内置了ART,直到5.0开始,完全用ART替换了Dalvik。
Dalvik安装的app,在运行时会动态的将一部分字节码解释为机器码,这一过程是即时编译,JIT(Just in time),而ART则是在一开始安装app时就将字节码转换为了机器码并存在存储相应的存储空间,这一过程是提前编译,AOT(Ahead of time)。
因此,DVM下app运行较慢,且会频繁的访问cpu,而ART下app虽然安装时间更长且占用了更多的空间,但是启动、运行速度有了提升,节省了电量的消耗。

JIT & AOT

前面提到了JIT和AOT只是两种不同的编译形式,一种是即使编译,一种是提前编译。
JIT是从Android 2.2引入的。虚拟机执行的是字节码DEX,但是机器执行的是机器码,因此每次运行程序的时候,都需要将DEX转换为本地的机器码,交给机器执行。加入JIT后,这一过程就由JIT来处理了。具体来讲,就是在程序运行中,每遇到一个新类,就会对这个类进行编译,编译后的结果转换为精简的原生指令码,这样下次执行到同样的逻辑时,直接执行这一精简原生指令码,就会提高运行速度了。但是如果对所有的类都进行JIT,那么那些执行次数较少的类就会拖慢整体的速度,因为你转换毕竟也是需要时间的嘛。所以并不是对所有代码都执行JIT的,是有选择的。此外,JIT并不是一劳永逸的,在每次运行时,都要重新进行JIT。
AOT相对来说,则是“用空间换时间”。在第一次安装时,就已经将字节码转换为了机器码,并保存在特定的存储空间。这样会导师安装时较慢,且会占用额外的存储空间,但是好处也是很明显的,程序运行时直接执行机器码即可,运行速度有了提升。
无论是JIT还是AOT,各有优缺点。所以Google在Android 7.0上将JIT和AOT合并起来一起用。具体来说,应用在初次安装时,不会提前编译了,因此安装速度不会降低。在应用运行时,会通过JIT优化,存储在jit code cache中,同时标记执行次数较多的函数并记录在profile文件中。等手机进入charging和idle状态时,系统会每隔一段时间扫描这些profile文件,执行AOT。以为只优化了那些热点函数,因此在初次运行时没有很明显的变化,在多次运行后,才会有速度的显著提升。同时所占用的额外存储空间也小了,安装速度也提高了。

DEX ODEX OAT

JVM执行的是由类文件编译出的.class文件,而Android虚拟机,执行的是由.class文件进一步处理得到的文件,这一处理过程即dx,得到的文件为.dex文件。
所以DEX文件简单来说就是有.class文件通过dx工具转化的。一般情况下,一个项目中有很多类文件,会生成很多.class文件,这些多个.class文件会通过文件内容的优化,然后合并,最终得到一个.dex文件(在不考虑64k这种特殊情况下)。
ODEX文件,即Optimized dex,是DEX经过优化后得到的文件。他并不是一种文件格式,即不存在什么.odex后缀,他只是一种类型,即DEX文件经过优化后的文件类型。那么具体来说,一个.dex文件在经过优化后,后缀可能还是.dex,也可能变成了新的.oat,但是他们都还是属于ODEX文件——优化后的DEX文件。
具体来讲,我们app打包成apk后,apk作为一种压缩文件,内部包含了DEX文件。在系统首次开机时,会解压apk文件,取出其中的DEX文件,存储到系统的data/app目录下。然后,重点来了,如果当前运行的是Dalvik虚拟机,那么DEX文件会被Dalvik虚拟机进行一次优化,这次优化是通过函数dexopt执行的,优化产生的文件名还是旧的文件名,后缀还是.dex,只是他现在已经不是DEX文件,而是优化的DEX文件,也就是ODEX文件了。而如果当前系统运行的虚拟机是ART,那么DEX文件也会被ART虚拟机做一次优化,这次优化是通过dex2oat工具执行的,优化后生成的文件名还是旧的文件名,后缀变成了.oat,文件类型也变成了ODEX。两种优化方式最终都会将ODEX文件存放至系统的data/dalvik-cache目录下。
为什么要这样处理文件名呢?因为虚拟机是从Dalvik过渡到ART上的,这样的优化后文件名不变,路径,那么任何通过绝对路径来引用ODEX文件的代码就都不用修改了。

apk

apk的内容

分析打包过程,首先看一下打包后的结果,然后逆推每一部分是如何打包的。
apk全称是Android Package,其实就是一个后缀为.apk的压缩文件,他包含了Android App包含的代码、资源的所有数据。用解压工具解压一个apk包后,可以看到目录如下:

  1. AndroidManifest.xml

这一文件是Android应用程序的清单文件,我们平时写应用时都会和他打交道。这一文件内包含了应用程序的所有界面、权限、BroadCast等内容,以及程序自己的相关信息,这个文件相当于是应用程序用来给系统做一个自我介绍。
2. assets 这一目录存放了apk中的静态资源文件,需要通过AssetManager类来访问内容。
3. classes.dex
Android项目中的代码在编译后会生成.class文件,然后再通过dx工具转换为字节码文件,就是这个dex文件。一般情况下只有一个classes.dex,如果项目代码方法数超过了65535而采用了multidex的话,会有其他的.dex文件。
4. META-INF
这以目录包含了应用程序的签名信息,用来验证apk文件的完整性、合法性,帮助系统在安装应用程序时能够确保apk文件是完整、安全的,没有被破坏、修改。
5. res
这一目录下存放了所有的其他资源,包括像layout资源、drawable资源等,这些资源都映射到一个个资源ID,应用程序则通过资源的索引来访问这些资源文件。
6. resources.arsc
资源的索引,是通过资源ID来做的。这里的resources.arsc是一个资源索引表,相当于记录了资源文件路径与其对应的ID的一个表,而R.java文件,则定义了资源关联的ID。在程序中通过R文件定义的资源名称,获取资源ID,进而用资源ID在resources.arsc中获取到资源的具体路径。

apk打包流程

这是最新的官网的打包流程图:
这是旧版官网的打包流程图:

相对而已,旧版的更加详细一点。就拿旧版的打包流程图来说吧,打包主要有以下几步:

  1. 使用aapt工具处理所有的资源,生成一个R.java文件,一个resources.arsc文件以及其他资源。

  2. 处理.aidl文件,生成对应的Java接口文件。

  3. 将上述两步得到的R.java文件、Java接口文件,与Andorid源码一起,通过Java编译器,编译得到Java字节码文件.class文件。

  4. 获取依赖的第三方库文件,将其与上一步得到的.class文件一起,通过使用dx工具,生成.dex文件。

  5. 将资源索引文件resources.arsc、资源目录res、与上一步得到的.dex文件一起,通过apkbuilder工具,构建出初始的.apk文件。

  6. 使用jarsigner工具,对.apk文件进行签名。

  7. 使用zipalign工具,对.apk文件进行对齐。(让资源按四字节的边界进行对齐,加快资源的访问速度)

经过以上七步,一个完成的apk文件就诞生了。

apk安装过程

Android应用的安装涉及到以下几个目录:

  • /data/app:存放apk文件
  • /data/data:存放应用程序的数据
  • /data/dalvik-cache:存放ODEX文件

具体的安装过程如下:

  1. 将apk文件复制到系统的/data/app目录下。
  2. 解压apk文件。
  3. 通过apk文件中的签名文件,校验签名,验证apk包的合法、安全性。
  4. 解压并校验.dex文件。
  5. 将解压得到的.dex文件进行优化,产生odex文件,存储在/data/dalvik-cache目录下。
  6. 在/data/data目录下,以应用程序的包名为名,创建一个目录,用来存储应用程序的所有数据。