其實我們知道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。