如何進行Dalvik,ART與ODEX簡析

這期內容當中小編將會給大家帶來有關如何進行Dalvik,ART與ODEX簡析，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

一：Dalvik和ART的區別

Dalvik： Dalvik是Google公司自己設計用于Android平臺的Java虛擬機它可以支持已轉換為 .dex（即Dalvik Executable）格式的Java應用程序的運行，.dex格式是專為Dalvik設計的一種壓縮格式，適合內存和處理器速度有限的系統。執行的是字節碼，它是依靠Just-In-Time (JIT)機制去解釋字節碼
ART：即Android Runtime，google為了替代Dalvik專門為Android研發的。Android KK為開發者推出，L版本正式上線。比替代品更高效省電，執行的是本地機器碼（也就是linux的ELF文件格式），依靠Ahead-Of-Time (AOT)機制

二.在不同平臺DEX轉化為ODEX的過程

簡化流程如下：

打包安裝運行簡化流程.png

這里參考的是

Android ART運行時無縫替換Dalvik虛擬機的過程分析

http://blog.csdn.net/luoshengyang/article/details/18006645

android安裝過程源碼分析：

Android應用程序進程啟動過程的源代碼分析

http://blog.csdn.net/luoshengyang/article/details/6747696

簡單來說，就是Android系統通過PackageManagerService來安裝APK，在安裝的過程，PackageManagerService會通過另外一個類Installer的成員函數dexopt來對APK里面的dex字節碼進行優化：

public final class Installer {  
    ......  

    public int dexopt(……) {  
        StringBuilder builder = new StringBuilder("dexopt");  
        builder.append(' ');  
        builder.append(apkPath);  
        builder.append(' ');  
        builder.append(uid);  
        builder.append(isPublic ? " 1" : " 0");  
        return execute(builder.toString());  
    }  

    ......  
}

這個函數定義在文件frameworks/base/services/java/com/android/server/pm/Installer.java中。Installer通過socket向守護進程installd發送一個dexopt請求,這個請求是由installd里面的函數dexopt來處理的。詳細過程請移步Android ART運行時無縫替換Dalvik虛擬機的過程分析

int dexopt(const char ……

函數定義在frameworks/native/cmds/installd/commands.c中 函數dexopt首先是讀取系統屬性persist.sys.dalvik.vm.lib的值，接著在/data/dalvik-cache目錄中創建一個odex文件。這個odex文件就是作為dex文件優化后的輸出文件。再接下來，函數dexopt通過fork來創建一個子進程。如果系統屬性persist.sys.dalvik.vm.lib的值等于libdvm.so，那么該子進程就會調用函數run_dexopt來將dex文件優化成odex文件。另一方面，如果系統屬性persist.sys.dalvik.vm.lib的值等于libart.so，那么該子進程就會調用函數run_dex2oat來將dex文件翻譯成oat文件，實際上就是將dex字節碼翻譯成本地機器碼，并且保存在一個oat文件中。
函數run_dexopt通過調用/system/bin/dexopt來對dex字節碼進行優化，而函數run_dex2oat通過調用/system/bin/dex2oat來將dex字節碼翻譯成本地機器碼。注意，無論是對dex字節碼進行優化，還是將dex字節碼翻譯成本地機器碼，最終得到的結果都是保存在相同名稱的一個odex文件里面的，但是前者對應的是一個dey文件（表示這是一個優化過的dex），后者對應的是一個oat文件（實際上是一個自定義的elf文件，里面包含的都是本地機器指令）。通過這種方式，原來任何通過絕對路徑引用了該odex文件的代碼就都不需要修改了。

三.oat文件格式

借助羅大神的圖我們可以知道，OAT文件本質上是一個ELF文件，因此在最外層它具有一般ELF文件的結構，例如它有標準的ELF文件頭以及通過段（Section）來描述文件內容。

OAT文件包含有兩個特殊的段oatdata和oatexec，前者包含有用來生成本地機器指令的dex文件內容，后者包含有生成的本地機器指令，它們之間的關系通過儲存在oatdata段前面的oat頭部描述。

APK安裝過程中生成的OAT文件的輸入只有一個DEX文件，也就是來自于打包在要安裝的APK文件里面的classes.dex文件。實際上，一個OAT文件是可以由若干個DEX生成的。這意味著在生成的OAT文件的oatdata段中，包含有多個DEX文件。詳細分析請移步Android運行時ART加載OAT文件的過程分析

四.multidex加載odex，multidex和oat的關系

MultiDex在dalvik虛擬機上的簡要安裝過程：
將/data/app/apkName.apk路徑下解壓得到的classes2.dex, …, classesN.dex，依次寫入到/data/data/pkgName/code_cache/secondary-dexes/apkName.apk.classes2.zip等zip文件的classes.dex中，并返回這個zip列表。然后針對這個zip列表執行安裝過程，具體過程是，將這個要安裝的zip列表加入BaseDexClassLoader的pathList實例的dexElements數組中，其中會針對各dex文件進行dex2opt優化。一旦加入到了dexElements數組中，程序啟動的時候，ClassLoader會加載dexElements數組中的元素，從而實現multi dex的安裝。

上面提到OAT文件可以由若干個dex生成，也就是不需要multidex去進行安裝，但是multidex是application中
進行Install的，跟虛擬機關系不大。

@Override
    attachBaseContext(……) {
    super.attachBaseContext(base);
    MultiDex.install(this);
}

在install函數中在執行從提取dex文件列表前會做一些校驗操作，其中包含檢查APK是否已安裝，若APK已安裝，則不進行后續操作。檢查SDK版本號，版本號大于20不能保證MultiDex可正常Work

 Set var2 = installedApk;
 synchronized(installedApk) {                  
 String apkPath = e.sourceDir;                  
 if(installedApk.contains(apkPath)) {                        
       return;
    }

所以multidex在ART上不會影響程序的邏輯，它和ART沒有關系。

從安裝過程上來看
Java的代碼實際上需要兩次“轉換”才可以在android設備上運行
一.PC端：.class->.dex->.apk
二.phone:dex->odex

區別在于第二步。
ART : .dex->.odex(機器碼)（AOT　　Ahead-Of-Time）
Dalvik: .dex->.odex(字節碼)（JIT　Just-In-Time）
機器碼可直接執行，而字節碼每次啟動都需要執行將優化過的odex字節碼再轉換成機器碼

ART優缺

系統性能大幅提升
App啟動、運行更快
減少每次啟動的編譯增加電池續航
存儲占用更大
安裝時間更長

上述就是小編為大家分享的如何進行Dalvik,ART與ODEX簡析了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。