轉(zhuǎn)載請(qǐng)注明出處：http://www.tkk7.com/zh-weir/archive/2011/10/29/362294.html
Android類(lèi)動(dòng)態(tài)加載技術(shù)
Android應(yīng)用開(kāi)發(fā)在一般情況下，常規(guī)的開(kāi)發(fā)方式和代碼架構(gòu)就能滿足我們的普通需求。但是有些特殊問(wèn)題，常常引發(fā)我們進(jìn)一步的沉思。我們從沉思中產(chǎn)生頓悟，從而產(chǎn)生新的技術(shù)形式。
如何開(kāi)發(fā)一個(gè)可以自定義控件的Android應(yīng)用？就像eclipse一樣，可以動(dòng)態(tài)加載插件；如何讓Android應(yīng)用執(zhí)行服務(wù)器上的不可預(yù)知的代碼？如何對(duì)Android應(yīng)用加密，而只在執(zhí)行時(shí)自解密，從而防止被破解？……
熟悉Java技術(shù)的朋友，可能意識(shí)到，我們需要使用類(lèi)加載器靈活的加載執(zhí)行的類(lèi)。這在Java里已經(jīng)算是一項(xiàng)比較成熟的技術(shù)了，但是在Android中，我們大多數(shù)人都還非常陌生。
類(lèi)加載機(jī)制
Dalvik虛擬機(jī)如同其他Java虛擬機(jī)一樣，在運(yùn)行程序時(shí)首先需要將對(duì)應(yīng)的類(lèi)加載到內(nèi)存中。而在Java標(biāo)準(zhǔn)的虛擬機(jī)中，類(lèi)加載可以從class文件中讀取，也可以是其他形式的二進(jìn)制流。因此，我們常常利用這一點(diǎn)，在程序運(yùn)行時(shí)手動(dòng)加載Class，從而達(dá)到代碼動(dòng)態(tài)加載執(zhí)行的目的。
然而Dalvik虛擬機(jī)畢竟不算是標(biāo)準(zhǔn)的Java虛擬機(jī)，因此在類(lèi)加載機(jī)制上，它們有相同的地方，也有不同之處。我們必須區(qū)別對(duì)待。
例如，在使用標(biāo)準(zhǔn)Java虛擬機(jī)時(shí)，我們經(jīng)常自定義繼承自ClassLoader的類(lèi)加載器。然后通過(guò)defineClass方法來(lái)從一個(gè)二進(jìn)制流中加載Class。然而，這在Android里是行不通的，大家就沒(méi)必要走彎路了。參看源碼我們知道，Android中ClassLoader的defineClass方法具體是調(diào)用VMClassLoader的defineClass本地靜態(tài)方法。而這個(gè)本地方法除了拋出一個(gè)“UnsupportedOperationException”之外，什么都沒(méi)做，甚至連返回值都為空。
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虛擬機(jī)類(lèi)加載機(jī)制
那如果在Dalvik虛擬機(jī)里，ClassLoader不好使，我們?nèi)绾螌?shí)現(xiàn)動(dòng)態(tài)加載類(lèi)呢？Android為我們從ClassLoader派生出了兩個(gè)類(lèi)：DexClassLoader和PathClassLoader。其中需要特別說(shuō)明的是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函數(shù)在Dalvik虛擬機(jī)里確實(shí)是被閹割了。而在這兩個(gè)繼承自ClassLoader的類(lèi)加載器，本質(zhì)上是重載了ClassLoader的findClass方法。在執(zhí)行loadClass時(shí)，我們可以參看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都屬于符合雙親委派模型的類(lèi)加載器（因?yàn)樗鼈儧](méi)有重載loadClass方法）。也就是說(shuō)，它們?cè)诩虞d一個(gè)類(lèi)之前，回去檢查自己以及自己以上的類(lèi)加載器是否已經(jīng)加載了這個(gè)類(lèi)。如果已經(jīng)加載過(guò)了，就會(huì)直接將之返回，而不會(huì)重復(fù)加載。
DexClassLoader和PathClassLoader其實(shí)都是通過(guò)DexFile這個(gè)類(lèi)來(lái)實(shí)現(xiàn)類(lèi)加載的。這里需要順便提一下的是，Dalvik虛擬機(jī)識(shí)別的是dex文件，而不是class文件。因此，我們供類(lèi)加載的文件也只能是dex文件，或者包含有dex文件的.apk或.jar文件。
也許有人想到，既然DexFile可以直接加載類(lèi)，那么我們?yōu)槭裁催€要使用ClassLoader的子類(lèi)呢？DexFile在加載類(lèi)時(shí)，具體是調(diào)用成員方法loadClass或者loadClassBinaryName。其中loadClassBinaryName需要將包含包名的類(lèi)名中的”.”轉(zhuǎn)換為”/”。我們看一下loadClass代碼就清楚了：
public Class loadClass(String name, ClassLoader loader) {
String slashName = name.replace('.', '/');
return loadClassBinaryName(slashName, loader);
} 在這段代碼前有一段注釋?zhuān)厝￡P(guān)鍵一部分就是說(shuō)：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子類(lèi)的原因。至于它是如何驗(yàn)證是否是在ClassLoader中調(diào)用此方法的，我沒(méi)有研究，大家如果有興趣可以繼續(xù)深入下去。
有一個(gè)細(xì)節(jié)，可能大家不容易注意到。PathClassLoader是通過(guò)構(gòu)造函數(shù)new DexFile(path)來(lái)產(chǎn)生DexFile對(duì)象的；而DexClassLoader則是通過(guò)其靜態(tài)方法loadDex（path, outpath, 0）得到DexFile對(duì)象。這兩者的區(qū)別在于DexClassLoader需要提供一個(gè)可寫(xiě)的outpath路徑，用來(lái)釋放.apk包或者.jar包中的dex文件。換個(gè)說(shuō)法來(lái)說(shuō)，就是PathClassLoader不能主動(dòng)從zip包中釋放出dex，因此只支持直接操作dex格式文件，或者已經(jīng)安裝的apk（因?yàn)橐呀?jīng)安裝的apk在cache中存在緩存的dex文件）。而DexClassLoader可以支持.apk、.jar和.dex文件，并且會(huì)在指定的outpath路徑釋放出dex文件。
另外，PathClassLoader在加載類(lèi)時(shí)調(diào)用的是DexFile的loadClassBinaryName，而DexClassLoader調(diào)用的是loadClass。因此，在使用PathClassLoader時(shí)類(lèi)全名需要用”/”替換”.”。
實(shí)際操作
這一部分比較簡(jiǎn)單，因此我就不贅言了。只是簡(jiǎn)單的說(shuō)下。
可能使用到的工具都比較常規(guī)：javac、dx、eclipse等。其中dx工具最好是指明--no-strict，因?yàn)?/span>class文件的路徑可能不匹配。
加載好類(lèi)后，通常我們可以通過(guò)Java反射機(jī)制來(lái)使用這個(gè)類(lèi)。但是這樣效率相對(duì)不高，而且老用反射代碼也比較復(fù)雜凌亂。更好的做法是定義一個(gè)interface，并將這個(gè)interface寫(xiě)進(jìn)容器端。待加載的類(lèi)，繼承自這個(gè)interface，并且有一個(gè)參數(shù)為空的構(gòu)造函數(shù)，以使我們能夠通過(guò)Class的newInstance方法產(chǎn)生對(duì)象。然后將對(duì)象強(qiáng)制轉(zhuǎn)換為interface對(duì)象，于是就可以直接調(diào)用成員方法了。
關(guān)于代碼加密的一些設(shè)想
最初設(shè)想將dex文件加密，然后通過(guò)JNI將解密代碼寫(xiě)在Native層。解密之后直接傳上二進(jìn)制流，再通過(guò)defineClass將類(lèi)加載到內(nèi)存中。
現(xiàn)在也可以這樣做，但是由于不能直接使用defineClass，而必須傳文件路徑給dalvik虛擬機(jī)內(nèi)核，因此解密后的文件需要寫(xiě)到磁盤(pán)上，增加了被破解的風(fēng)險(xiǎn)。
Dalvik虛擬機(jī)內(nèi)核僅支持從dex文件加載類(lèi)的方式是不靈活的，由于沒(méi)有非常深入的研究?jī)?nèi)核，我不能確定是Dalvik虛擬機(jī)本身不支持還是Android在移植時(shí)將其閹割了。不過(guò)相信Dalvik或者是Android開(kāi)源項(xiàng)目都正在向能夠支持raw數(shù)據(jù)定義類(lèi)方向努力。
我們可以在文檔中看到Google說(shuō)：Jar or APK file with "classes.dex". (May expand this to include "raw DEX" in the future.)；在Android的Dalvik源碼中我們也能看到RawDexFile的身影（不過(guò)沒(méi)有具體實(shí)現(xiàn)）。
在RawDexFile出來(lái)之前，我們都只能使用這種存在一定風(fēng)險(xiǎn)的加密方式。需要注意釋放的dex文件路徑及權(quán)限管理，另外，在加載完畢類(lèi)之后，除非出于其他目的否則應(yīng)該馬上刪除臨時(shí)的解密文件。
轉(zhuǎn)載請(qǐng)注明出處：http://www.tkk7.com/zh-weir/archive/2011/10/29/362294.html