1. Dalvik＆ART
1.1 Dalvik
Dalvik是Google公司自己設計用于Android平臺的虛擬機。DVM即Dalvik Virtual Machine的縮寫，那么DVM和JVM有什么區別呢？
-
DVM基于寄存器，JVM基于棧
寄存器是CPU上面的一塊存儲空間，棧是內存上面的一段連續的存儲空間，所以CPU直接訪問自己上面的一塊空間的數據的效率肯定要大于訪問內存上面的數據。基于棧架構的程序在運行時虛擬機需要頻繁的從棧上讀取或寫入數據，這個過程需要更多的指令分派與內存訪問次數，會耗費不少CPU時間，對于像手機設備資源有限的設備來說，這是相當大的一筆開銷。DVM基于寄存器架構。數據的訪問通過寄存器間直接傳遞，這樣的訪問方式比基于棧方式要快很多。
-
執行的字節碼文件不一樣
DVM執行的是.dex文件，JVM執行的是.class文件。
AVM解釋執行的是dex字節碼.dex：.java –> .class –> .dex –> .apk
JVM運行的是java字節碼.class：.java –> .class –> .jar
-
運行環境的區別
DVM：允許運行多個虛擬機實例，每一個應用啟動都運行一個單獨的虛擬機，并且運行在一個獨立的進程中
JVM：只能運行一個實例，也就是所有應用都運行在同一個JVM中
1.2 ART
ART即Android Runtime，是在Dalvik的基礎上做了一些優化。在Dalvik下，應用每次運行的時候，字節碼都需要通過即時編譯器（JIT, just in time）轉換為機器碼，這會拖慢應用的運行效率，而在ART 環境中，應用在第一次安裝的時候，字節碼就會預先編譯成機器碼，使其成為真正的本地應用。這個過程叫做預編譯（AOT, Ahead-Of-Time）。這樣的話，應用的啟動(首次)和執行都會變得更加快速。
ART虛擬機執行的本地機器碼：
.java –> java bytecode(.class) –> dalvik bytecode(.dex) –> optimized android runtime machine code(.oat)
1.3 Dalvik和ART區別
Dalvik是運行時解釋dex文件，安裝比較快，開啟應用比較慢，應用占用空間小；ART是安裝的時候字節碼預編譯成機器碼存儲在本地，執行的時候直接就可以運行的，安裝慢，開啟應用快，占用空間大；
比較喜歡一個騎自行車的例子，Dalvik好比一個已經折疊起來的自行車，每次騎之前都要先組裝才能騎，ART相當于一個已經組裝好的自行車，每次直接騎著就走了。
2. dex＆odex＆oat
2.1 dex
dex(Dalvik Executable)，本質上java文件編譯后都是字節碼，只不過JVM運行的是.class字節碼，而DVM運行的是.dex字節碼，sdk\build-tools\25.0.2\dx工具負責將Java字節碼.class文件轉換為Dalvik字節碼.dex，dx工具對Java類文件重新排列，消除在類文件中出現的所有冗余信息，避免虛擬機在初始化時出現反復的文件加載與解析過程。一般情況下，Java類文件中包含多個不同的方法簽名，如果其他的類文件引用該類文件中的方法，方法簽名也會被復制到其類文件中，也就是說，多個不同的類會同時包含相同的方法簽名，同樣地，大量的字符串常量在多個類文件中也被重復使用。這些冗余信息會直接增加文件的體積，同時也會嚴重影響虛擬機解析文件的效率。消除其中的冗余信息，重新組合形成一個常量池，所有的類文件共享同一個常量池，由于dx工具對常量池的壓縮，使得相同的字符串，常量在DEX文件中只出現一次，從而減小了文件的體積，同時也提高了類的查找速度，此外，dex格式文件增加了新的操作碼支持，文件結構也相對簡潔，使用等長的指令來提高解析速度。
2.2 odex
odex(Optimized dex)，即優化的dex，主要是為了提高DVM的運行速度，在編譯打包APK時，Java類會被編譯成一個或者多個字節碼文件（.class），通過dx工具CLASS文件轉換成一個DEX（Dalvik Executable）文件。 通常情況下，我們看到的Android應用程序實際上是一個以.apk為后綴名的壓縮文件。我們可以通過壓縮工具對apk進行解壓，解壓出來的內容中有一個名為classes.dex的文件。那么我們首次開機的時候系統需要將其從apk中解壓出來保存在data/app目錄中。 如果當前運行在Dalvik虛擬機下，Dalvik會對classes.dex進行一次“翻譯”，“翻譯”的過程也就是守護進程installd的函數dexopt來對dex字節碼進行優化，實際上也就是由dex文件生成odex文件，最終odex文件被保存在手機的VM緩存目錄data/dalvik-cache下（注意！這里所生成的odex文件依舊是以dex為后綴名，格式如：system@priv-app@Settings@Settings.apk@classes.dex）。如果當前運行于ART模式下， ART同樣會在首次進入系統的時候調用/system/bin/dexopt（此處應該是dex2oat工具吧）工具來將dex字節碼翻譯成本地機器碼，保存在data/dalvik-cache下。 那么這里需要注意的是，無論是對dex字節碼進行優化，還是將dex字節碼翻譯成本地機器碼，最終得到的結果都是保存在相同名稱的一個odex文件里面的，但是前者對應的是一個.dex文件（表示這是一個優化過的dex），后者對應的是一個.oat文件。通過這種方式，原來任何通過絕對路徑引用了該odex文件的代碼就都不需要修改了。 由于在系統首次啟動時會對應用進行安裝，那么在預置APK比較多的情況下，將會大大增加系統首次啟動的時間。
從前面的描述可知，既然無論是DVM還是ART，對DEX的優化結果都是保存在一個相同名稱的odex文件，那么如果我們把這兩個過程在ROM編譯的時候預處理提取Odex文件將會大大優化系統首次啟動的時間。具體做法則是在device目錄下的/device/huawei/angler/BoardConfig.mk中定義WITH_DEXPREOPT := true，打開這個宏之后，無論是有源碼還是無源碼的預置apk預編譯時都會提取odex文件，不過這里需要注意的是打開WITH_DEXPREOPT 宏之后，預編譯時提取Odex會增加一定的空間，預置太多apk，會導致system.img 過大，而編譯不過。遇到這種情況可以通過刪除apk中的dex文件、調大system.img的大小限制，或在預編譯時跳過一些apk的odex提取。
2.3 oat
oat文件是ART的核心，是通過/system/bin/dex2oat 工具生成的，實際上是一個自定義的elf文件，里面包含的都是本地機器指令，通過AOT生成的文件，在系統中的表現形式有OAT、ART、ODEX，其中大部分apk在執行AOT后生成的都是odex文件。但是由dex2oat工具生成的oat文件包含有兩個特殊的段oatdata和oatexec，前者包含有用來生成本地機器指令的dex文件內容，后者包含有生成的本地機器指令，進而就可以直接運行。其是通過PMS –> installd –> dex2oat的流程生成的，可以在預編譯的時候，也可以在開機apk掃描的過程中或者apk安裝過程中生成。
3. JIT＆AOT
3.1 JIT
JIT(Just In Time Compiler， 即時編譯)，與Dalvik虛擬機相關。
JIT在2.2版本提出的，目的是為了提高android的運行速度，一直存活到4.4版本，因為在4.4之后的ROM中，就不存在Dalvik虛擬機了。我們使用Java開發android，在編譯打包APK文件時，會經過以下流程：
- Java編譯器將應用中所有Java文件編譯為class文件
- dx工具將應用編譯輸出的類文件轉換為Dalvik字節碼，即dex文件
DVM負責解釋dex文件為機器碼，如果我們不做處理的話，每次執行代碼，都需要Dalvik將java代碼由解釋器(Interpreter)將每個java指令轉譯為微處理器指令，并根據轉譯后的指令先后次序依序執行，一條java指令可能對應多條微處理器指令，這樣效率不高。為了解決這個問題，Google在2.2版本添加了JIT編譯器，當App運行時，每當遇到一個新類，JIT編譯器就會對這個類進行編譯，經過編譯后的代碼，會被優化成相當精簡的原生型指令碼（即native code），這樣在下次執行到相同邏輯的時候，速度就會更快。但是使用JIT也不一定加快執行速度，如果大部分代碼的執行次數很少，那么編譯花費的時間不一定少于執行dex的時間。Google當然也知道這一點，所以JIT不對所有dex代碼進行編譯，而是只編譯執行次數較多的dex為本地機器碼。
3.2 AOT
AOT(Ahead Of Time)，和ART虛擬機相關。
JIT是運行時編譯，這樣可以對執行次數頻繁的dex代碼進行編譯和優化，減少以后使用時的翻譯時間，雖然可以加快Dalvik運行速度，但是還是有弊病，那就是將dex翻譯為本地機器碼也要占用時間，所以Google在4.4之后推出了ART，用來替換Dalvik。
在4.4版本上，兩種運行時環境共存，可以相互切換，但是在5.0+，Dalvik虛擬機則被徹底的丟棄，全部采用ART。ART的策略與Dalvik不同，在ART 環境中，應用在第一次安裝的時候，字節碼就會預先編譯成機器碼，使其成為真正的本地應用。之后打開App的時候，不需要額外的翻譯工作，直接使用本地機器碼運行，因此運行速度提高。
總的來說：
- JIT代表運行時編譯策略，也可以理解成一種運行時編譯器，是為了加快Dalvik虛擬機解釋dex速度提出的一種技術方案，來緩存頻繁使用的本地機器碼
- AOT可以理解運行前編譯策略，ART虛擬機的主要特征就是AOT
4. Android N上的改變
4.1 ART缺點
- dex->oat生成時間太久,進而apk安裝時間很久
- dex2oat耗用系統資源太多，特別dex2oat占用cpu和memory
- oat文件過大，rom小的設備data空間會吃緊
- Powerconsumption 增加
- ART不太穩定，在M上crash問題太多，debug不太容易
- oat文件是elf格式，所以加載oat文件時候相關依賴庫也很多，間接導致app進程占用Memory的增加
