亲宝软件园·资讯

展开

Android Classloader动态加载 浅谈Android Classloader动态加载分析

JohnsonZZZ 人气:0
想了解浅谈Android Classloader动态加载分析的相关内容吗,JohnsonZZZ在本文为您仔细讲解Android Classloader动态加载的相关知识和一些Code实例,欢迎阅读和指正,我们先划重点:Android,Classloader动态加载,Android,Classloader,下面大家一起来学习吧。

ClassLoader概念

我们知道,Java源文件(.java)经过编译器编译之后,会转换成Java字节码(.class),然而程序是如何加载这些字节码文件到内存中呢?这就用到了ClassLoader,即类加载器。ClassLoader类加载器负责读取 Java 字节代码,并转换成 java.lang.Class类的一个实例。从而只有class文件被载入到了内存之后,才能被其程序所引用。所以ClassLoader就是用来动态加载class文件到内存当中用的。

ClassLoader的分类

Android中的常用几种类加载器类型继承关系划分可以用一组关系图来表示

BootClassLoder

通过查看ClassLoader源码 我们得知,Android中在默认父加载器传入的情况下,默认父加载器为PathClassLoder,而PathClassLoader的父加载器正是BootClassLoader。BootClassLoader是ClassLoader的内部类,是包内可见,我们无法直接使用,也无法直接动态加载。

 /**
   * Encapsulates the set of parallel capable loader types.
   */
  private static ClassLoader createSystemClassLoader() {
    String classPath = System.getProperty("java.class.path", ".");
    String librarySearchPath = System.getProperty("java.library.path", "");

    ...省略部分代码

    //默认父构造器为PathClassLoder
    return new PathClassLoader(classPath, librarySearchPath, BootClassLoader.getInstance());
  }

URLClassLoader

URLClassLoader继承自SecureClassLoader,SecureClassLoader继承自ClassLoader。URLClassLoader的特点就是只能加载jar文件,但是dalvik不能直接识别jar。所以在Android中无法直接使用这个类加载器。

BaseDexClassLoader

BaseDexClassLoader直接继承自ClassLoader,下面是其构造函数

public BaseDexClassLoader(String dexPath, File optimizedDirectory, String librarySearchPath, ClassLoader parent) {
    super(parent);
    this.pathList = new DexPathList(this, dexPath, librarySearchPath, null);
    ....
  }

下面解析下这四个参数

  1. dexPath:指目标类所在的apk、dex或者jar文件的路径(包括SD卡),然后加载器将从该路径中寻找到指定的目标类。当然了,这个路径可以是多个路径,这样可以寻找到多个目标类,多路径之间需要使用特定的分隔符,分隔符可以使用System.getProperty("path.separtor")获取。
  2. optimizedDirectory:由于dex文件被包含在apk或者jar文件中,需要先解压出来,而这个参数 就代表了被解压的路径。而且apk文件其实也是一个压缩包,解压的过程其实也是一个ODEX优化的过程,那么何为ODEX优化呢?其实就是把包里面的可执行程序提取出来变成ODEX文件,存放到optimizedDirectory目录下,因为提取出来的原因,应用第一次进行启动的时候,直接使用ODEX文件 启动速度自然是比解压再启动速度是要快的。为什么是应用第一次启动呢?因为dex版本只有第一次启动会解压执行程序到/data/dalvik-cache(针对PathClassLoader),或者optimizedDirectory文件目录下(针对DexClassLoader),之后就可以直接读取目录下的dex文件了。
  3. librarySearchPath:指的是目标类所使用的c、c++库存放的路径
  4. parent:是指该加载器的父加载器,一般为当前执行类的加载器。

PathClassLoader

public PathClassLoader(String dexPath, ClassLoader parent) { 
    super(dexPath, null, null, parent); 
} 

 public PathClassLoader(String dexPath, String librarySearchPath, ClassLoader parent) {
    super(dexPath, null, librarySearchPath, parent);
   ...
 }

通过源码我们可以知道,PathClassLoader继承于BaseDexClassLoader,并且构造器将optimizedDirectory置为null,也就是没有设置ODEX优化后的存储路径,前文有提到,如果没有设置optimizedDirectory目录,那么默认存储路径就是/data/dalvik-cache。因为这个原因,PathClassLoader被设定成只能加载Android系统类和已安装的android应用类。

DexClassLoader

public DexClassLoader(String dexPath, String optimizedDirectory, String librarySearchPath, ClassLoader parent) {
    super(dexPath, new File(optimizedDirectory), librarySearchPath, parent);
   ...
  }

DexClassLoader也是继承于BaseDexClassLoader,支持加载包含classes.dex文件的apk、jar,前文我们提到dalvik不支持直接加载jar文件,那么为什么到了DexClassLoader这里怎么就可以支持加载了呢?原因在于其父类BaseDexClassLoader对于“.jar”,“.apk”,".zip",".dex"后缀的文件都会进行对应的处理,最终提取成可执行的dex文件。然而URLClassLoader并未对此做类似的处理,因此我们一般会采用DexClassLoader做动态加载。

InMemoryDexClassLoader

 public InMemoryDexClassLoader(ByteBuffer[] dexBuffers, ClassLoader parent) {
    super(dexBuffers, parent);
  }
  
  public InMemoryDexClassLoader(ByteBuffer dexBuffer, ClassLoader parent) {
    this(new ByteBuffer[] { dexBuffer }, parent);
  }

InMemoryDexClassLoader继承于BaseDexClassLoader,是API26新增的类加载器。dexBuffers数组构造了一个DexPathList,可用于加载内存中的dex。

DelegateLastClassLoader

public DelegateLastClassLoader(String dexPath, ClassLoader parent) {
    super(dexPath, parent);
  }

DelegateLastClassLoader是API27新增的类加载器,继承自 PathClassLoader。DelegateLastClassLoader实行最后的查找策略。使用DelegateLastClassLoader来加载每个类和资源,使用的是以下顺序:

  1. 判断是否已经加载过该类
  2. 搜索此类的类加载器是否已经加载过该类
  3. 搜索与此类加载器相关联的dexPath文件列表,并委托给父加载器。

双亲委托机制

Android类加载器通过loadClass加载目标类,下面是加载的源码

 protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
  {
      // 首先检查当前目标类是否已经被加载过,有则直接返回
      Class<?> c = findLoadedClass(name);
      if (c == null) {
        try {
          if (parent != null) {
            //如果有父类加载器,优先使用父类加载器寻找目标类
            c = parent.loadClass(name, false);
          } else {
             //其次,如果有辅助类加载器,使用辅助类加载器寻找目标类
            c = findBootstrapClassOrNull(name);
          }
        } catch (ClassNotFoundException e) {
          // ClassNotFoundException thrown if class not found
          // from the non-null parent class loader
        }

        if (c == null) {
          //如果仍未找到,则通过寻找子ClassLoader的目标类(如果子ClassLoader重写了findClass)
          c = findClass(name);
        }
      }
      return c;
  }

由上述源码,我们可以总结:

  1. 当前类加载器首先检查目标类是否已经被加载过,有则直接返回
  2. 当前类加载器会先委托父类加载器加载目标类,如果未设置父加载器,则检查辅助加载器是否支持查询加载目标类
  3. 只有上述加载器找不到目标类的时候,才会调用当前类加载器(Child) 查询路径寻找目标类。

以上这么做的好处是:一方面防止目标类的重复加载,另外一方面 主要考虑安全因素,防止有人重写原生类,比如说java.lang.String这样的数据类型,替换原生的String类,加载到JVM中,造成严重的安全问题。

双亲委托机制 在Android热修复领域中也有着广泛的应用。每个ClassLoader可以有多个dex文件,每个dex文件是一个Element,多个dex文件组成一个dexElements,类加载器寻找类的时候,会遍历dexElements中的dex文件,再通过dex文件遍历目标类。由于双亲委托机制的存在,寻找到目标类后就直接返回,不再寻找其他dex文件下该目标类,热修复的原理就是hook住ClassLoader,使其先加载修复后的目标类,而存在的BUG的目标类不会被加载。

加载全部内容

相关教程
猜你喜欢
用户评论