Android動態加載之ClassLoader詳解

Dalvik虛擬機如同其他Java虛擬機一樣，在運行程序時首先需要將對應的類加載到內存中。而在Java標準的虛擬機中，類加載可以從class文件中讀取，也可以是其他形式的二進制流。因此，我們常常利用這一點，在程序運行時手動加載Class，從而達到代碼動態加載執行的目的。
只不過Android平臺上虛擬機運行的是Dex字節碼,一種對class文件優化的產物,傳統Class文件是一個Java源碼文件會生成一個.class文件，而Android是把所有Class文件進行合併，優化，然後生成一個最終的class.dex,目的是把不同class文件重複的東西只需保留一份,如果我們的Android應用不進行分dex處理,最後一個應用的apk只會有一個dex文件。

Android平臺的ClassLoader

Android中的ClassLoader

Android中類加載器有BootClassLoader,URLClassLoader,
PathClassLoader,DexClassLoader,BaseDexClassLoader,等都最終繼承自java.lang.ClassLoader。

• ClassLoader

java.lang.ClassLoader是所有ClassLoader的最終父類。構造方法主要以下兩種
1.傳入一個父類構造器

實際構造器

2.無參默認構造法

 

 

無參構造器

可以看出ClassLoader主要就是傳入一個父構造器，而且一般父構造器不能爲空，不像java虛擬機裏父構造器爲空時默認的父構造器爲Bootstrap ClassLoader。Android中默認無父構造器傳入的情況下，默認父構造器爲一個PathClassLoader且此PathClassLoader父構造器爲BootClassLoader。
ClassLoader中重要的方法是loadClass(String name)，其他的子類都繼承了此方法且沒有進行復寫。

laodClass.png

可以看出在加載類時首先判斷這個類是否之前被加載過，如果有則直接返回，如果沒有則首先嚐試讓parent ClassLoader進行加載,加載不成功纔在自己的findClass中進行加載。這和java虛擬機中常見的雙親委派模型一致的，這種模型並不是一個強制性的約束模型，比如你可以繼承ClassLoader複寫loadCalss方法來破壞這種模型，只不過雙親委派模是一種被推薦的實現類加載器的方式，而且jdk1.2以後已經不提倡用戶在覆蓋loadClass方法，而應該把自己的類加載邏輯寫到findClass中。

 

• BootClassLoader

和java虛擬機中不同的是BootClassLoader是ClassLoader內部類,由java代碼實現而不是c++實現,是Android平臺上所有ClassLoader的最終parent,這個內部類是包內可見,所以我們沒法使用。

• URLClassLoader

只能用於加載jar文件，但是由於 dalvik 不能直接識別jar，所以在 Android 中無法使用這個加載器。

• BaseDexClassLoader

PathClassLoader和DexClassLoader都繼承自BaseDexClassLoader,其中的主要邏輯都是在BaseDexClassLoader完成的。這些源碼在java/dalvik/system中。
先看下BaseDexClassLoader的構造方式：

BaseDexClassLoader.png

BaseDexClassLoader的構造函數包含四個參數，分別爲：

 

• dexPath,指目標類所在的APK或jar文件的路徑,類裝載器將從該路徑中尋找指定的目標類,該類必須是APK或jar的全路徑.如果要包含多個路徑,路徑之間必須使用特定的分割符分隔,特定的分割符可以使用System.getProperty(“path.separtor”)獲得。上面"支持加載APK、DEX和JAR，也可以從SD卡進行加載"指的就是這個路徑，最終做的是將dexPath路徑上的文件ODEX優化到內部位置optimizedDirectory，然後，再進行加載的。
• File optimizedDirectory,由於dex文件被包含在APK或者Jar文件中,因此在裝載目標類之前需要先從APK或Jar文件中解壓出dex文件,該參數就是制定解壓出的dex 文件存放的路徑。這也是對apk中dex根據平臺進行ODEX優化的過程。其實APK是一個程序壓縮包，裏面包含dex文件，ODEX優化就是把包裏面的執行程序提取出來，就變成ODEX文件，因爲你提取出來了，系統第一次啓動的時候就不用去解壓程序壓縮包的程序，少了一個解壓的過程。這樣的話系統啓動就加快了。爲什麼說是第一次呢？是因爲DEX版本的也只有第一次會解壓執行程序到 /data/dalvik-cache（針對PathClassLoader）或者optimizedDirectory(針對DexClassLoader）目錄，之後也是直接讀取目錄下的的dex文件，所以第二次啓動就和正常的差不多了。當然這只是簡單的理解，實際生成的ODEX還有一定的優化作用。ClassLoader只能加載內部存儲路徑中的dex文件，所以這個路徑必須爲內部路徑。
• libPath,指目標類中所使用的C/C++庫存放的路徑
• classload,是指該裝載器的父裝載器,一般爲當前執行類的裝載器，例如在Android中以context.getClassLoader()作爲父裝載器。

• DexClassLoader

在看下DexClassLoader和PathClassLoader的構造器：

DexClassLoader

DexClassLoader支持加載APK、DEX和JAR，也可以從SD卡進行加載。
上面說dalvik不能直接識別jar,DexClassLoader卻可以加載jar文件,這難道不矛盾嗎?其實在BaseDexClassLoader裏對".jar",".zip",".apk",".dex"後綴的文件最後都會生成一個對應的dex文件,所以最終處理的還是dex文件,而URLClassLoader並沒有做類似的處理。
一般我們都是用這個DexClassLoader來作爲動態加載的加載器。

 

• PathClassLoader

 

PathClassLoader

optimized_dexFilepath

很簡單明瞭，可以看出PathClassLoader沒有將optimizedDirectory置爲Null,也就是沒設置優化後的存放路徑。其實optimizedDirectory爲null時的默認路徑就是/data/dalvik-cache 目錄。
PathClassLoader是用來加載Android系統類和應用的類，並且不建議開發者使用。

advice

很多博客裏說PathClassLoader只能加載已安裝的apk的dex，其實這說的應該是在dalvik虛擬機上，在art虛擬機上PathClassLoader可以加載未安裝的apk的dex（在art平臺上已驗證），然而在/data/dalvik-cache 確未找到相應的dex文件，懷疑是art虛擬機判斷apk未安裝，所以只是將apk優化後的odex放在內存中，之後進行釋放，這只是個猜想，希望有知道的可以告知一下。因爲dalvik上無法使用，所以我們也沒法使用。

 

ClassLoader加載class的過程

#BaseDexClassLoader
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException { 
    Class clazz = pathList.findClass(name);
    if (clazz == null) { 
        throw new ClassNotFoundException(name); 
    } 
    return clazz;
}
#DexPathList
public Class findClass(String name) { 
    for (Element element : dexElements) { 
        DexFile dex = element.dexFile;
        if (dex != null) { 
            Class clazz = dex.loadClassBinaryName(name, definingContext); 
          if (clazz != null) { 
              return clazz; 
          } 
        } 
    } 
    return null;
}
#DexFile
public Class loadClassBinaryName(String name, ClassLoader loader) { 
    return defineClass(name, loader, mCookie);
}
private native static Class defineClass(String name, ClassLoader loader, int cookie);

可以看出，BaseDexClassLoader中有個pathList對象，pathList中包含一個DexFile的數組dexElements，由上面分析知道，dexPath傳入的原始dex(.apk,.zip,.jar等)文件在optimizedDirectory文件夾中生成相應的優化後的odex文件，dexElements數組就是這些odex文件的集合，如果不分包一般這個數組只有一個Element元素，也就只有一個DexFile文件，而對於類加載呢，就是遍歷這個集合，通過DexFile去尋找。最終調用native方法的defineClass。

ART虛擬機的兼容性問題

Android Runtime（縮寫爲ART），在Android 5.0及後續Android版本中作爲正式的運行時庫取代了以往的Dalvik虛擬機。ART能夠把應用程序的字節碼轉換爲機器碼，是Android所使用的一種新的虛擬機。它與Dalvik的主要不同在於：Dalvik採用的是JIT技術，字節碼都需要通過即時編譯器（just in time ，JIT）轉換爲機器碼，這會拖慢應用的運行效率，而ART採用Ahead-of-time（AOT）技術，應用在第一次安裝的時候，字節碼就會預先編譯成機器碼，這個過程叫做預編譯。ART同時也改善了性能、垃圾回收（Garbage Collection）、應用程序除錯以及性能分析。但是請注意，運行時內存佔用空間較少同樣意味着編譯二進制需要更高的存儲。
ART模式相比原來的Dalvik，會在安裝APK的時候，使用Android系統自帶的dex2oat工具把APK裏面的.dex文件轉化成OAT文件，OAT文件是一種Android私有ELF文件格式，它不僅包含有從DEX文件翻譯而來的本地機器指令，還包含有原來的DEX文件內容。這使得我們無需重新編譯原有的APK就可以讓它正常地在ART裏面運行，也就是我們不需要改變原來的APK編程接口。ART模式的系統裏，同樣存在DexClassLoader類，包名路徑也沒變，只不過它的具體實現與原來的有所不同，但是接口是一致的。實際上，ART運行時就是和Dalvik虛擬機一樣，實現了一套完全兼容Java虛擬機的接口。

作者：SilenceDut
鏈接：https://www.jianshu.com/p/a620e368389a
來源：簡書