http://www.blogjava.net/zh-weir/archive/2011/10/29/362294.htmlhtml
Android應用開發在通常狀況下,常規的開發方式和代碼架構就能知足咱們的普通需求。可是有些特殊問題,經常引起咱們進一步的沉思。咱們從沉思中產生頓悟,從而產生新的技術形式。java
如何開發一個能夠自定義控件的Android應用?就像eclipse同樣,能夠動態加載插件;如何讓Android應用執行服務器上的不可預知的代碼?如何對Android應用加密,而只在執行時自解密,從而防止被破解?……緩存
熟悉Java技術的朋友,可能意識到,咱們須要使用類加載器靈活的加載執行的類。這在Java裏已經算是一項比較成熟的技術了,可是在Android中,咱們大多數人都還很是陌生。
服務器
Dalvik虛擬機如同其餘Java虛擬機同樣,在運行程序時首先須要將對應的類加載到內存中。而在Java標準的虛擬機中,類加載能夠從class文件中讀取,也能夠是其餘形式的二進制流。所以,咱們經常利用這一點,在程序運行時手動加載Class,從而達到代碼動態加載執行的目的。架構
然而Dalvik虛擬機畢竟不算是標準的Java虛擬機,所以在類加載機制上,它們有相同的地方,也有不一樣之處。咱們必須區別對待。eclipse
例如,在使用標準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部分源碼:this
所以DexClassLoader和PathClassLoader都屬於符合雙親委派模型的類加載器(由於它們沒有重載loadClass方法)。也就是說,它們在加載一個類以前,回去檢查本身以及本身以上的類加載器是否已經加載了這個類。若是已經加載過了,就會直接將之返回,而不會重複加載。加密
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文件路徑及權限管理,另外,在加載完畢類以後,除非出於其餘目的不然應該立刻刪除臨時的解密文件。