在目前的軟硬件環(huán)境下,Native App與Web App在用戶(hù)體驗上有著(zhù)明顯的優(yōu)勢,但在實(shí)際項目中有些會(huì )因為業(yè)務(wù)的頻繁變更而頻繁的升級客戶(hù)端,造成較差的用戶(hù)體驗,而這也恰恰是Web App的優(yōu)勢。本文對網(wǎng)上Android動(dòng)態(tài)加載jar的資料進(jìn)行梳理和實(shí)踐在這里與大家一起分享,試圖改善頻繁升級這一弊病。
Android應用開(kāi)發(fā)在一般情況下,常規的開(kāi)發(fā)方式和代碼架構就能滿(mǎn)足我們的普通需求。但是有些特殊問(wèn)題,常常引發(fā)我們進(jìn)一步的沉思。我們從沉思中產(chǎn)生頓悟,從而產(chǎn)生新的技術(shù)形式。
如何開(kāi)發(fā)一個(gè)可以自定義控件的Android應用?就像eclipse一樣,可以動(dòng)態(tài)加載插件;如何讓Android應用執行服務(wù)器上的不可預知的代碼?如何對Android應用加密,而只在執行時(shí)自解密,從而防止被破解?……
熟悉Java技術(shù)的朋友,可能意識到,我們需要使用類(lèi)加載器靈活的加載執行的類(lèi)。這在Java里已經(jīng)算是一項比較成熟的技術(shù)了,但是在A(yíng)ndroid中,我們大多數人都還非常陌生。
類(lèi)加載機制
Dalvik虛擬機如同其他Java虛擬機一樣,在運行程序時(shí)首先需要將對應的類(lèi)加載到內存中。而在Java標準的虛擬機中,類(lèi)加載可以從class文件中讀取,也可以是其他形式的二進(jìn)制流,因此,我們常常利用這一點(diǎn),在程序運行時(shí)手動(dòng)加載Class,從而達到代碼動(dòng)態(tài)加載執行的目的
然而Dalvik虛擬機畢竟不算是標準的Java虛擬機,因此在類(lèi)加載機制上,它們有相同的地方,也有不同之處。我們必須區別對待
例如,在使用標準Java虛擬機時(shí),我們經(jīng)常自定義繼承自ClassLoader的類(lèi)加載器。然后通過(guò)defineClass方法來(lái)從一個(gè)二進(jìn)制流中加載Class。然而,這在A(yíng)ndroid里是行不通的,大家就沒(méi)必要走彎路了。參看源碼我們知道,Android中ClassLoader的defineClass方法具體是調用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虛擬機類(lèi)加載機制
那如果在Dalvik虛擬機里,ClassLoader不好使,我們如何實(shí)現動(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函數在Dalvik虛擬機里確實(shí)是被閹割了。而在這兩個(gè)繼承自ClassLoader的類(lèi)加載器,本質(zhì)上是重載了ClassLoader的findClass方法。在執行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)加載器(因為它們沒(méi)有重載loadClass方法)。也就是說(shuō),它們在加載一個(gè)類(lèi)之前,回去檢查自己以及自己以上的類(lèi)加載器是否已經(jīng)加載了這個(gè)類(lèi)。如果已經(jīng)加載過(guò)了,就會(huì )直接將之返回,而不會(huì )重復加載。
DexClassLoader和PathClassLoader其實(shí)都是通過(guò)DexFile這個(gè)類(lèi)來(lái)實(shí)現類(lèi)加載的。這里需要順便提一下的是,Dalvik虛擬機識別的是dex文件,而不是class文件。因此,我們供類(lèi)加載的文件也只能是dex文件,或者包含有dex文件的.apk或.jar文件。
也許有人想到,既然DexFile可以直接加載類(lèi),那么我們?yōu)槭裁催€要使用ClassLoader的子類(lèi)呢?DexFile在加載類(lèi)時(shí),具體是調用成員方法loadClass或者loadClassBinaryName。其中loadClassBinaryName需要將包含包名的類(lèi)名中的”.”轉換為”/”我們看一下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)的原因。至于它是如何驗證是否是在ClassLoader中調用此方法的,我沒(méi)有研究,大家如果有興趣可以繼續深入下去。
有一個(gè)細節,可能大家不容易注意到。PathClassLoader是通過(guò)構造函數new DexFile(path)來(lái)產(chǎn)生DexFile對象的;而DexClassLoader則是通過(guò)其靜態(tài)方法loadDex(path, outpath, 0)得到DexFile對象。這兩者的區別在于DexClassLoader需要提供一個(gè)可寫(xiě)的outpath路徑,用來(lái)釋放.apk包或者.jar包中的dex文件。換個(gè)說(shuō)法來(lái)說(shuō),就是PathClassLoader不能主動(dòng)從zip包中釋放出dex,因此只支持直接操作dex格式文件,或者已經(jīng)安裝的apk(因為已經(jīng)安裝的apk在cache中存在緩存的dex文件)。而DexClassLoader可以支持.apk、.jar和.dex文件,并且會(huì )在指定的outpath路徑釋放出dex文件。
另外,PathClassLoader在加載類(lèi)時(shí)調用的是DexFile的loadClassBinaryName,而DexClassLoader調用的是loadClass。因此,在使用PathClassLoader時(shí)類(lèi)全名需要用”/”替換”.”
實(shí)際操作
使用到的工具都比較常規:javac、dx、eclipse等其中dx工具最好是指明--no-strict,因為class文件的路徑可能不匹配
加載好類(lèi)后,通常我們可以通過(guò)Java反射機制來(lái)使用這個(gè)類(lèi)但是這樣效率相對不高,而且老用反射代碼也比較復雜凌亂。更好的做法是定義一個(gè)interface,并將這個(gè)interface寫(xiě)進(jìn)容器端。待加載的類(lèi),繼承自這個(gè)interface,并且有一個(gè)參數為空的構造函數,以使我們能夠通過(guò)Class的newInstance方法產(chǎn)生對象然后將對象強制轉換為interface對象,于是就可以直接調用成員方法了,下面是具體的實(shí)現步驟了:
第一步:
編寫(xiě)好動(dòng)態(tài)代碼類(lèi):
- package com.dynamic.interfaces;
- import android.app.Activity;
- /**
- * 動(dòng)態(tài)加載類(lèi)的接口
- */
- public interface IDynamic {
- /**初始化方法*/
- public void init(Activity activity);
- /**自定義方法*/
- public void showBanner();
- public void showDialog();
- public void showFullScreen();
- public void showAppWall();
- /**銷(xiāo)毀方法*/
- public void destory();
- }
實(shí)現類(lèi)代碼如下:- package com.dynamic.impl;
-
- import android.app.Activity;
- import android.widget.Toast;
-
- import com.dynamic.interfaces.IDynamic;
-
- /**
- * 動(dòng)態(tài)類(lèi)的實(shí)現
- *
- */
- public class Dynamic implements IDynamic{
-
- private Activity mActivity;
-
- @Override
- public void init(Activity activity) {
- mActivity = activity;
- }
-
- @Override
- public void showBanner() {
- Toast.makeText(mActivity, "我是ShowBannber方法", 1500).show();
- }
-
- @Override
- public void showDialog() {
- Toast.makeText(mActivity, "我是ShowDialog方法", 1500).show();
- }
-
- @Override
- public void showFullScreen() {
- Toast.makeText(mActivity, "我是ShowFullScreen方法", 1500).show();
- }
-
- @Override
- public void showAppWall() {
- Toast.makeText(mActivity, "我是ShowAppWall方法", 1500).show();
- }
-
- @Override
- public void destory() {
- }
-
- }
這樣動(dòng)態(tài)類(lèi)就開(kāi)發(fā)好了
第二步:
將上面開(kāi)發(fā)好的動(dòng)態(tài)類(lèi)打包成.jar,這里要注意的是只打包實(shí)現類(lèi)Dynamic.java,不打包接口類(lèi)IDynamic.java,
然后將打包好的jar文件拷貝到android的安裝目錄中的platform-tools目錄下,使用dx命令:(我的jar文件是dynamic.jar)
dx --dex --output=dynamic_temp.jar dynamic.jar
這樣就生成了dynamic_temp.jar,這個(gè)jar和dynamic.jar有什么區別呢?
其實(shí)這條命令主要做的工作是:首先將dynamic.jar編譯成dynamic.dex文件(Android虛擬機認識的字節碼文件),然后再將dynamic.dex文件壓縮成dynamic_temp.jar,當然你也可以壓縮成.zip格式的,或者直接編譯成.apk文件都可以的,這個(gè)后面會(huì )說(shuō)到。
到這里還不算完事,因為你想想用什么來(lái)連接動(dòng)態(tài)類(lèi)和目標類(lèi)呢?那就是動(dòng)態(tài)類(lèi)的接口了,所以這時(shí)候還要打個(gè).jar包,這時(shí)候只需要打接口類(lèi)IDynamic.java了
然后將這個(gè).jar文件引用到目標類(lèi)中,下面來(lái)看一下目標類(lèi)的實(shí)現:
- package com.jiangwei.demo;
-
- import java.io.File;
- import java.util.List;
-
- import android.app.Activity;
- import android.content.Intent;
- import android.content.pm.ActivityInfo;
- import android.content.pm.PackageManager;
- import android.content.pm.ResolveInfo;
- import android.os.Bundle;
- import android.os.Environment;
- import android.view.View;
- import android.widget.Button;
- import android.widget.Toast;
-
- import com.dynamic.interfaces.IDynamic;
-
- import dalvik.system.DexClassLoader;
- import dalvik.system.PathClassLoader;
-
- public class AndroidDynamicLoadClassActivity extends Activity {
-
- //動(dòng)態(tài)類(lèi)加載接口
- private IDynamic lib;
-
- @Override
- public void onCreate(Bundle savedInstanceState) {
- super.onCreate(savedInstanceState);
- setContentView(R.layout.main);
- //初始化組件
- Button showBannerBtn = (Button) findViewById(R.id.show_banner_btn);
- Button showDialogBtn = (Button) findViewById(R.id.show_dialog_btn);
- Button showFullScreenBtn = (Button) findViewById(R.id.show_fullscreen_btn);
- Button showAppWallBtn = (Button) findViewById(R.id.show_appwall_btn);
- /**使用DexClassLoader方式加載類(lèi)*/
- //dex壓縮文件的路徑(可以是apk,jar,zip格式)
- String dexPath = Environment.getExternalStorageDirectory().toString() + File.separator + "Dynamic.apk";
- //dex解壓釋放后的目錄
- //String dexOutputDir = getApplicationInfo().dataDir;
- String dexOutputDirs = Environment.getExternalStorageDirectory().toString();
- //定義DexClassLoader
- //第一個(gè)參數:是dex壓縮文件的路徑
- //第二個(gè)參數:是dex解壓縮后存放的目錄
- //第三個(gè)參數:是C/C++依賴(lài)的本地庫文件目錄,可以為null
- //第四個(gè)參數:是上一級的類(lèi)加載器
- DexClassLoader cl = new DexClassLoader(dexPath,dexOutputDirs,null,getClassLoader());
-
- /**使用PathClassLoader方法加載類(lèi)*/
- //創(chuàng )建一個(gè)意圖,用來(lái)找到指定的apk:這里的"com.dynamic.impl是指定apk中在A(yíng)ndroidMainfest.xml文件中定義的<action name="com.dynamic.impl"/>
- Intent intent = new Intent("com.dynamic.impl", null);
- //獲得包管理器
- PackageManager pm = getPackageManager();
- List<ResolveInfo> resolveinfoes = pm.queryIntentActivities(intent, 0);
- //獲得指定的activity的信息
- ActivityInfo actInfo = resolveinfoes.get(0).activityInfo;
- //獲得apk的目錄或者jar的目錄
- String apkPath = actInfo.applicationInfo.sourceDir;
- //native代碼的目錄
- String libPath = actInfo.applicationInfo.nativeLibraryDir;
- //創(chuàng )建類(lèi)加載器,把dex加載到虛擬機中
- //第一個(gè)參數:是指定apk安裝的路徑,這個(gè)路徑要注意只能是通過(guò)actInfo.applicationInfo.sourceDir來(lái)獲取
- //第二個(gè)參數:是C/C++依賴(lài)的本地庫文件目錄,可以為null
- //第三個(gè)參數:是上一級的類(lèi)加載器
- PathClassLoader pcl = new PathClassLoader(apkPath,libPath,this.getClassLoader());
- //加載類(lèi)
- try {
- //com.dynamic.impl.Dynamic是動(dòng)態(tài)類(lèi)名
- //使用DexClassLoader加載類(lèi)
- //Class libProviderClazz = cl.loadClass("com.dynamic.impl.Dynamic");
- //使用PathClassLoader加載類(lèi)
- Class libProviderClazz = pcl.loadClass("com.dynamic.impl.Dynamic");
- lib = (IDynamic)libProviderClazz.newInstance();
- if(lib != null){
- lib.init(AndroidDynamicLoadClassActivity.this);
- }
- } catch (Exception exception) {
- exception.printStackTrace();
- }
- /**下面分別調用動(dòng)態(tài)類(lèi)中的方法*/
- showBannerBtn.setOnClickListener(new View.OnClickListener() {
- public void onClick(View view) {
- if(lib != null){
- lib.showBanner();
- }else{
- Toast.makeText(getApplicationContext(), "類(lèi)加載失敗", 1500).show();
- }
- }
- });
- showDialogBtn.setOnClickListener(new View.OnClickListener() {
- public void onClick(View view) {
- if(lib != null){
- lib.showDialog();
- }else{
- Toast.makeText(getApplicationContext(), "類(lèi)加載失敗", 1500).show();
- }
- }
- });
- showFullScreenBtn.setOnClickListener(new View.OnClickListener() {
- public void onClick(View view) {
- if(lib != null){
- lib.showFullScreen();
- }else{
- Toast.makeText(getApplicationContext(), "類(lèi)加載失敗", 1500).show();
- }
- }
- });
- showAppWallBtn.setOnClickListener(new View.OnClickListener() {
- public void onClick(View view) {
- if(lib != null){
- lib.showAppWall();
- }else{
- Toast.makeText(getApplicationContext(), "類(lèi)加載失敗", 1500).show();
- }
- }
- });
- }
- }
這里面定義了一個(gè)IDynamic接口變量,同時(shí)使用了DexClassLoader和PathClassLoader來(lái)加載類(lèi),這里面先來(lái)說(shuō)一說(shuō)DexClassLoader方式加載:
- //定義DexClassLoader
- //第一個(gè)參數:是dex壓縮文件的路徑
- //第二個(gè)參數:是dex解壓縮后存放的目錄
- //第三個(gè)參數:是C/C++依賴(lài)的本地庫文件目錄,可以為null
- //第四個(gè)參數:是上一級的類(lèi)加載器
- DexClassLoader cl = new DexClassLoader(dexPath,dexOutputDirs,null,getClassLoader());
上面已經(jīng)說(shuō)了,DexClassLoader是繼承ClassLoader類(lèi)的,這里面的參數說(shuō)明:第一個(gè)參數是:dex壓縮文件的路徑:這個(gè)就是我們將上面編譯后的dynamic_temp.jar存放的目錄,當然也可以是.zip和.apk格式的
第二個(gè)參數是:dex解壓后存放的目錄:這個(gè)就是將.jar,.zip,.apk文件解壓出的dex文件存放的目錄,這個(gè)就和PathClassLoader方法有區別了,同時(shí)你也可以看到PathClassLoader方法中沒(méi)有這個(gè)參數,這個(gè)也真是這兩個(gè)類(lèi)的區別:
PathClassLoader不能主動(dòng)從zip包中釋放出dex,因此只支持直接操作dex格式文件,或者已經(jīng)安裝的apk(因為已經(jīng)安裝的apk在手機的data/dalvik目錄中存在緩存的dex文件)。而DexClassLoader可以支持.apk、.jar和.dex文件,并且會(huì )在指定的outpath路徑釋放出dex文件。
然而我們可以通過(guò)DexClassLoader方法指定解壓后的dex文件的存放目錄,但是我們一般不這么做,因為這樣做無(wú)疑的暴露了dex文件,所以我們一般不會(huì )將.jar/.zip/.apk壓縮文件存放到用戶(hù)可以察覺(jué)到的位置,同時(shí)解壓dex的目錄也是不能讓用戶(hù)看到的。
第三個(gè)參數和第四個(gè)參數用到的不是很多,所以這里就不做太多的解釋了。
這里還要注意一點(diǎn)就是PathClassLoader方法的時(shí)候,第一個(gè)參數是dex存放的路徑,這里傳遞的是:
- //獲得apk的目錄或者jar的目錄
- String apkPath = actInfo.applicationInfo.sourceDir;
指定的apk安裝路徑,這個(gè)值只能這樣獲取,不然會(huì )加載類(lèi)失敗的
第三步:
運行目標類(lèi):
要做的工作是:
如果用的是DexClassLoader方式加載類(lèi):這時(shí)候需要將.jar或者.zip或者.apk文件放到指定的目錄中,我這里為了方便就放到sd卡的根目錄中
如果用的是PathClassLoader方法加載類(lèi):這時(shí)候需要先將Dynamic.apk安裝到手機中,不然找不到這個(gè)activity,同時(shí)要注意的是:
- //創(chuàng )建一個(gè)意圖,用來(lái)找到指定的apk:這里的"com.dynamic.impl是指定apk中在A(yíng)ndroidMainfest.xml文件中定義的<action name="com.dynamic.impl"/>
- Intent intent = new Intent("com.dynamic.impl", null);
這里的com.dynamic.impl是一個(gè)action需要在指定的apk中定義,這個(gè)名稱(chēng)是動(dòng)態(tài)apk和目標apk之間約定好的運行結果
點(diǎn)擊showBanner顯示一個(gè)Toast,成功的運行了動(dòng)態(tài)類(lèi)中的代碼!
其實(shí)更好的辦法就是將動(dòng)態(tài)的.jar.zip.apk文件從網(wǎng)絡(luò )上獲取,安全可靠,同時(shí)本地的目標項目不需要改動(dòng)代碼就可以執行不同的邏輯了
關(guān)于代碼加密的一些設想
最初設想將dex文件加密,然后通過(guò)JNI將解密代碼寫(xiě)在Native層。解密之后直接傳上二進(jìn)制流,再通過(guò)defineClass將類(lèi)加載到內存中。
現在也可以這樣做,但是由于不能直接使用defineClass,而必須傳文件路徑給dalvik虛擬機內核,因此解密后的文件需要寫(xiě)到磁盤(pán)上,增加了被破解的風(fēng)險。
Dalvik虛擬機內核僅支持從dex文件加載類(lèi)的方式是不靈活的,由于沒(méi)有非常深入的研究?jì)群?,我不能確定是Dalvik虛擬機本身不支持還是Android在移植時(shí)將其閹割了。不過(guò)相信Dalvik或者是Android開(kāi)源項目都正在向能夠支持raw數據定義類(lèi)方向努力。
我們可以在文檔中看到Google說(shuō):Jar or APK file with "classes.dex". (May expand this to include "raw DEX" in the future.);在A(yíng)ndroid的Dalvik源碼中我們也能看到RawDexFile的身影(不過(guò)沒(méi)有具體實(shí)現)
在RawDexFile出來(lái)之前,我們都只能使用這種存在一定風(fēng)險的加密方式。需要注意釋放的dex文件路徑及權限管理,另外,在加載完畢類(lèi)之后,除非出于其他目的否則應該馬上刪除臨時(shí)的解密文件