Android動態載入基礎 ClassLoader工作機制
基本資訊
類載入器ClassLoader
早期使用過Eclipse等Java編寫的軟體的同學可能比較熟悉，Eclipse可以載入許多第三方的外掛（或者叫擴充套件），這就是動態載入。這些外掛大多是一些Jar包，而使用外掛其實就是動態載入Jar包裡的Class進行工作。這其實非常好理解，Java程式碼都是寫在Class裡面的，程式執行在虛擬機器上時，虛擬機器需要把需要的Class載入進來才能建立例項物件並工作，而完成這一個載入工作的角色就是ClassLoader。
對於Java程式來說，編寫程式就是編寫類，執行程式也就是執行類（編譯得到的
class檔案），其中起到關鍵作用的就是類載入器ClassLoader。
Android的Dalvik/ART虛擬機器如同標準JAVA的JVM虛擬機器一樣，在執行程式時首先需要將對應的類載入到記憶體中。因此，我們可以利用這一點，在程式執行時手動載入Class，從而達到程式碼動態載入可執行檔案的目的。Android的Dalvik/ART虛擬機器雖然與標準Java的JVM虛擬機器不一樣，ClassLoader具體的載入細節不一樣，但是工作機制是類似的，也就是說在Android中同樣可以採用類似的動態載入外掛的功能，只是在Android應用中動態載入一個外掛的工作要比Eclipse載入一個外掛複雜許多（這點後面在解釋說明）。
有幾個ClassLoader例項？
動態載入的基礎是ClassLoader
其實，在Android系統啟動的時候會建立一個Boot型別的ClassLoader例項，用於載入一些系統Framework層級需要的類，我們的Android應用裡也需要用到一些系統的類，所以APP啟動的時候也會把這個Boot型別的ClassLoader傳進來。
此外，APP也有自己的類，這些類儲存在APK的dex檔案裡面，所以APP啟動的時候，也會建立一個自己的ClassLoader例項，用於載入自己dex檔案中的類。下面我們在專案裡驗證看看
@Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); ClassLoader classLoader = getClassLoader(); if (classLoader != null){ Log.i(TAG, "[onCreate] classLoader " + i + " : " + classLoader.toString()); while (classLoader.getParent()!=null){ classLoader = classLoader.getParent(); Log.i(TAG,"[onCreate] classLoader " + i + " : " + classLoader.toString()); } } }
輸出結果為
[onCreate] classLoader 1 : dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/me.kaede.anroidclassloadersample-1/base.apk"],nativeLibraryDirectories=[/vendor/lib, /system/lib]]]
[onCreate] classLoader 2 : [email protected]可以看見有2個Classloader例項，一個是BootClassLoader（系統啟動的時候建立的），另一個是PathClassLoader（應用啟動時建立的，用於載入“/data/app/me.kaede.anroidclassloadersample-1/base.apk”裡面的類）。由此也可以看出，一個執行的Android應用至少有2個ClassLoader。
建立自己ClassLoader例項
動態載入外部的dex檔案的時候，我們也可以使用自己建立的ClassLoader例項來載入dex裡面的Class，不過ClassLoader的建立方式有點特殊，我們先看看它的構造方法
/*
* constructor for the BootClassLoader which needs parent to be null.
*/
ClassLoader(ClassLoader parentLoader, boolean nullAllowed) {
if (parentLoader == null && !nullAllowed) {
throw new NullPointerException("parentLoader == null && !nullAllowed");
}
parent = parentLoader;
}建立一個ClassLoader例項的時候，需要使用一個現有的ClassLoader例項作為新建立的例項的Parent。這樣一來，一個Android應用，甚至整個Android系統裡所有的ClassLoader例項都會被一棵樹關聯起來，這也是ClassLoader的 雙親代理模型（Parent-Delegation Model）的特點。
ClassLoader雙親代理模型載入類的特點和作用
JVM中ClassLoader通過defineClass方法載入jar裡面的Class，而Android中這個方法被棄用了。
@Deprecated
protected final Class<?> defineClass(byte[] classRep, int offset, int length)
throws ClassFormatError {
throw new UnsupportedOperationException("can't load this type of class file");
}取而代之的是loadClass方法
public Class<?> loadClass(String className) throws ClassNotFoundException {
return loadClass(className, false);
}
protected Class<?> loadClass(String className, boolean resolve) throws ClassNotFoundException {
Class<?> clazz = findLoadedClass(className);
if (clazz == null) {
ClassNotFoundException suppressed = null;
try {
clazz = parent.loadClass(className, false);
} catch (ClassNotFoundException e) {
suppressed = e;
}
if (clazz == null) {
try {
clazz = findClass(className);
} catch (ClassNotFoundException e) {
e.addSuppressed(suppressed);
throw e;
}
}
}
return clazz;
}特點
從原始碼中我們也可以看出，loadClass方法在載入一個類的例項的時候，
-
會先查詢當前ClassLoader例項是否載入過此類，有就返回；
-
如果沒有。查詢Parent是否已經載入過此類，如果已經載入過，就直接返回Parent載入的類；
-
如果繼承路線上的ClassLoader都沒有載入，才由Child執行類的載入工作；
這樣做有個明顯的特點，如果一個類被位於樹根的ClassLoader載入過，那麼在以後整個系統的生命週期內，這個類永遠不會被重新載入。
作用
首先是共享功能，一些Framework層級的類一旦被頂層的ClassLoader載入過就快取在記憶體裡面，以後任何地方用到都不需要重新載入。
除此之外還有隔離功能，不同繼承路線上的ClassLoader載入的類肯定不是同一個類，這樣的限制避免了使用者自己的程式碼冒充核心類庫的類訪問核心類庫包可見成員的情況。這也好理解，一些系統層級的類會在系統初始化的時候被載入，比如java.lang.String，如果在一個應用裡面能夠簡單地用自定義的String類把這個系統的String類給替換掉，那將會有嚴重的安全問題。
使用ClassLoader一些需要注意的問題
我們都知道，我們可以通過動態載入獲得新的類，從而升級一些程式碼邏輯，這裡有幾個問題要注意一下。
如果你希望通過動態載入的方式，載入一個新版本的dex檔案，使用裡面的新類替換原有的舊類，從而修復原有類的BUG，那麼你必須保證在載入新類的時候，舊類還沒有被載入，因為如果已經載入過舊類，那麼ClassLoader會一直優先使用舊類。
如果舊類總是優先於新類被載入，我們也可以使用一個與載入舊類的ClassLoader沒有樹的繼承關係的另一個ClassLoader來載入新類，因為ClassLoader只會檢查其Parent有沒有載入過當前要載入的類，如果兩個ClassLoader沒有繼承關係，那麼舊類和新類都能被載入。
不過這樣一來又有另一個問題了，在Java中，只有當兩個例項的類名、包名以及載入其的ClassLoader都相同，才會被認為是同一種類型。上面分別載入的新類和舊類，雖然包名和類名都完全一樣，但是由於載入的ClassLoader不同，所以並不是同一種類型，在實際使用中可能會出現型別不符異常。
同一個Class = 相同的 ClassName + PackageName + ClassLoader
以上問題在採用動態載入功能的開發中容易出現，請注意。
DexClassLoader 和 PathClassLoader
在Android中，ClassLoader是一個抽象類，實際開發過程中，我們一般是使用其具體的子類DexClassLoader、PathClassLoader這些類載入器來載入類的，它們的不同之處是：
-
DexClassLoader可以載入jar/apk/dex，可以從SD卡中載入未安裝的apk；
-
PathClassLoader只能載入系統中已經安裝過的apk；
類載入器的初始化
平時開發的時候，使用DexClassLoader就夠用了，但是我們不妨挖一下這兩者具體細節上的區別。
// DexClassLoader.java
public class DexClassLoader extends BaseDexClassLoader {
public DexClassLoader(String dexPath, String optimizedDirectory,
String libraryPath, ClassLoader parent) {
super(dexPath, new File(optimizedDirectory), libraryPath, parent);
}
}
// PathClassLoader.java
public class PathClassLoader extends BaseDexClassLoader {
public PathClassLoader(String dexPath, ClassLoader parent) {
super(dexPath, null, null, parent);
}
public PathClassLoader(String dexPath, String libraryPath,
ClassLoader parent) {
super(dexPath, null, libraryPath, parent);
}
}這兩者只是簡單的對BaseDexClassLoader做了一下封裝，具體的實現還是在父類裡。不過這裡也可以看出，PathClassLoader的optimizedDirectory只能是null，進去BaseDexClassLoader看看這個引數是幹什麼的
public BaseDexClassLoader(String dexPath, File optimizedDirectory,
String libraryPath, ClassLoader parent) {
super(parent);
this.originalPath = dexPath;
this.pathList = new DexPathList(this, dexPath, libraryPath, optimizedDirectory);
}這裡建立了一個DexPathList例項，進去看看
public DexPathList(ClassLoader definingContext, String dexPath,
String libraryPath, File optimizedDirectory) {
……
this.dexElements = makeDexElements(splitDexPath(dexPath), optimizedDirectory);
}
private static Element[] makeDexElements(ArrayList<File> files,
File optimizedDirectory) {
ArrayList<Element> elements = new ArrayList<Element>();
for (File file : files) {
ZipFile zip = null;
DexFile dex = null;
String name = file.getName();
if (name.endsWith(DEX_SUFFIX)) {
dex = loadDexFile(file, optimizedDirectory);
} else if (name.endsWith(APK_SUFFIX) || name.endsWith(JAR_SUFFIX)
|| name.endsWith(ZIP_SUFFIX)) {
zip = new ZipFile(file);
}
……
if ((zip != null) || (dex != null)) {
elements.add(new Element(file, zip, dex));
}
}
return elements.toArray(new Element[elements.size()]);
}
private static DexFile loadDexFile(File file, File optimizedDirectory)
throws IOException {
if (optimizedDirectory == null) {
return new DexFile(file);
} else {
String optimizedPath = optimizedPathFor(file, optimizedDirectory);
return DexFile.loadDex(file.getPath(), optimizedPath, 0);
}
}
/**
* Converts a dex/jar file path and an output directory to an
* output file path for an associated optimized dex file.
*/
private static String optimizedPathFor(File path,
File optimizedDirectory) {
String fileName = path.getName();
if (!fileName.endsWith(DEX_SUFFIX)) {
int lastDot = fileName.lastIndexOf(".");
if (lastDot < 0) {
fileName += DEX_SUFFIX;
} else {
StringBuilder sb = new StringBuilder(lastDot + 4);
sb.append(fileName, 0, lastDot);
sb.append(DEX_SUFFIX);
fileName = sb.toString();
}
}
File result = new File(optimizedDirectory, fileName);
return result.getPath();
}看到這裡我們明白了，optimizedDirectory是用來快取我們需要載入的dex檔案的，並建立一個DexFile物件，如果它為null，那麼會直接使用dex檔案原有的路徑來建立DexFile
物件。
optimizedDirectory必須是一個內部儲存路徑，還記得我們之前說過的，無論哪種動態載入，載入的可執行檔案一定要存放在內部儲存。DexClassLoader可以指定自己的optimizedDirectory，所以它可以載入外部的dex，因為這個dex會被複制到內部路徑的optimizedDirectory；而PathClassLoader沒有optimizedDirectory，所以它只能載入內部的dex，這些大都是存在系統中已經安裝過的apk裡面的。
載入類的過程
上面還只是建立了類載入器的例項，其中建立了一個DexFile例項，用來儲存dex檔案，我們猜想這個例項就是用來載入類的。
Android中，ClassLoader用loadClass方法來載入我們需要的類
public Class<?> loadClass(String className) throws ClassNotFoundException {
return loadClass(className, false);
}
protected Class<?> loadClass(String className, boolean resolve) throws ClassNotFoundException {
Class<?> clazz = findLoadedClass(className);
if (clazz == null) {
ClassNotFoundException suppressed = null;
try {
clazz = parent.loadClass(className, false);
} catch (ClassNotFoundException e) {
suppressed = e;
}
if (clazz == null) {
try {
clazz = findClass(className);
} catch (ClassNotFoundException e) {
e.addSuppressed(suppressed);
throw e;
}
}
}
return clazz;
}loadClass方法呼叫了findClass方法，而BaseDexClassLoader過載了這個方法，得到BaseDexClassLoader看看
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
Class clazz = pathList.findClass(name);
if (clazz == null) {
throw new ClassNotFoundException(name);
}
return clazz;
}結果還是呼叫了DexPathList的findClass
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例項，其實也就是遍歷了所有載入過的dex檔案，再呼叫loadClassBinaryName方法一個個嘗試能不能載入想要的類，真是簡單粗暴
public Class loadClassBinaryName(String name, ClassLoader loader) {
return defineClass(name, loader, mCookie);
}
private native static Class defineClass(String name, ClassLoader loader, int cookie);看到這裡想必大家都明白了，loadClassBinaryName中呼叫了Native方法defineClass載入類。
至此，ClassLoader的建立和載入類的過程的完成了。有趣的是，標準JVM中，ClassLoader是用defineClass載入類的，而Android中defineClass被棄用了，改用了loadClass方法，而且載入類的過程也挪到了DexFile中，在DexFile中載入類的具體方法也叫defineClass，不知道是Google故意寫成這樣的還是巧合。
自定義ClassLoader
平時進行動態載入開發的時候，使用DexClassLoader就夠了。但我們也可以建立自己的類去繼承ClassLoader，需要注意的是loadClass方法並不是final型別的，所以我們可以過載loadClass方法並改寫類的載入邏輯。
通過前面我們分析知道，ClassLoader雙親代理的實現很大一部分就是在loadClass方法裡，我們可以通過重寫loadClass方法避開雙親代理的框架，這樣一來就可以在重新載入已經載入過的類，也可以在載入類的時候注入一些程式碼。這是一種Hack的開發方式，採用這種開發方式的程式穩定性可能比較差，但是卻可以實現一些“黑科技”的功能。
Android程式比起一般Java程式在使用動態載入時麻煩在哪裡
通過上面的分析，我們知道使用ClassLoader動態載入一個外部的類是非常容易的事情，所以很容易就能實現動態載入新的可執行程式碼的功能，但是比起一般的Java程式，在Android程式中使用動態載入主要有兩個麻煩的問題：
-
Android中許多元件類（如Activity、Service等）是需要在Manifest檔案裡面註冊後才能工作的（系統會檢查該元件有沒有註冊），所以即使動態載入了一個新的元件類進來，沒有註冊的話還是無法工作；
-
Res資源是Android開發中經常用到的，而Android是把這些資源用對應的R.id註冊好，執行時通過這些ID從Resource例項中獲取對應的資源。如果是執行時動態載入進來的新類，那類裡面用到R.id的地方將會丟擲找不到資源或者用錯資源的異常，因為新類的資源ID根本和現有的Resource例項中儲存的資源ID對不上；
說到底，拋開虛擬機器的差別不說，一個Android程式和標準的Java程式最大的區別就在於他們的上下文環境（Context）不同。Android中，這個環境可以給程式提供元件需要用到的功能，也可以提供一些主題、Res等資源，其實上面說到的兩個問題都可以統一說是這個環境的問題，而現在的各種Android動態載入框架中，核心要解決的東西也正是“如何給外部的新類提供上下文環境”的問題。