JVM與Dalvik

Android應用程序運行在Dalvik/ART虛擬機，并且每一個應用程序對應有一個單獨的Dalvik虛擬機實例。Dalvik虛擬機實則也算是一個Java虛擬機，只不過它執(zhí)行的不是class文件，而是dex文件。 Dalvik虛擬機與Java虛擬機共享有差不多的特性，差別在于兩者執(zhí)行的指令集是不一樣的，前者的指令集是基本寄存器的，而后者的指令集是基于堆棧的。 

 JMV基于棧，Dalvik基于寄存器

基于棧的虛擬機

對于基于棧的虛擬機來說，每一個運行時的線程，都有一個獨立的棧。棧中記錄了方法調用的歷史，每有一次方法調用，棧中便會多一個棧楨。最頂部的棧楨稱作當前棧楨，其代表著當前執(zhí)行的方法?；跅５奶摂M機通過操作數棧進行所有操作。 

字節(jié)碼指令

在Androidstudio中搜索ASMPlugin，可以直接用這個插件查看字節(jié)碼 

執(zhí)行過程

基于寄存器的虛擬機

寄存器

寄存器是CPU的組成部分。寄存器是有限存貯容量的高速存貯部件，它們可用來暫存指令、數據和位址。 

基于寄存器的虛擬機

基于寄存器的虛擬機中沒有操作數棧，但是有很多虛擬寄存器。其實和操作數棧相同，這些寄存器也存放在運行時棧中，本質上就是一個數組。與JVM相似，在Dalvik VM中每個線程都有自己的PC和調用棧，方法調用的活動記錄以幀為單位保存在調用棧上。 

 與JVM版相比，可以發(fā)現Dalvik版程序的指令數明顯減少了，數據移動次數也明顯減少了。

ART與Dalvik

Dalvik虛擬機執(zhí)行的是dex字節(jié)碼，解釋執(zhí)行。從Android 2.2版本開始，支持JIT及時編譯（Just In Time）在程序運行的過程中進行選擇熱點代碼（經常執(zhí)行的代碼）進行編譯或者優(yōu)化。 而ART（Android Runtime） 是在 Android 4.4 中引入的一個開發(fā)者選項，也是 Android 5.0 及更高版本的默認 Android 運行時。ART虛擬機執(zhí)行的是本地機器碼。Android的運行時從Dalvik虛擬機替換成ART虛擬機，并不要求開發(fā)者將自己的應用直接編譯成目標機器碼，APK仍然是一個包含dex字節(jié)碼的文件。那么，ART虛擬機執(zhí)行的本地機器碼是從哪里來？

dex2aot

Dalvik下應用在安裝的過程，會執(zhí)行一次優(yōu)化，將dex字節(jié)碼進行優(yōu)化生成odex文件。而Art下將應用的dex字節(jié)碼翻譯成本地機器碼的最恰當AOT時機也就發(fā)生在應用安裝的時候。ART 引入了預先編譯機制（Ahead Of Time），在安裝時，ART 使用設備自帶的 dex2oat 工具來編譯應用，dex中的字節(jié)碼將被編譯成本地機器碼。 

 odex的目的：預先提取，減少RAM的占用，因為沒有odex的話，系統(tǒng)要從apk包中提取dex再運行。

dexopt與dexaot

• dexopt：在Dalvik中虛擬機在加載一個dex文件時，對 dex 文件 進行 驗證 和 優(yōu)化的操作，其對 dex 文件的優(yōu)化結果變成了 odex(Optimized dex) 文件，這個文件和 dex 文件很像，只是使用了一些優(yōu)化操作碼。
• dex2oat：ART 預先編譯機制，在安裝時對 dex 文件執(zhí)行AOT 提前編譯操作，編譯為OAT（實際上是ELF文件）可執(zhí)行文件（機器碼）。

Android N的運作方式

ART 使用預先 (AOT) 編譯，并且從 Android N混合使用AOT編譯，解釋和JIT。 1、最初安裝應用時不進行任何 AOT 編譯（安裝又快了），運行過程中解釋執(zhí)行，對經常執(zhí)行的方法進行JIT，經過 JIT 編譯的方法將會記錄到Profile配置文件中。 2、當設備閑置和充電時，編譯守護進程會運行，根據Profile文件對常用代碼進行 AOT 編譯。待下次運行時直接使用。 

ClassLoader

介紹

任何一個 Java 程序都是由一個或多個 class 文件組成，在程序運行時，需要將 class 文件加載到 JVM 中才可以使用，負責加載這些 class 文件的就是 Java 的類加載機制。ClassLoader 的作用簡單來說就是加載 class 文件，提供給程序運行時使用。每個 Class 對象的內部都有一個 classLoader 字段來標識自己是由哪個ClassLoader 加載的。 

 ClassLoader是一個抽象類，而它的具體實現類主要有：

• BootClassLoader：用于加載Android Framework層class文件。
• PathClassLoader：用于Android應用程序類加載器?？梢约虞d指定的dex，以及jar、zip、apk中的classes.dex
• DexClassLoader：用于加載指定的dex，以及jar、zip、apk中的classes.dex

很多博客里說PathClassLoader只能加載已安裝的apk的dex，其實這說的應該是在dalvik虛擬機上。但現在一般不用關心dalvik了。

Log.e(TAG, "Activity.class 由：" + Activity.class.getClassLoader() +" 加載");
Log.e(TAG, "MainActivity.class 由：" + getClassLoader() +" 加載");
//輸出：
Activity.class 由：java.lang.BootClassLoader@d3052a9 加載
MainActivity.class 由：dalvik.system.PathClassLoader[DexPathList[[zip file
"/data/app/com.enjoy.enjoyfix-1/base.apk"],nativeLibraryDirectories=
[/data/app/com.enjoy.enjoyfix-1/lib/x86, /system/lib, /vendor/lib]]] 加載

ClassLoader加載流程與雙親委托機制

可以看到創(chuàng)建 ClassLoader 需要接收一個 ClassLoader parent 參數。這個 parent 的目的就在于實現類加載的雙親委托。即： 某個類加載器在加載類時，首先將加載任務委托給父類加載器，依次遞歸，如果父 類加載器可以完成類加載任務，就成功返回；只有父類加載器無法完成此加載任務或者沒有父類加載器時，才自己去加載。

1、避免重復加載，當父加載器已經加載了該類的時候，就沒有必要子ClassLoader再加載一次。 2、安全性考慮，防止核心API庫被隨意篡改。 

因此我們自己創(chuàng)建的ClassLoader: new PathClassLoader("/sdcard/xx.dex", getClassLoader()); 并不僅僅只能加載 xx.dex中的class。

值得注意的是： c = findBootstrapClassOrNull(name); 按照方法名理解，應該是當parent為null時候，也能夠加載 BootClassLoader 加載的類。 newPathClassLoader("/sdcard/xx.dex", null) ，能否加載Activity.class？ 但是實際上，Android當中的實現為：（Java不同）

類加載

熱修復

 PathClassLoader 中存在一個Element數組，Element類中存在一個dexFile成員表示dex文件，即：APK中有X個dex，則Element數組就有X個元素。

在 PathClassLoader 中的Element數組為：[patch.dex , classes.dex , classes2.dex]。如果存在Key.class位于patch.dex與classes2.dex中都存在一份，當進行類查找時，循環(huán)獲得 dexElements 中的DexFile，查找到了Key.class則立即返回，不會再管后續(xù)的element中的DexFile是否能加載到Key.class了。

因此實際上，一種熱修復實現可以將出現Bug的class單獨的制作一份fix.dex文件(補丁包)，然后在程序啟動時，從服務器下載fix.dex保存到某個路徑，再通過fix.dex的文件路徑，用其創(chuàng)建 Element 對象，然后將這個 Element 對象插入到我們程序的類加載器 PathClassLoader 的 pathList 中的 dexElements 數組頭部。這樣在加載出現Bug的class時會優(yōu)先加載fix.dex中的修復類，從而解決Bug。 

到此這篇關于Android虛擬機與類加載機制詳情的文章就介紹到這了,更多相關Android虛擬機內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論