其实我们知道java代码的运行是需要使用虚拟机支持的。就是我们所说的JVM(java Virtual Machine )。运行的就java 经过编译的.class 文件。
但是在android中，我们也已经知道，并不是直接运行的.class文件的，而是dex文件。而且我们知道在java中的每一个类，经过编译之后都会生成一个class文件。这个class 文件包含了我们java 文件中所有需要用到的信息。这种文件在服务器端运行还行，但是到了移动端，就显得不合适了。主要有以下几个方面原因
1、每个java类都会生成class文件。使得加载的时候需要频繁读取文件，加载速度慢
2、文件的加载，堆栈的加栈模式都需要耗费较多的内存资源，对于内存资源稀缺的移动端，是一个明显的短板。
简言之，移动端的资源更加有限，无论是内存，cpu，磁盘都不能跟服务器端比较，所以class文件在移动端运行是不太合适的。于是乎dex文件就诞生了。有人将多个class文件整合成打包成一个dex文件。而且做了较多的优化，比如
1、将多个class整合成一个dex，减少反复读取文件的时间，提高加载速度。
2、dex中对各个 各个数据紧密排列，无间隙，结构的设计上大量使用了索引，减少了文件体积。
那么dex文件被生成出来了，自然就不能用原来的JVM来解析和运行。所以在android上有自己的虚拟机，也就是我们常说的Dalvik虚拟机。
在android 4.4及以前使用的都是Dalvik虚拟机，运行的就是我们的dex文件。但是这个dex 文件并不是我们机器可以直接运行的机器码，所以在dalvik运行dex的时候，会先将dex快速转为可以运行的机器码。而且我们前面也提到过了，dex文件是有大小限制的，而且很多Android开发者可能知道一个65535问题，说的就是单个dex的方法数不得超过65535的上限。于是乎比较大的apk中往往都会包含多个dex，这样dalvik虚拟机在应用冷启动的过程中就会加上一个合包的过程，这样导致的结果就是我们app的启动和运行都会比较慢，这也是Dalvik虚拟机的JIT特性。
为了解决这个问题，在android 5.0只有就开始有了ART虚拟机。
但是为了兼容android4.4及以下的程序，这个ART虚拟机也需要有Dalvik虚拟机的特性，但是就在这个基础上加上了一个很好的特性AOT(ahead of time)。这个特性就是我们在安装APK的时候就将dex直接处理成可直接供ART虚拟机使用的机器码，ART虚拟机将.dex文件转换成可直接运行的.oat文件，ART虚拟机天生支持多dex，所以也不会有一个合包的过程，所以ART虚拟机会很大的提升APP冷启动速度。
这里多提一点，就是我们后面会用到的xposed hook框架（87版本）hook就是java代码，所以是不支持5.0级以上系统的。当然后面xposed 框架也进行了更新，比如我们xposed 89版，支持到android5.0-7.1。
