Dex動態加載是為了解決什么問題？

在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修復了這個問題，但是我們仍然需要對老系統做兼容。

Dex動態加載思路

一種有效的解決思路是把Dex文件分割成多個較小的Dex。這就如同很多項目會把自己分割成多個Jar文件一樣，不同的功能在不同的Jar文件里面，通過一些配置和額外的操作，可以讓虛擬機有選擇性的加載Jar文件。

但是在Android系統中，一個應用是只允許有一個Dex文件的。也就是說在編譯期的時候，所有的Jar文件最終會被合并成一個Dex文件。我們沒有辦法在Apk文件里面打包兩個Dex，讓DexOpt分別對兩個Dex文件做處理，而Android系統也不會同時為一個Apk加載兩個Dex。

如果我們把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，一個是SystemClass-Loader，這個ClassLoader里面除了Java標準的類庫之外，還有一個android.jar，所有Android Framework層的類都在這里。

而另外一個重要的ClassLoader就是基于Android Context的ClassLoader。所有屬于當前應用的類都是用這個ClassLoader來加載的，我們可以在Android源碼中看到，所有的Activity，Service，View都是使用這個ClassLoader來反射并創建的。我們暫時把它叫做ContextClassLoader。

加載外部Dex

首先構建一個Dex文件，這一步并不復雜，首先我們把所需要的.class文件或者是Jar文件和一些源碼一起編譯生成一個Jar文件。然后使用Android SDK提供的dx工具把Jar文件轉成Dex文件。

我們可以提前對它進行ODex操作，讓它在被DexClassLoader加載的時候，跳過DexOpt的部分工作，從而加快加載的過程。

現在的工作就是在運行時加載這個Dex文件了。我們可以在Application啟動的onCreate方法里面加載Dex，但是如果你的Dex太大，那么它會讓你的App啟動變慢。

我們也可以使用線程去加載，但我們必須保證加載完成之后再進行某個外部類的請求。當然也可以真正等到需要某個外部類的時候再進行Dex加載。這根本上取決于Dex文件本身的大小，太大了可以預加載，而比較小可以等到實際需要的時候再加載。

我們暫且把這個加載了外部Dex的ClassLoader成為ExternalClassLoader.

上面我們提到了樹形結構和系統中的多個ClassLoader，當我們加載外部Dex的時候，我們是否需要指定一個父ClassLoader呢？我們當然需要一個父ClassLoader，否則ExternalClassLoader連一些基本的Java類都沒有，它根本不可能成功的加載一個Dex。

進一步的，我們要選擇哪一個ClassLoader來作為我們的父親呢？是SystemClassLoader還是ContextClass-Loader？

這是根據情況來定的，如果外部的Dex文件里沒有任何和Android相關的代碼，那么SystemClassLoader是我們的首選，否則我們就應該用ContextClass-Loader。如果是后者的情況，我們的樹可以被看成一個鏈表。

外部的View, Acitivity等的處理

我們知道，我們編寫的四大組件都不是由我們自己來創建的，是由系統來給我們構造并管理其生命周期的。那么這個過程是什么樣的呢？

拿Activity來舉例，我們需要通過調用當前Activity/Context的startActivity，傳入一個Intent來調用啟動一個新的Activity。系統有一個ActivityManager來處理這里的邏輯。這里的邏輯相當的復雜，但簡單來說，ActivityManager會收到并處理這個Intent，從而決定是是啟動一個新的，還是把舊的放到前臺。它會先查找這個Activity在哪個應用里面，這是通過掃描每個應用的Android-Manifest來確定。這些信息是在PackageManager里面被檢索的。總之如果這個Activity不在任何的manifest里面，它就不可能被啟動。

所以僅有一個Activity類是不夠的，我們需要在manifest里面聲明它。上面是Activity的情況，Service之類的也是同理。那么View怎么辦？

盡管我們可以直接創建View，但是大部分的View都不是我們創建的，而是通過XML布局文件Inflate出來的。也就是說，我們在XML定義了一些外部Dex里面的View，那么顯然這個XML是不能被成功的Inflate的。因為除非系統會使用我們的ExternalClassLoader，否則它肯定是找不到我們的類的：ContextClassLoader里面并沒有外部Dex中的類。

也就是說問題的根本在于，對于那些Android系統為我們創建的對象，它是不能包含在外部Dex里面的。而Android系統中大部分的組件類的生命周期都交給了系統來管理。我們不可能自己來創建這些類對象。

那么另一種思路：我們是不是可以通過使用我們的ExternalClassLoader來代替ContextClassLoader呢？盡管系統的ContextClassLoader是私有的，但是我們可以通過反射強制的把它替換成我們的ExternalClassLoader。

而對于那些外部的組件（Activity等），盡管我們沒有它們的類，但是并不影響我們在AndroidManifest里面聲明這個Activity。因為Android系統只是把它作為一個檢索，并不會真正檢查它里面的組件是不是真的在虛擬機環境中已經被加載了，只有真正使用Intent啟動某個組件的時候才會去檢查。而只要我們保證這個時候我們已經加載了外部的ClassLoader，那么這個組件就可以被正常的啟動。

還有一點，除了我們要為外部可能有的組件在AndroidManifest里面做聲明一外，那些外部組件可能用到的權限我們也需要一一聲明，例如如果外部Activity使用了相機功能，那么如果我們的Manifest里面沒有聲明使用相機功能的權限的話，即便這個Activity能成功為加載出來，仍然是不能使用的。

總結

以上是生活随笔為你收集整理的Android安全与逆向之Dex动态加载的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。