Dalvik虛擬機如同其他Java虛擬機一樣蜡吧，在運行程序時首先需要將對應的類加載到內存中峦失。而在Java標準的虛擬機中坯沪，類加載可以從class文件中讀取悴灵，也可以是其他形式的二進制流扛芽。因此，我們常常利用這一點积瞒，在程序運行時手動加載Class川尖，從而達到代碼動態(tài)加載執(zhí)行的目的。
只不過Android平臺上虛擬機運行的是Dex字節(jié)碼,一種對class文件優(yōu)化的產物,傳統(tǒng)Class文件是一個Java源碼文件會生成一個.class文件茫孔，而Android是把所有Class文件進行合并叮喳，優(yōu)化庐船，然后生成一個最終的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.傳入一個父類構造器

實際構造器

無參構造器

laodClass.png

• BootClassLoader

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

• URLClassLoader

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

• BaseDexClassLoader

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

BaseDexClassLoader.png

• dexPath,指目標類所在的APK或jar文件的路徑,類裝載器將從該路徑中尋找指定的目標類,該類必須是APK或jar的全路徑.如果要包含多個路徑,路徑之間必須使用特定的分割符分隔,特定的分割符可以使用System.getProperty(“path.separtor”)獲得硬霍。上面"支持加載APK、DEX和JAR辐真，也可以從SD卡進行加載"指的就是這個路徑须尚，最終做的是將dexPath路徑上的文件ODEX優(yōu)化到內部位置optimizedDirectory，然后侍咱，再進行加載的耐床。
• File optimizedDirectory,由于dex文件被包含在APK或者Jar文件中,因此在裝載目標類之前需要先從APK或Jar文件中解壓出dex文件,該參數(shù)就是制定解壓出的dex 文件存放的路徑。這也是對apk中dex根據(jù)平臺進行ODEX優(yōu)化的過程楔脯。其實APK是一個程序壓縮包撩轰，里面包含dex文件，ODEX優(yōu)化就是把包里面的執(zhí)行程序提取出來，就變成ODEX文件堪嫂，因為你提取出來了偎箫，系統(tǒng)第一次啟動的時候就不用去解壓程序壓縮包的程序，少了一個解壓的過程皆串。這樣的話系統(tǒng)啟動就加快了淹办。為什么說是第一次呢？是因為DEX版本的也只有第一次會解壓執(zhí)行程序到 /data/dalvik-cache（針對PathClassLoader）或者optimizedDirectory(針對DexClassLoader）目錄恶复，之后也是直接讀取目錄下的的dex文件怜森，所以第二次啟動就和正常的差不多了。當然這只是簡單的理解谤牡，實際生成的ODEX還有一定的優(yōu)化作用副硅。ClassLoader只能加載內部存儲路徑中的dex文件，所以這個路徑必須為內部路徑翅萤。
• libPath,指目標類中所使用的C/C++庫存放的路徑
• classload,是指該裝載器的父裝載器,一般為當前執(zhí)行類的裝載器恐疲，例如在Android中以context.getClassLoader()作為父裝載器。

• DexClassLoader

在看下DexClassLoader和PathClassLoader的構造器：

DexClassLoader

• PathClassLoader

PathClassLoader

optimized_dexFilepath

advice

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的數(shù)組dexElements，由上面分析知道撮竿，dexPath傳入的原始dex(.apk,.zip,.jar等)文件在optimizedDirectory文件夾中生成相應的優(yōu)化后的odex文件吮便，dexElements數(shù)組就是這些odex文件的集合，如果不分包一般這個數(shù)組只有一個Element元素幢踏，也就只有一個DexFile文件髓需，而對于類加載呢，就是遍歷這個集合房蝉，通過DexFile去尋找授账。最終調用native方法的defineClass。

ART虛擬機的兼容性問題

Android Runtime（縮寫為ART）惨驶，在Android 5.0及后續(xù)Android版本中作為正式的運行時庫取代了以往的Dalvik虛擬機白热。ART能夠把應用程序的字節(jié)碼轉換為機器碼，是Android所使用的一種新的虛擬機粗卜。它與Dalvik的主要不同在于：Dalvik采用的是JIT技術屋确，字節(jié)碼都需要通過即時編譯器（just in time ，JIT）轉換為機器碼续扔，這會拖慢應用的運行效率攻臀，而ART采用Ahead-of-time（AOT）技術，應用在第一次安裝的時候纱昧，字節(jié)碼就會預先編譯成機器碼刨啸，這個過程叫做預編譯。ART同時也改善了性能识脆、垃圾回收（Garbage Collection）设联、應用程序除錯以及性能分析。但是請注意灼捂，運行時內存占用空間較少同樣意味著編譯二進制需要更高的存儲离例。
ART模式相比原來的Dalvik，會在安裝APK的時候悉稠，使用Android系統(tǒng)自帶的dex2oat工具把APK里面的.dex文件轉化成OAT文件宫蛆，OAT文件是一種Android私有ELF文件格式，它不僅包含有從DEX文件翻譯而來的本地機器指令的猛，還包含有原來的DEX文件內容耀盗。這使得我們無需重新編譯原有的APK就可以讓它正常地在ART里面運行，也就是我們不需要改變原來的APK編程接口卦尊。ART模式的系統(tǒng)里叛拷，同樣存在DexClassLoader類，包名路徑也沒變猫牡，只不過它的具體實現(xiàn)與原來的有所不同胡诗，但是接口是一致的邓线。實際上，ART運行時就是和Dalvik虛擬機一樣煌恢，實現(xiàn)了一套完全兼容Java虛擬機的接口骇陈。

參考：
【Android動態(tài)加載入門 簡單加載模式-作者：kaedea】