Android教程網
  1. 首頁
  2. Android 技術
  3. Android 手機
  4. Android 系統教程
  5. Android 游戲
 Android教程網 >> Android技術 >> Android開發實例 >> Android類動態加載技術

Android類動態加載技術

編輯: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”之外,什麼都沒做,甚至連返回值都為空。

  1. static void Dalvik_java_lang_VMClassLoader_defineClass(const u4* args,  
  2.  
  3.     JValue* pResult)  
  4.  
  5. {  
  6.  
  7.     Object* loader = (Object*) args[0];  
  8.  
  9.     StringObject* nameObj = (StringObject*) args[1];  
  10.  
  11.     const u1* data = (const u1*) args[2];  
  12.  
  13.     int offset = args[3];  
  14.  
  15.     int len = args[4];  
  16.  
  17.     Object* pd = (Object*) args[5];  
  18.  
  19.     char* name = NULL;  
  20.  
  21.    
  22.  
  23.     name = dvmCreateCstrFromString(nameObj);  
  24.  
  25.     LOGE("ERROR: defineClass(%p, %s, %p, %d, %d, %p)\n",  
  26.  
  27.         loader, name, data, offset, len, pd);  
  28.  
  29.     dvmThrowException("Ljava/lang/UnsupportedOperationException;",  
  30.  
  31.         "can't load this type of class file");  
  32.  
  33.    
  34.  
  35.     free(name);  
  36.  
  37.     RETURN_VOID();  
  38.  



Dalvik虛擬機類加載機制

       那如果在Dalvik虛擬機裡,ClassLoader不好使,我們如何實現動態加載類呢?Android為我們從ClassLoader派生出了兩個類:DexClassLoader和PathClassLoader。其中需要特別說明的是PathClassLoader中一段被注釋掉的代碼:

這從另一方面佐證了defineClass函數在Dalvik虛擬機裡確實是被閹割了。而在這兩個繼承自ClassLoader的類加載器,本質上是重載了ClassLoader的findClass方法。在執行loadClass時,我們可以參看ClassLoader部分源碼:

  1. /**//* --this doesn't work in current version of Dalvik--  
  2.  
  3.     if (data != null) {  
  4.  
  5.         System.out.println("--- Found class " + name  
  6.  
  7.             + " in zip[" + i + "] '" + mZips[i].getName() + "'");  
  8.  
  9.         int dotIndex = name.lastIndexOf('.');  
  10.  
  11.         if (dotIndex != -1) {  
  12.  
  13.             String packageName = name.substring(0, dotIndex);  
  14.  
  15.             synchronized (this) {  
  16.  
  17.                 Package packageObj = getPackage(packageName);  
  18.  
  19.                 if (packageObj == null) {  
  20.  
  21.                     definePackage(packageName, null, null,  
  22.  
  23.                             null, null, null, null, null);  
  24.  
  25.                 }  
  26.  
  27.             }  
  28.  
  29.         }  
  30.  
  31.    
  32.  
  33.         return defineClass(name, data, 0, data.length);  
  34.  
  35.     }  
  36.  
  37. */ 
  38.  


      

因此DexClassLoader和PathClassLoader都屬於符合雙親委派模型的類加載器(因為它們沒有重載loadClass方法)。也就是說,它們在加載一個類之前,回去檢查自己以及自己以上的類加載器是否已經加載了這個類。如果已經加載過了,就會直接將之返回,而不會重復加載。

  1. protected Class<?> loadClass(String className, boolean resolve)   
  2.  
  3. throws ClassNotFoundException {  
  4.  
  5. Class<?> clazz = findLoadedClass(className);  
  6.  
  7.    
  8.  
  9.     if (clazz == null) {  
  10.  
  11.         try {  
  12.  
  13.             clazz = parent.loadClass(className, false);  
  14.  
  15.         } catch (ClassNotFoundException e) {  
  16.  
  17.             // Don't want to see this.  
  18.  
  19.         }  
  20.  
  21.    
  22.  
  23.         if (clazz == null) {  
  24.  
  25.             clazz = findClass(className);  
  26.  
  27.         }  
  28.  
  29.     }  
  30.  
  31.    
  32.  
  33.     return clazz;  
  34.  


      

       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 [email protected] Class#forName(String)} instead. 這就是我們需要使用ClassLoader子類的原因。至於它是如何驗證是否是在ClassLoader中調用此方法的,我沒有研究,大家如果有興趣可以繼續深入下去。

  1.  
  2. public Class loadClass(String name, ClassLoader loader) {  
  3.  
  4.         String slashName = name.replace('.', '/');  
  5.  
  6.         return loadClassBinaryName(slashName, loader);  
  7.  

 

       有一個細節,可能大家不容易注意到。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文件路徑及權限管理,另外,在加載完畢類之後,除非出於其他目的否則應該馬上刪除臨時的解密文件。

  1. 上一頁:
  2. 下一頁:
熱門文章
閱讀排行版
Copyright © Android教程網 All Rights Reserved