【转】Android类动态加载技术

http://www.blogjava.net/zh-weir/archive/2011/10/29/362294.html

 

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中一段被注释掉的代码：

 

/* --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虚拟机里确实是被阉割了。而在这两个继承自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文件路径及权限管理，另外，在加载完毕类以后，除非出于其余目的不然应该立刻删除临时的解密文件。