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”之外，什麼都沒做，甚至連傳回值都為空。

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虛拟機類加載機制

       那如果在Dalvik虛拟機裡，ClassLoader不好使，我們如何實作動态加載類呢？Android為我們從ClassLoader派生出了兩個類：DexClassLoader和PathClassLoader。其中需要特别說明的是PathClassLoader中一段被注釋掉的代碼：

       這從另一方面佐證了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