【Android高级】Dalvik虚拟机及其类加载器讲解

      插件开发的过程中DexClassLoader和PathClassLoader这两个类加载器了是很重要的,但是他们也是有区别的,而且我们也知道PathClassLoader是Android应用中的默认加载器。他们的区别是:
      DexClassLoader可以加载任何路径的apk/dex/jar
      PathClassLoader只能加载/data/app中的apk,也就是已经安装到手机中的apk。这个也是PathClassLoader作为默认的类加载器的原因,因为一般程序都是安装了,在打开,这时候PathClassLoader就去加载指定的apk(解压成dex,然后在优化成odex)就可以了。

      Dalvik虚拟机如同其他Java虚拟机一样,在运行程序时首先需要将对应的类加载到内存中。而在Java标准的虚拟机中,类加载可以从class文件中读取,也可以是其他形式的二进制流,因此,我们常常利用这一点,在程序运行时手动加载Class,从而达到代码动态加载执行的目的

       然而Dalvik虚拟机毕竟不算是标准的Java虚拟机,因此在类加载机制上,它们有相同的地方,也有不同之处。我们必须区别对待

       例如,在使用标准Java虚拟机时,我们经常自定义继承自ClassLoader的类加载器。然后通过defineClass方法来从一个二进制流中加载Class。然而,这在Android里是行不通的,大家就没必要走弯路了。参看源码我们知道,Android中ClassLoader的defineClass方法具体是调用VMClassLoader的defineClass本地静态方法。而这个本地方法除了抛出一个“UnsupportedOperationException”之外,什么都没做,甚至连返回值都为空

[cpp]  view plain copy
  1. static void Dalvik_java_lang_VMClassLoader_defineClass(const u4* args,JValue* pResult){  
  2.     Object* loader = (Object*) args[0];  
  3.     StringObject* nameObj = (StringObject*) args[1];  
  4.     const u1* data = (const u1*) args[2];  
  5.     int offset = args[3];  
  6.     int len = args[4];  
  7.     Object* pd = (Object*) args[5];  
  8.     char* name = NULL;  
  9.     name = dvmCreateCstrFromString(nameObj);  
  10.     LOGE("ERROR: defineClass(%p, %s, %p, %d, %d, %p)\n",loader, name, data, offset, len, pd);  
  11.     dvmThrowException("Ljava/lang/UnsupportedOperationException;","can't load this type of class file");  
  12.     free(name);  
  13.     RETURN_VOID();  
  14. }  

Dalvik虚拟机类加载机制
       那如果在Dalvik虚拟机里,ClassLoader不好使,我们如何实现动态加载类呢?Android为我们从ClassLoader派生出了两个类:DexClassLoader和PathClassLoader。其中需要特别说明的是PathClassLoader中一段被注释掉的代码:

[java]  view plain copy
  1. /* --this doesn't work in current version of Dalvik-- 
  2.     if (data != null) { 
  3.         System.out.println("--- Found class " + name 
  4.             + " in zip[" + i + "] '" + mZips[i].getName() + "'"); 
  5.         int dotIndex = name.lastIndexOf('.'); 
  6.         if (dotIndex != -1) { 
  7.             String packageName = name.substring(0, dotIndex); 
  8.             synchronized (this) { 
  9.                 Package packageObj = getPackage(packageName); 
  10.                 if (packageObj == null) { 
  11.                     definePackage(packageName, null, null, 
  12.                             null, null, null, null, null); 
  13.                 } 
  14.             } 
  15.         } 
  16.         return defineClass(name, data, 0, data.length); 
  17.     } 
  18. */  

这从另一方面佐证了defineClass函数在Dalvik虚拟机里确实是被阉割了。而在这两个继承自ClassLoader的类加载器,本质上是重载了ClassLoader的findClass方法。在执行loadClass时,我们可以参看ClassLoader部分源码:

[java]  view plain copy
  1. protected Class<?> loadClass(String className, boolean resolve) throws ClassNotFoundException {  
  2. Class<?> clazz = findLoadedClass(className);  
  3.     if (clazz == null) {  
  4.         try {  
  5.             clazz = parent.loadClass(className, false);  
  6.         } catch (ClassNotFoundException e) {  
  7.             // Don't want to see this.  
  8.         }  
  9.         if (clazz == null) {  
  10.             clazz = findClass(className);  
  11.         }  
  12.     }  
  13.     return clazz;  
  14. }  

因此DexClassLoader和PathClassLoader都属于符合双亲委派模型的类加载器(因为它们没有重载loadClass方法)。也就是说,它们在加载一个类之前,回去检查自己以及自己以上的类加载器是否已经加载了这个类。如果已经加载过了,就会直接将之返回,而不会重复加载。
DexClassLoader和PathClassLoader其实都是通过DexFile这个类来实现类加载的。这里需要顺便提一下的是,Dalvik虚拟机识别的是dex文件,而不是class文件。因此,我们供类加载的文件也只能是dex文件,或者包含有dex文件的.apk或.jar文件。
也许有人想到,既然DexFile可以直接加载类,那么我们为什么还要使用ClassLoader的子类呢?DexFile在加载类时,具体是调用成员方法loadClass或者loadClassBinaryName。其中loadClassBinaryName需要将包含包名的类名中的”.”转换为”/”我们看一下loadClass代码就清楚了:

[java]  view plain copy
  1. public Class loadClass(String name, ClassLoader loader) {  
  2.         String slashName = name.replace('.''/');  
  3.         return loadClassBinaryName(slashName, loader);  
  4. }  

       在这段代码前有一段注释,截取关键一部分就是说: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时类全名需要用”/”替换”.”

你可能感兴趣的:(虚拟机,dalvik)