android的ART虚拟机初探（非常详细）从零基础到精通，收藏这篇就够了！

最新推荐文章于 2025-07-19 11:04:04 发布

原创最新推荐文章于 2025-07-19 11:04:04 发布 · 834 阅读

13 ·

CC 4.0 BY-SA版权

文章标签：

#android #学习 #网络 #xss #nosql #okhttp

背景

在android4.4版本开始引入ART虚拟机，并从Android 5.0系统开始，ART虚拟机(Android Runtime)就彻底代替了原先的Dalvik虚拟机，成为Android系统上新的虚拟机。

Dalvik虚拟机缺陷

1.Dalvik是为32位设计的，不适用于64位CPU。

2.单纯的字节码解释加JIT编译的执行方式，性能要弱于本地机器码的执行。

3.无论是解释执行还是JIT编译都是单次运行过程中发生，每运行一次都可能需要重新做这些工作，这样做太浪费资源。

4.原先的垃圾回收机制不够好，会导致卡顿。

ART虚拟机优势

AOT编译：

Ahead-of-time（AOT）是相对于Just-in-time（JIT）而言的。JIT是在运行时进行字节码到本地机器码的编译，这也是为什么Java普遍被认为效率比C++差的原因。无论是解释器的解释还是运行过程中即时编译，都比C++编译出的本地机器码执行多了一个耗费时间的过程。而AOT就是向C++编译过程靠拢的一项技术：当APK在安装的时候，系统会通过一个名称为dex2oat的工具将APK中的dex文件编译成包含本地机器码的oat文件存放下来。这样做之后，在程序执行的时候，就可以直接使用已经编译好的机器码以加快效率。

垃圾回收的改进：

GC（Garbage Collection）是虚拟机非常重要的一个特性，因为它的实现好坏会影响所有在虚拟机上运行的应用。GC实现得不好可能会导致画面跳跃，掉帧，UI响应过慢等问题。

ART的垃圾回收机制优化

1.将GC的停顿由2次改成1次

2.在仅有一次的GC停顿中进行并行处理

3.在特殊场景下，对于近期创建的具有较短生命的对象消耗更少的时间进行垃圾回收

4.改进垃圾收集的工效，更频繁的执行并行垃圾收集

5.对于后台进程的内存在垃圾回收过程进行压缩以解决碎片化的问题

AOT编译是在应用程序安装时就进行的工作，下图描述了Dalvik虚拟机与（Android 5.0上的）ART虚拟机在安装APK时的区别：

从上图中我们看到：

在Dalvik虚拟机上，APK中的Dex文件在安装时会被优化成odex文件，在运行时，会被JIT编译器编译成native代码。
而在ART虚拟机上安装时，Dex文件会直接由dex2oat工具翻译成oat格式的文件，oat文件中既包含了dex文件中原先的内容，也包含了已经编译好的native代码。

dex2oat生成的oat文件在设备上位于/data/dalvik-cache/目录下。同时，由于32位和64位的机器码有所区别，因此这个目录下还会通过子文件夹对oat文件进行分类。例如，手机上通常会有下面两个目录：

/data/dalvik-cache/arm/
/data/dalvik-cache/arm64/

OAT文件格式

OAT文件遵循ELF格式。ELF是android系统上可执行文件，是目标文件，共享库和Core dump文件的标准格式。ELF全称是Executable and Linkable Format。OAT文件的格式如下。

从上图中我们看到，OAT文件中包含的内容有：

ELF Header：ELF头信息。
oatdata symbol：oatdata符号，其地址指向了OAT头信息。
Header：Oat文件的头信息，详细描述了Oat文件中的内容。例如：Oat文件的版本，Dex文件个数，指令集等等信息。Header，Dex File数组以及Class Metadata数组都位于ELF的只读数据段(.rodata)中。
Dex File数组：生成该Oat文件的Dex文件，可能包含多个。
Class Metadata数组：Dex中包含的类的基本信息，可能包含多个。通过其中的信息可以索引到编译后的机器码。
编译后的方法代码数组：每个方法编译后对应的机器码，可能包含多个。这些内容位于代码段（.text）中。

我们可以通过/art/目录下的这些源码文件来详细了解Oat文件的结构：