Android系統下的動態Dex加載

1 問題
在Android系統中，一個App的所有代碼都在一個Dex文件里面。Dex是一個類似Jar的存
儲了多有Java編譯字節碼的歸檔文件。因為Android系統使用Dalvik虛擬機，所以需要把
使用Java Compiler編譯之后的class文件轉換成Dalvik能夠執行的class文件。這里需要強
調的是，Dex和Jar一樣是一個歸檔文件，里面仍然是Java代碼對應的字節碼文件。
當Android系統啟動一個應用的時候，有一步是對Dex進行優化，這個過程有一個專門的
工具來處理，叫DexOpt。DexOpt的執行過程是在第一次加載Dex文件的時候執行的。這
個過程會生成一個ODEX文件，即Optimised Dex。執行ODex的效率會比直接執行Dex文
件的效率要高很多。但是在早期的Android系統中，DexOpt有一個問題，也就是這篇文
章想要說明並解決的問題。DexOpt會把每一個類的方法id檢索起來，存在一個鏈表結構
里面。但是這個鏈表的長度是用一個short類型來保存的，導致了方法id的數目不能夠超過
65536個。當一個項目足夠大的時候，顯然這個方法數的上限是不夠的。盡管在新版本的
Android系統中，DexOpt修復了這個問題，但是我們仍然需要對老系統做兼容。
2 思路
一種有效的解決思路是把Dex文件分割成多個較小的Dex。這就如同很多項目會把自己分
割成多個Jar文件一樣，不同的功能在不同的Jar文件里面，通過一些配置和額外的操作，
可以讓虛擬機有選擇性的加載Jar文件。但是在Android系統中，一個應用是只允許有一
個Dex文件的。也就是說在編譯期的時候，所有的Jar文件最終會被合並成一個Dex文件。
我們沒有辦法在Apk文件里面打包兩個Dex，讓DexOpt分別對兩個Dex文件做處理，而
Android系統也不會同時為一個Apk加載兩個Dex。
1
2.1 動態加載
如果我們把Dex分成多個文件，然后在程序運行的時候，再把多的那幾個動態的加載進來
是否可行呢？也就是說我們能否在運行時階段把代碼加入虛擬機中。對於虛擬機來說，其
實所有的代碼都是在運行時被加載進來的。而不同於C語言還存在着靜態鏈接。虛擬機在
所有Java代碼執行之前被啟動，然后開始把字節碼加載到環境中執行，我們可以理解成所
有的代碼都是動態加載到虛擬機里的。
而說到加載，不得不說的是ClassLoader。它的工作就是加載.class文件。在Android的
Dalvik環境中，對應的是DexClassLoader，它們的功能是完全一樣的。ClassLoader的
一大特點就是它是一個樹狀結構。每個ClassLoader都有一個父親ClassLoader。也就是
說，ClassLoader不是把所有的Class放到一個巨大的數組或別的什么數據結構中來處理。
ClassLoader在加載一個Jar中的類的時候，需要制定另一個ClassLoader作為父親節點，
當我們需要通過ClassLoader得到一個類類型的時候，ClassLoader會把請求優先交給父
親ClassLoader來處理，而父親ClassLoader又會交給它的父親，一直到根ClassLoader。
如果根ClassLoader有這個類，而返回這個類的類類型，否則把這個請求交給這個請求的
來源子ClassLoader。這是一種向上傳遞，向下分發的機制。這種情況下，對於調用着來
說，子ClassLoader永遠都是包含最多Class的ClassLoader。有一點我們需要注意，父親
ClassLoader只會向請求來源分發自己的處理結果。所以如果來源是自己，那么如果沒有
請求類它就會返回空，而不是遍歷所有子ClassLoader去請求是否有被請求的類。
在Android系統中，對於一個應用來說，其實有兩個ClassLoader，一個是SystemClassLoader，這個ClassLoader里面除了Java標准的類庫之外，還有一個android.jar，所有
Android Framework層的類都在這里。而另外一個重要的ClassLoader就是基於Android
Context的ClassLoader。所有屬於當前應用的類都是用這個ClassLoader來加載的，我們
可以在Android源碼中看到，所有的Activity，Service，View都是使用這個ClassLoader
來反射並創建的。我們暫時把它叫做ContextClassLoader。
3 加載外部Dex
3.1 構建一個Dex文件
這一步並不復雜，首先我們把所需要的.class文件或者是Jar文件和一些源碼一起編譯生
成一個Jar文件。然后使用Android SDK提供的dx工具把Jar文件轉成Dex文件。我們可以
提前對它進行ODex操作，讓它在被DexClassLoader加載的時候，跳過DexOpt的部分工
作，從而加快加載的過程。
2
3.2 DexClassLoader
現在的工作就是在運行時加載這個Dex文件了。我們可以在Application啟動的onCreate
方法里面加載Dex，但是如果你的Dex太大，那么它會讓你的App啟動變慢。我們也可以
使用線程去加載，但我們必須保證加載完成之后再進行某個外部類的請求。當然也可以真
正等到需要某個外部類的時候再進行Dex加載。這根本上取決於Dex文件本身的大小，太
大了可以預加載，而比較小可以等到實際需要的時候再加載。我們暫且把這個加載了外部
Dex的ClassLoader成為ExternalClassLoader
上面我們提到了樹形結構和系統中的多個ClassLoader，當我們加載外部Dex的時候，我
們是否需要指定一個父ClassLoader呢？我們當然需要一個父ClassLoader，否則我們ExternalClassLoader連一些基本的Java類都沒有，它根本不可能成功的加載一個Dex。進一
步的，我們要選擇哪一個ClassLoader來作為我們的父親呢？是SystemClassLoader還是
ExternalClassLoader？這是根據情況來定的，如果外部的Dex文件里沒有任何和Android
相關的代碼，那么SystemClassLoader是我們的首選，否則我們就應該用ContextClassLoader。如果是后者的情況，我們的樹可以被看成一個鏈表。
3.3 外部的View, Acitivity等
我們知道，我們編寫的四大組建都不是由我們自己來創建的，是由系統來給我們構造並
管理其生命周期的。那么這個過程是什么樣的呢？拿Activity來舉例，我們需要通過調用
當前Activity/Context的startActivity，傳入一個Intent來調用啟動一個新的Activity。系
統有一個ActivityManager來處理這里的邏輯。這里的邏輯相當的復雜，但簡單來說，
ActivityManager會收到並處理這個Intent，從而決定是是啟動一個新的，還是把舊的放
到前台。它會先查找這個Activity在哪個應用里面，這是通過掃描每個應用的AndroidManifest來確定。這些信息是在PackageManager里面被檢索的。總之如果這個Activity
不再任何的manifest里面，它就不可能被啟動。所以僅有一個Activity類是不夠的，我們
需要在manifest里面聲明它。
上面是Activity的情況，Service之類的也是同理。那么View怎么辦？盡管我們可以直接創
建View，但是大部分的View都不是我們創建的，而是通過XML布局文件Inflate出來的。
也就是說，我們在XML定義了一些外部Dex里面的View，那么顯然這個XML是不能被成
功的Inflate的。因為除非系統會使用我們的ExternalClassLoader，否則它肯定是找不到
我們的類的：ContextClassLoader里面並沒有外部Dex中的類。
也就是說問題的根本在於，對於那些Android系統為我們創建的對象，它是不能包含在外
部Dex里面的。而Android系統中大部分的組建類的生命周期都交給了系統來管理。我們
3
不可能自己來創建這些類對象。那么另一種思路：我們是不是可以通過使用我們的ExternalClassLoader來代替ContextClassLoader呢？盡管系統的ContextClassLoader是私有
的，但是我們可以通過反射強制的把它替換成我們的ExternalClassLoader。而對於那些
外部的組建（Activity等），盡管我們沒有它們的類，但是並不影響我們在AndroidManifest里面聲明這個Activity。因為Android系統只是把它作為一個檢索，並不會真正檢查它
里面的組建是不是真的在虛擬機環境中已經被加載了，只有真正使用Intent啟動某個組建
的時候才會去檢查。而只要我們保證這個時候我們已經加載了外部的ClassLoader，那么
這個組建就可以被正常的啟動。
還有一點，除了我們要為外部可能有的組建在AndroidManifest里面做聲明一外，那些外
部組建可能用到的權限我們也需要一一聲明，例如如果外部Activity使用了相機功能，那
么如果我們的Manifest里面沒有聲明使用相機功能的權限的話，即便這個Activity能成功
為加載出來，仍然是不能使用的。
4 核心代碼段
加載外部Dex
mClassLoader = new DexClassLoader ( f . getAbsolutePath ( ) ,
mContext . getCacheDir ( ) . getAbsolutePath ( ) ,
null , mContext . getClassLoader ( ) ) ;
讓系統使用ExternalClassLoader
t r y {
F ie ld mMainThread = ge t F ie ld ( A c t i v i t y . class , ”mMainThread”) ;
Object mainThread = mMainThread . get ( a c t i v i t y ) ;
Class t hreadClass = mainThread . get Class ( ) ;
F ie ld mPackages = ge t F ie ld ( threadClass , ”mPackages”) ;
WeakReference<?> r e f ;
Map< St ring , ?> map =(Map< St ring , ? >) mPackages . get (mainThread ) ;
r e f = (WeakReference<? >) map . get (mContext . getPackageName ( ) ) ;
Object apk = r e f . get ( ) ;
Class apkClass = apk . get Class ( ) ;
F ie ld mClassLoader = ge t F ie ld ( apkClass , ”mClassLoader”) ;
mClassLoader . set (apk , classLoader ) ;
} catch ( I llegalArgument Except ion e) {
i f (DEBUG) {
e . print St ackTrace ( ) ;
}
} catch ( I llega lAc c essEx c ept ion e) {
i f (DEBUG) {
4
e . print St ackTrace ( ) ;
}
}
5