Android類動態載入技術
阿新 • • 發佈：2019-01-04
Android類動態載入技術
Android應用開發在一般情況下，常規的開發方式和程式碼架構就能滿足我們的普通需求。但是有些特殊問題，常常引發我們進一步的沉思。我們從沉思中產生頓悟，從而產生新的技術形式。
如何開發一個可以自定義控制元件的Android應用？就像eclipse一樣，可以動態載入外掛；如何讓Android應用執行伺服器上的不可預知的程式碼？如何對Android應用加密，而只在執行時自解密，從而防止被破解？……
熟悉Java技術的朋友，可能意識到，我們需要使用類載入器靈活的載入執行的類。這在Java裡已經算是一項比較成熟的技術了，但是在Android中，我們大多數人都還非常陌生。
類載入機制
Dalvik虛擬機器如同其他Java虛擬機器一樣，在執行程式時首先需要將對應的類載入到記憶體中。而在Java標準的虛擬機器中，類載入可以從class檔案中讀取，也可以是其他形式的二進位制流。因此，我們常常利用這一點，在程式執行時手動載入Class，從而達到程式碼動態載入執行的目的。
然而Dalvik虛擬機器畢竟不算是標準的Java虛擬機器，因此在類載入機制上，它們有相同的地方，也有不同之處。我們必須區別對待。
例如，在使用標準Java虛擬機器時，我們經常自定義繼承自ClassLoader的類載入器。然後通過defineClass方法來從一個二進位制流中載入Class。然而，這在Android裡是行不通的，大家就沒必要走彎路了。參看原始碼我們知道，Android中ClassLoader的defineClass方法具體是呼叫VMClassLoader的defineClass本地靜態方法。而這個本地方法除了丟擲一個“UnsupportedOperationException”之外，什麼都沒做，甚至連返回值都為空。
程式碼:
那如果在Dalvik虛擬機器裡，ClassLoader不好使，我們如何實現動態載入類呢？Android為我們從ClassLoader派生出了兩個類：DexClassLoader和PathClassLoader。其中需要特別說明的是PathClassLoader中一段被註釋掉的程式碼：
程式碼:
這從另一方面佐證了defineClass函式在Dalvik虛擬機器裡確實是被閹割了。而在這兩個繼承自ClassLoader的類載入器，本質上是過載了ClassLoader的findClass方法。在執行loadClass時，我們可以參看ClassLoader部分原始碼：
程式碼:
DexClassLoader和PathClassLoader其實都是通過DexFile這個類來實現類載入的。這裡需要順便提一下的是，Dalvik虛擬機器識別的是dex檔案，而不是class檔案。因此，我們供類載入的檔案也只能是dex檔案，或者包含有dex檔案的.apk或.jar檔案。
也許有人想到，既然DexFile可以直接載入類，那麼我們為什麼還要使用ClassLoader的子類呢？DexFile在載入類時，具體是呼叫成員方法loadClass或者loadClassBinaryName。其中loadClassBinaryName需要將包含包名的類名中的”.”轉換為”/”。我們看一下loadClass程式碼就清楚了：
程式碼:
在這段程式碼前有一段註釋，擷取關鍵一部分就是說：If you are not calling this from a class loader, this is most likely not going to do what you want. Use {@link Class#forName(String)} instead. 這就是我們需要使用ClassLoader子類的原因。至於它是如何驗證是否是在ClassLoader中呼叫此方法的，我沒有研究，大家如果有興趣可以繼續深入下去。
有一個細節，可能大家不容易注意到。PathClassLoader是通過建構函式new DexFile(path)來產生DexFile物件的；而DexClassLoader則是通過其靜態方法loadDex（path, outpath, 0）得到DexFile物件。這兩者的區別在於DexClassLoader需要提供一個可寫的outpath路徑，用來釋放.apk包或者.jar包中的dex檔案。換個說法來說，就是PathClassLoader不能主動從zip包中釋放出dex，因此只支援直接操作dex格式檔案，或者已經安裝的apk（因為已經安裝的apk在cache中存在快取的dex檔案）。而DexClassLoader可以支援.apk、.jar和.dex檔案，並且會在指定的outpath路徑釋放出dex檔案。
另外，PathClassLoader在載入類時呼叫的是DexFile的loadClassBinaryName，而DexClassLoader呼叫的是loadClass。因此，在使用PathClassLoader時類全名需要用”/”替換”.”。
實際操作
這一部分比較簡單，因此我就不贅言了。只是簡單的說下。
可能使用到的工具都比較常規：javac、dx、eclipse等。其中dx工具最好是指明--no-strict，因為class檔案的路徑可能不匹配。
載入好類後，通常我們可以通過Java反射機制來使用這個類。但是這樣效率相對不高，而且老用反射程式碼也比較複雜凌亂。更好的做法是定義一個interface，並將這個interface寫進容器端。待載入的類，繼承自這個interface，並且有一個引數為空的建構函式，以使我們能夠通過Class的newInstance方法產生物件。然後將物件強制轉換為interface物件，於是就可以直接呼叫成員方法了。
關於程式碼加密的一些設想
最初設想將dex檔案加密，然後通過JNI將解密程式碼寫在Native層。解密之後直接傳上二進位制流，再通過defineClass將類載入到記憶體中。
現在也可以這樣做，但是由於不能直接使用defineClass，而必須傳檔案路徑給dalvik虛擬機器核心，因此解密後的檔案需要寫到磁碟上，增加了被破解的風險。
Dalvik虛擬機器核心僅支援從dex檔案載入類的方式是不靈活的，由於沒有非常深入的研究核心，我不能確定是Dalvik虛擬機器本身不支援還是Android在移植時將其閹割了。不過相信Dalvik或者是Android開源專案都正在向能夠支援raw資料定義類方向努力。
我們可以在文件中看到Google說：Jar or APK file with "classes.dex". (May expand this to include "raw DEX" in the future.)；在Android的Dalvik原始碼中我們也能看到RawDexFile的身影（不過沒有具體實現）。
在RawDexFile出來之前，我們都只能使用這種存在一定風險的加密方式。需要注意釋放的dex檔案路徑及許可權管理，另外，在載入完畢類之後，除非出於其他目的否則應該馬上刪除臨時的解密檔案。
轉載請註明出處：http://www.blogjava.net/zh-weir/archive/2011/10/29/362294.html
Android應用開發在一般情況下，常規的開發方式和程式碼架構就能滿足我們的普通需求。但是有些特殊問題，常常引發我們進一步的沉思。我們從沉思中產生頓悟，從而產生新的技術形式。
如何開發一個可以自定義控制元件的Android應用？就像eclipse一樣，可以動態載入外掛；如何讓Android應用執行伺服器上的不可預知的程式碼？如何對Android應用加密，而只在執行時自解密，從而防止被破解？……
熟悉Java技術的朋友，可能意識到，我們需要使用類載入器靈活的載入執行的類。這在Java裡已經算是一項比較成熟的技術了，但是在Android中，我們大多數人都還非常陌生。
類載入機制
Dalvik虛擬機器如同其他Java虛擬機器一樣，在執行程式時首先需要將對應的類載入到記憶體中。而在Java標準的虛擬機器中，類載入可以從class檔案中讀取，也可以是其他形式的二進位制流。因此，我們常常利用這一點，在程式執行時手動載入Class，從而達到程式碼動態載入執行的目的。
然而Dalvik虛擬機器畢竟不算是標準的Java虛擬機器，因此在類載入機制上，它們有相同的地方，也有不同之處。我們必須區別對待。
例如，在使用標準Java虛擬機器時，我們經常自定義繼承自ClassLoader的類載入器。然後通過defineClass方法來從一個二進位制流中載入Class。然而，這在Android裡是行不通的，大家就沒必要走彎路了。參看原始碼我們知道，Android中ClassLoader的defineClass方法具體是呼叫VMClassLoader的defineClass本地靜態方法。而這個本地方法除了丟擲一個“UnsupportedOperationException”之外，什麼都沒做，甚至連返回值都為空。
程式碼:
static void Dalvik_java_lang_VMClassLoader_defineClass(const u4* args, JValue* pResult)
{
Object* loader = (Object*) args[0];
StringObject* nameObj = (StringObject*) args[1];
const u1* data = (const u1*) args[2];
int offset = args[3];
int len = args[4];
Object* pd = (Object*) args[5];
char* name = NULL;
name = dvmCreateCstrFromString(nameObj);
LOGE("ERROR: defineClass(%p, %s, %p, %d, %d, %p)\n", loader, name, data, offset, len, pd);
dvmThrowException("Ljava/lang/UnsupportedOperationException;", "can't load this type of class file");
free(name);
RETURN_VOID();
}
那如果在Dalvik虛擬機器裡，ClassLoader不好使，我們如何實現動態載入類呢？Android為我們從ClassLoader派生出了兩個類：DexClassLoader和PathClassLoader。其中需要特別說明的是PathClassLoader中一段被註釋掉的程式碼：
程式碼:
/**//* --this doesn't work in current version of Dalvik--
if (data != null) {
System.out.println("--- Found class " + name + " in zip[" + i + "] '" + mZips[i].getName() + "'");
int dotIndex = name.lastIndexOf('.');
if (dotIndex != -1) {
String packageName = name.substring(0, dotIndex);
synchronized (this) {
Package packageObj = getPackage(packageName);
if (packageObj == null) {
definePackage(packageName, null, null, null, null, null, null, null);
}
}
}
return defineClass(name, data, 0, data.length);
}
*/
這從另一方面佐證了defineClass函式在Dalvik虛擬機器裡確實是被閹割了。而在這兩個繼承自ClassLoader的類載入器，本質上是過載了ClassLoader的findClass方法。在執行loadClass時，我們可以參看ClassLoader部分原始碼：
程式碼:
protected Class<?> loadClass(String className, boolean resolve) throws ClassNotFoundException {
Class<?> clazz = findLoadedClass(className);
if (clazz == null) {
try {
clazz = parent.loadClass(className, false);
} catch (ClassNotFoundException e) {
// Don't want to see this.
}
if (clazz == null) {
clazz = findClass(className);
}
}
return clazz;
}
因此DexClassLoader和PathClassLoader都屬於符合雙親委派模型的類載入器（因為它們沒有過載loadClass方法）。也就是說，它們在載入一個類之前，回去檢查自己以及自己以上的類載入器是否已經載入了這個類。如果已經載入過了，就會直接將之返回，而不會重複載入。DexClassLoader和PathClassLoader其實都是通過DexFile這個類來實現類載入的。這裡需要順便提一下的是，Dalvik虛擬機器識別的是dex檔案，而不是class檔案。因此，我們供類載入的檔案也只能是dex檔案，或者包含有dex檔案的.apk或.jar檔案。
也許有人想到，既然DexFile可以直接載入類，那麼我們為什麼還要使用ClassLoader的子類呢？DexFile在載入類時，具體是呼叫成員方法loadClass或者loadClassBinaryName。其中loadClassBinaryName需要將包含包名的類名中的”.”轉換為”/”。我們看一下loadClass程式碼就清楚了：
程式碼:
public Class loadClass(String name, ClassLoader loader) {
String slashName = name.replace('.', '/');
return loadClassBinaryName(slashName, loader);
}
在這段程式碼前有一段註釋，擷取關鍵一部分就是說：If you are not calling this from a class loader, this is most likely not going to do what you want. Use {@link Class#forName(String)} instead. 這就是我們需要使用ClassLoader子類的原因。至於它是如何驗證是否是在ClassLoader中呼叫此方法的，我沒有研究，大家如果有興趣可以繼續深入下去。
有一個細節，可能大家不容易注意到。PathClassLoader是通過建構函式new DexFile(path)來產生DexFile物件的；而DexClassLoader則是通過其靜態方法loadDex（path, outpath, 0）得到DexFile物件。這兩者的區別在於DexClassLoader需要提供一個可寫的outpath路徑，用來釋放.apk包或者.jar包中的dex檔案。換個說法來說，就是PathClassLoader不能主動從zip包中釋放出dex，因此只支援直接操作dex格式檔案，或者已經安裝的apk（因為已經安裝的apk在cache中存在快取的dex檔案）。而DexClassLoader可以支援.apk、.jar和.dex檔案，並且會在指定的outpath路徑釋放出dex檔案。
另外，PathClassLoader在載入類時呼叫的是DexFile的loadClassBinaryName，而DexClassLoader呼叫的是loadClass。因此，在使用PathClassLoader時類全名需要用”/”替換”.”。
實際操作
這一部分比較簡單，因此我就不贅言了。只是簡單的說下。
可能使用到的工具都比較常規：javac、dx、eclipse等。其中dx工具最好是指明--no-strict，因為class檔案的路徑可能不匹配。
載入好類後，通常我們可以通過Java反射機制來使用這個類。但是這樣效率相對不高，而且老用反射程式碼也比較複雜凌亂。更好的做法是定義一個interface，並將這個interface寫進容器端。待載入的類，繼承自這個interface，並且有一個引數為空的建構函式，以使我們能夠通過Class的newInstance方法產生物件。然後將物件強制轉換為interface物件，於是就可以直接呼叫成員方法了。
關於程式碼加密的一些設想
最初設想將dex檔案加密，然後通過JNI將解密程式碼寫在Native層。解密之後直接傳上二進位制流，再通過defineClass將類載入到記憶體中。
現在也可以這樣做，但是由於不能直接使用defineClass，而必須傳檔案路徑給dalvik虛擬機器核心，因此解密後的檔案需要寫到磁碟上，增加了被破解的風險。
Dalvik虛擬機器核心僅支援從dex檔案載入類的方式是不靈活的，由於沒有非常深入的研究核心，我不能確定是Dalvik虛擬機器本身不支援還是Android在移植時將其閹割了。不過相信Dalvik或者是Android開源專案都正在向能夠支援raw資料定義類方向努力。
我們可以在文件中看到Google說：Jar or APK file with "classes.dex". (May expand this to include "raw DEX" in the future.)；在Android的Dalvik原始碼中我們也能看到RawDexFile的身影（不過沒有具體實現）。
在RawDexFile出來之前，我們都只能使用這種存在一定風險的加密方式。需要注意釋放的dex檔案路徑及許可權管理，另外，在載入完畢類之後，除非出於其他目的否則應該馬上刪除臨時的解密檔案。
轉載請註明出處：http://www.blogjava.net/zh-weir/archive/2011/10/29/362294.html