關(guān)于Dalvik、ART、DEX、JIT、AOT

1. Dalvik＆ART

1.1 Dalvik

Dalvik是Google公司自己設(shè)計(jì)用于Android平臺(tái)的虛擬機(jī)。DVM即Dalvik Virtual Machine的縮寫，那么DVM和JVM有什么區(qū)別呢？

  1. DVM基于寄存器，JVM基于棧

    寄存器是CPU上面的一塊存儲(chǔ)空間，棧是內(nèi)存上面的一段連續(xù)的存儲(chǔ)空間，所以CPU直接訪問自己上面的一塊空間的數(shù)據(jù)的效率肯定要大于訪問內(nèi)存上面的數(shù)據(jù)?；跅＜軜?gòu)的程序在運(yùn)行時(shí)虛擬機(jī)需要頻繁的從棧上讀取或?qū)懭霐?shù)據(jù)，這個(gè)過程需要更多的指令分派與內(nèi)存訪問次數(shù)，會(huì)耗費(fèi)不少CPU時(shí)間，對(duì)于像手機(jī)設(shè)備資源有限的設(shè)備來說，這是相當(dāng)大的一筆開銷。DVM基于寄存器架構(gòu)。數(shù)據(jù)的訪問通過寄存器間直接傳遞，這樣的訪問方式比基于棧方式要快很多。

  2. 執(zhí)行的字節(jié)碼文件不一樣

    DVM執(zhí)行的是.dex文件，JVM執(zhí)行的是.class文件。

    AVM解釋執(zhí)行的是dex字節(jié)碼.dex：.java –> .class –> .dex –> .apk

    JVM運(yùn)行的是java字節(jié)碼.class：.java –> .class –> .jar

  3. 運(yùn)行環(huán)境的區(qū)別

    DVM：允許運(yùn)行多個(gè)虛擬機(jī)實(shí)例，每一個(gè)應(yīng)用啟動(dòng)都運(yùn)行一個(gè)單獨(dú)的虛擬機(jī)，并且運(yùn)行在一個(gè)獨(dú)立的進(jìn)程中

    JVM：只能運(yùn)行一個(gè)實(shí)例，也就是所有應(yīng)用都運(yùn)行在同一個(gè)JVM中

1.2 ART

ART即Android Runtime，是在Dalvik的基礎(chǔ)上做了一些優(yōu)化。在Dalvik下，應(yīng)用每次運(yùn)行的時(shí)候，字節(jié)碼都需要通過即時(shí)編譯器（JIT, just in time）轉(zhuǎn)換為機(jī)器碼，這會(huì)拖慢應(yīng)用的運(yùn)行效率，而在ART 環(huán)境中，應(yīng)用在第一次安裝的時(shí)候，字節(jié)碼就會(huì)預(yù)先編譯成機(jī)器碼，使其成為真正的本地應(yīng)用。這個(gè)過程叫做預(yù)編譯（AOT, Ahead-Of-Time）。這樣的話，應(yīng)用的啟動(dòng)(首次)和執(zhí)行都會(huì)變得更加快速。

ART虛擬機(jī)執(zhí)行的本地機(jī)器碼：

.java –> java bytecode(.class) –> dalvik bytecode(.dex) –> optimized android runtime machine code(.oat)

1.3 Dalvik和ART區(qū)別

Dalvik是運(yùn)行時(shí)解釋dex文件，安裝比較快，開啟應(yīng)用比較慢，應(yīng)用占用空間小；ART是安裝的時(shí)候字節(jié)碼預(yù)編譯成機(jī)器碼存儲(chǔ)在本地，執(zhí)行的時(shí)候直接就可以運(yùn)行的，安裝慢，開啟應(yīng)用快，占用空間大；

比較喜歡一個(gè)騎自行車的例子，Dalvik好比一個(gè)已經(jīng)折疊起來的自行車，每次騎之前都要先組裝才能騎，ART相當(dāng)于一個(gè)已經(jīng)組裝好的自行車，每次直接騎著就走了。

2. dex＆odex＆oat

2.1 dex

dex(Dalvik Executable)，本質(zhì)上java文件編譯后都是字節(jié)碼，只不過JVM運(yùn)行的是.class字節(jié)碼，而DVM運(yùn)行的是.dex字節(jié)碼，sdk\build-tools\25.0.2\dx工具負(fù)責(zé)將Java字節(jié)碼.class文件轉(zhuǎn)換為Dalvik字節(jié)碼.dex，dx工具對(duì)Java類文件重新排列，消除在類文件中出現(xiàn)的所有冗余信息，避免虛擬機(jī)在初始化時(shí)出現(xiàn)反復(fù)的文件加載與解析過程。一般情況下，Java類文件中包含多個(gè)不同的方法簽名，如果其他的類文件引用該類文件中的方法，方法簽名也會(huì)被復(fù)制到其類文件中，也就是說，多個(gè)不同的類會(huì)同時(shí)包含相同的方法簽名，同樣地，大量的字符串常量在多個(gè)類文件中也被重復(fù)使用。這些冗余信息會(huì)直接增加文件的體積，同時(shí)也會(huì)嚴(yán)重影響虛擬機(jī)解析文件的效率。消除其中的冗余信息，重新組合形成一個(gè)常量池，所有的類文件共享同一個(gè)常量池，由于dx工具對(duì)常量池的壓縮，使得相同的字符串，常量在DEX文件中只出現(xiàn)一次，從而減小了文件的體積，同時(shí)也提高了類的查找速度，此外，dex格式文件增加了新的操作碼支持，文件結(jié)構(gòu)也相對(duì)簡(jiǎn)潔，使用等長(zhǎng)的指令來提高解析速度。

2.2 odex

odex(Optimized dex)，即優(yōu)化的dex，主要是為了提高DVM的運(yùn)行速度，在編譯打包APK時(shí)，Java類會(huì)被編譯成一個(gè)或者多個(gè)字節(jié)碼文件（.class），通過dx工具CLASS文件轉(zhuǎn)換成一個(gè)DEX（Dalvik Executable）文件。 通常情況下，我們看到的Android應(yīng)用程序?qū)嶋H上是一個(gè)以.apk為后綴名的壓縮文件。我們可以通過壓縮工具對(duì)apk進(jìn)行解壓，解壓出來的內(nèi)容中有一個(gè)名為classes.dex的文件。那么我們首次開機(jī)的時(shí)候系統(tǒng)需要將其從apk中解壓出來保存在data/app目錄中。 如果當(dāng)前運(yùn)行在Dalvik虛擬機(jī)下，Dalvik會(huì)對(duì)classes.dex進(jìn)行一次“翻譯”，“翻譯”的過程也就是守護(hù)進(jìn)程installd的函數(shù)dexopt來對(duì)dex字節(jié)碼進(jìn)行優(yōu)化，實(shí)際上也就是由dex文件生成odex文件，最終odex文件被保存在手機(jī)的VM緩存目錄data/dalvik-cache下（注意！這里所生成的odex文件依舊是以dex為后綴名，格式如：system@priv-app@Settings@Settings.apk@classes.dex）。如果當(dāng)前運(yùn)行于ART模式下， ART同樣會(huì)在首次進(jìn)入系統(tǒng)的時(shí)候調(diào)用/system/bin/dexopt（此處應(yīng)該是dex2oat工具吧）工具來將dex字節(jié)碼翻譯成本地機(jī)器碼，保存在data/dalvik-cache下。 那么這里需要注意的是，無論是對(duì)dex字節(jié)碼進(jìn)行優(yōu)化，還是將dex字節(jié)碼翻譯成本地機(jī)器碼，最終得到的結(jié)果都是保存在相同名稱的一個(gè)odex文件里面的，但是前者對(duì)應(yīng)的是一個(gè).dex文件（表示這是一個(gè)優(yōu)化過的dex），后者對(duì)應(yīng)的是一個(gè).oat文件。通過這種方式，原來任何通過絕對(duì)路徑引用了該odex文件的代碼就都不需要修改了。 由于在系統(tǒng)首次啟動(dòng)時(shí)會(huì)對(duì)應(yīng)用進(jìn)行安裝，那么在預(yù)置APK比較多的情況下，將會(huì)大大增加系統(tǒng)首次啟動(dòng)的時(shí)間。

從前面的描述可知，既然無論是DVM還是ART，對(duì)DEX的優(yōu)化結(jié)果都是保存在一個(gè)相同名稱的odex文件，那么如果我們把這兩個(gè)過程在ROM編譯的時(shí)候預(yù)處理提取Odex文件將會(huì)大大優(yōu)化系統(tǒng)首次啟動(dòng)的時(shí)間。具體做法則是在device目錄下的/device/huawei/angler/BoardConfig.mk中定義WITH_DEXPREOPT := true，打開這個(gè)宏之后，無論是有源碼還是無源碼的預(yù)置apk預(yù)編譯時(shí)都會(huì)提取odex文件，不過這里需要注意的是打開WITH_DEXPREOPT 宏之后，預(yù)編譯時(shí)提取Odex會(huì)增加一定的空間，預(yù)置太多apk，會(huì)導(dǎo)致system.img 過大，而編譯不過。遇到這種情況可以通過刪除apk中的dex文件、調(diào)大system.img的大小限制，或在預(yù)編譯時(shí)跳過一些apk的odex提取。
2.3 oat
oat文件是ART的核心，是通過/system/bin/dex2oat 工具生成的，實(shí)際上是一個(gè)自定義的elf文件，里面包含的都是本地機(jī)器指令，通過AOT生成的文件，在系統(tǒng)中的表現(xiàn)形式有OAT、ART、ODEX，其中大部分apk在執(zhí)行AOT后生成的都是odex文件。但是由dex2oat工具生成的oat文件包含有兩個(gè)特殊的段oatdata和oatexec，前者包含有用來生成本地機(jī)器指令的dex文件內(nèi)容，后者包含有生成的本地機(jī)器指令，進(jìn)而就可以直接運(yùn)行。其是通過PMS –> installd –> dex2oat的流程生成的，可以在預(yù)編譯的時(shí)候，也可以在開機(jī)apk掃描的過程中或者apk安裝過程中生成。

3. JIT＆AOT

3.1 JIT

JIT(Just In Time Compiler， 即時(shí)編譯)，與Dalvik虛擬機(jī)相關(guān)。

JIT在2.2版本提出的，目的是為了提高android的運(yùn)行速度，一直存活到4.4版本，因?yàn)樵?.4之后的ROM中，就不存在Dalvik虛擬機(jī)了。我們使用Java開發(fā)android，在編譯打包APK文件時(shí)，會(huì)經(jīng)過以下流程：

  1. Java編譯器將應(yīng)用中所有Java文件編譯為class文件
  2. dx工具將應(yīng)用編譯輸出的類文件轉(zhuǎn)換為Dalvik字節(jié)碼，即dex文件

DVM負(fù)責(zé)解釋dex文件為機(jī)器碼，如果我們不做處理的話，每次執(zhí)行代碼，都需要Dalvik將java代碼由解釋器(Interpreter)將每個(gè)java指令轉(zhuǎn)譯為微處理器指令，并根據(jù)轉(zhuǎn)譯后的指令先后次序依序執(zhí)行，一條java指令可能對(duì)應(yīng)多條微處理器指令，這樣效率不高。為了解決這個(gè)問題，Google在2.2版本添加了JIT編譯器，當(dāng)App運(yùn)行時(shí)，每當(dāng)遇到一個(gè)新類，JIT編譯器就會(huì)對(duì)這個(gè)類進(jìn)行編譯，經(jīng)過編譯后的代碼，會(huì)被優(yōu)化成相當(dāng)精簡(jiǎn)的原生型指令碼（即native code），這樣在下次執(zhí)行到相同邏輯的時(shí)候，速度就會(huì)更快。但是使用JIT也不一定加快執(zhí)行速度，如果大部分代碼的執(zhí)行次數(shù)很少，那么編譯花費(fèi)的時(shí)間不一定少于執(zhí)行dex的時(shí)間。Google當(dāng)然也知道這一點(diǎn)，所以JIT不對(duì)所有dex代碼進(jìn)行編譯，而是只編譯執(zhí)行次數(shù)較多的dex為本地機(jī)器碼。

3.2 AOT

AOT(Ahead Of Time)，和ART虛擬機(jī)相關(guān)。

JIT是運(yùn)行時(shí)編譯，這樣可以對(duì)執(zhí)行次數(shù)頻繁的dex代碼進(jìn)行編譯和優(yōu)化，減少以后使用時(shí)的翻譯時(shí)間，雖然可以加快Dalvik運(yùn)行速度，但是還是有弊病，那就是將dex翻譯為本地機(jī)器碼也要占用時(shí)間，所以Google在4.4之后推出了ART，用來替換Dalvik。

在4.4版本上，兩種運(yùn)行時(shí)環(huán)境共存，可以相互切換，但是在5.0+，Dalvik虛擬機(jī)則被徹底的丟棄，全部采用ART。ART的策略與Dalvik不同，在ART 環(huán)境中，應(yīng)用在第一次安裝的時(shí)候，字節(jié)碼就會(huì)預(yù)先編譯成機(jī)器碼，使其成為真正的本地應(yīng)用。之后打開App的時(shí)候，不需要額外的翻譯工作，直接使用本地機(jī)器碼運(yùn)行，因此運(yùn)行速度提高。

總的來說：

  • JIT代表運(yùn)行時(shí)編譯策略，也可以理解成一種運(yùn)行時(shí)編譯器，是為了加快Dalvik虛擬機(jī)解釋dex速度提出的一種技術(shù)方案，來緩存頻繁使用的本地機(jī)器碼
  • AOT可以理解運(yùn)行前編譯策略，ART虛擬機(jī)的主要特征就是AOT

4. Android N上的改變

4.1 ART缺點(diǎn)

  • dex->oat生成時(shí)間太久,進(jìn)而apk安裝時(shí)間很久
  • dex2oat耗用系統(tǒng)資源太多，特別dex2oat占用cpu和memory
  • oat文件過大，rom小的設(shè)備data空間會(huì)吃緊
  • Powerconsumption 增加
  • ART不太穩(wěn)定，在M上crash問題太多，debug不太容易
  • oat文件是elf格式，所以加載oat文件時(shí)候相關(guān)依賴庫也很多，間接導(dǎo)致app進(jìn)程占用Memory的增加

9102年了，還不知道Android為什么卡？

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容