前言

植物的茁壮成长离不开肥沃的土地，同样，对于java和android程序来说的离不开虚拟机。

JVM、Dalvik、ART三种虚拟机在Java和Android世界中起到至关重要的作用，可以说Dalvik和ART由JVM演化而来，并且ART是Dalvik的替代品。

下面分别对这三种虚拟机做下介绍：

JVM介绍

JVM是Java Virtual Machine（Java虚拟机）的缩写，JVM是一种用于计算设备的规范，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。

Java语言的一个非常重要的特点就是与平台的无关性。而使用Java虚拟机是实现这一特点的关键。一般的高级语言如果要在不同的平台上运行，至少需要编译成不同的目标代码。而引入Java语言虚拟机后，Java语言在不同平台上运行时不需要重新编译。Java语言使用Java虚拟机屏蔽了与具体平台相关的信息，使得Java语言编译程序只需生成在Java虚拟机上运行的目标代码（字节码），就可以在多种平台上不加修改地运行。Java虚拟机在执行字节码时，把字节码解释成具体平台上的机器指令执行。这就是Java的能够“一次编译，到处运行”的原因。

JRE ：英文名称（Java Runtime Environment），Java 运行时环境。它主要包含两个部分，jvm 的标准实现和 Java 的一些基本类库。它相对于 jvm 来说，多出来的是一部分的 Java 类库。

JDK ：英文名称（Java Development Kit），Java 开发工具包。jdk 是整个 Java 开发的核心，它集成了 jre 和一些好用的小工具。例如：javac.exe，java.exe，jar.exe 等。

显然，这三者的关系是：JDK  > JRE > JVM

Dalvik介绍

Google为什么不用JVM来当做android虚拟机？原因是版权和效率问题。

Dalvik是Google为Android平台专门开发的虚拟机，它是Android应用的解释执行器。Dalvik虚拟机并非JVM的简单替代品，它有自己鲜有的特点。

不同于JVM的基于虚拟栈，Dalvik虚拟机最大的特点是基于寄存器。Java是一种编翻译编解释的语言，需要把java代码编译成字节码来执行，为了实现这一目的，生成的中间代码没有使用寄存器，而是使用栈来实现，这也是能跨平台的原因，但是这样会对运行速度造成负面影响。Dalvik设计之初是为了运行在嵌入式设备上，对性能要求比较高，并且对跨平台没有多大要求，因此Dalvik使用寄存器来加快代码的执行速度。

既然使用了寄存器，那么字节码便无法继续使用，Android使用Dex文件来代替Java虚拟机的class文件，相比于class文件，Dex文件有以下的改进：

1.  生成Dex文件时，会把所有的class文件整合到一个Dex文件中，同时对所有类进行优化整合，去除冗余信息，不但见笑了整个文件的大小，也提高了类的装载速度。

2.  Dex文件会把每个类文件中的常量进行整合，最后放到一个常量池中，节约了内存的使用。

3.  Dex文件的签名只有一份，验证也只有一次。

4.  Dalvik虚拟机为应用创建的线程都是linux线程，通过Linux内核来进行线程管理，效率高。

Dalvik使用JIT（Just-In-Time）也称运行时编译，是一种将字节码翻译成机器码的技术，要点是把翻译好的机器码缓存起来，而不是每次都进行解释，以节省时间。Android从2.2开始引入JIT编译器，但是实际效果并没有那么显著，虽然Android一直在改进，但是作用有限，因此在Android4.4中引入了新的编译技术ART。

ART介绍

ART全称Android Runtime，在Android4.4引入与Dalvik并存，在Android5.0及以后版本作为缺省虚拟机配置。

ART内置AOT（Ahead-of-Time）编译器，在应用安装期间，系统会通过一个名称为dex2oat的工具将APK中的dex文件编译成包含本地机器码的oat文件存放下来。这样做之后，在程序执行的时候，就可以直接使用已经编译好的机器码以加快效率，由于运行时不在需要JIT编译，所以代码执行的速度要快的多。

ART的优点：

1.应用运行更快，因为Dex在安装的时候已经被翻译完成。

2.减少应用的启动时间，因为直接执行的是native代码

3.提高设备的续航能力，因为不需要JIT

4.改善了垃圾回收机制

ART的缺点：

由于安装的时候需要翻译成机器码并存储在设备上，所以安装的时候需要更长的时间和更大的空间。

android 8.0中dex vdex odex art oat文件的区别

dex：应用程序二进制字节码文件，虚拟机执行程序前需将其优化。

apk内部目录

odex：Android8.0之前系统会对dex文件做优化，生成可执行文件odex，保存到data/dalvik-cache目录。Android8.0之后odex 是从vdex 这个文件中提取了部分模块生成的一个新的可执行二进制码文件 ， odex从vdex 中提取后，vdex 的大小就减少了（ odex + vdex 才代表一个apk ）。

vdex：android8.0 新增的格式包，dex代码 直接转化的 可执行二进制码 文件，第一次开机就会生成在/system/app/<packagename>/oat/ 下。在系统运行过程中，虚拟机将其 从 “/system/app” 下 copy 到 “/data/davilk-cache/” 下。

art：odex进行优化 生成的可执行二进制码文件，由虚拟机负责生成。主要是apk 启动的热点函数相关地址的记录，方便寻址相关； 生成art 文件后，/system/app 下的odex 和 vdex 会无效，即使你删除，apk也会正常运行。push 一个新的apk file 覆盖之前/system/app 下apk file ，会触发PKMS 扫描时下发force_dex flag ，强行生成新的vdex 文件，覆盖之前的vdex 文件，由于某种机制，这个新vdex 文件会copy到/data/dalvik-cache/下，于是art 文件也变化了。

oat：ART虚拟机使用的是oat文件，oat文件是一种Android私有ELF文件格式，它不仅包含有从DEX文件翻译而来的本地机器指令，还包含有原来的DEX文件内容。APK在安装的过程中，会通过dex2oat工具生成一个OAT文件。对于apk来说，oat文件实际上就是对odex文件的包装，即oat=odex，而对于一些framework中的一些jar包，会生成相应的oat尾缀的文件，如system@framework@boot-telephony-common.oat。

问题：Android5.0已经开始使用art了，为什么还要保留odex？

DEX转换成OAT的这个过程是5.0以上系统用户在安装程序或是刷入ROM、增量更新后首次启动时必然执行的。 按照Google的说法，相比做过ODEX优化，未做过优化的DEX转换成OAT要花费更长的时间，比如2-3倍。 比如安装一个odex优化过的程序假设需要1秒钟，未做过优化的程序就需要2~3秒。 由此可见，虽然dalvik被弃用了，但ODEX优化在Android 5.0系统以上依旧起着作用。