【移动应用开发技术】浅谈Android Classloader动态加载分析

【移动应用开发技术】浅谈AndroidClassloader动态加载分析

ClassLoader概念我们知道，Java源文件（.java）经过编译器编译之后，会转换成Java字节码(.class)，然而程序是如何加载这些字节码文件到内存中呢？这就用到了ClassLoader，即类加载器。ClassLoader类加载器负责读取Java字节代码，并转换成java.lang.Class类的一个实例。从而只有class文件被载入到了内存之后，才能被其程序所引用。所以ClassLoader就是用来动态加载class文件到内存当中用的。ClassLoader的分类Android中的常用几种类加载器类型继承关系划分可以用一组关系图来表示BootClassLoder通过查看ClassLoader源码我们得知，Android中在默认父加载器传入的情况下，默认父加载器为PathClassLoder，而PathClassLoader的父加载器正是BootClassLoader。BootClassLoader是ClassLoader的内部类，是包内可见，我们无法直接使用，也无法直接动态加载。URLClassLoaderURLClassLoader继承自SecureClassLoader，SecureClassLoader继承自ClassLoader。URLClassLoader的特点就是只能加载jar文件，但是dalvik不能直接识别jar。所以在Android中无法直接使用这个类加载器。BaseDexClassLoaderBaseDexClassLoader直接继承自ClassLoader，下面是其构造函数下面解析下这四个参数PathClassLoader通过源码我们可以知道，PathClassLoader继承于BaseDexClassLoader，并且构造器将optimizedDirectory置为null，也就是没有设置ODEX优化后的存储路径，前文有提到，如果没有设置optimizedDirectory目录，那么默认存储路径就是/data/dalvik-cache。因为这个原因，PathClassLoader被设定成只能加载Android系统类和已安装的android应用类。DexClassLoaderDexClassLoader也是继承于BaseDexClassLoader，支持加载包含classes.dex文件的apk、jar，前文我们提到dalvik不支持直接加载jar文件，那么为什么到了DexClassLoader这里怎么就可以支持加载了呢？原因在于其父类BaseDexClassLoader对于“.jar”，“.apk”，".zip"，".dex"后缀的文件都会进行对应的处理，最终提取成可执行的dex文件。然而URLClassLoader并未对此做类似的处理，因此我们一般会采用DexClassLoader做动态加载。InMemoryDexClassLoaderInMemoryDexClassLoader继承于BaseDexClassLoader，是API26新增的类加载器。dexBuffers数组构造了一个DexPathList，可用于加载内存中的dex。DelegateLastClassLoaderDelegateLastClassLoader是API27新增的类加载器，继承自PathClassLoader。DelegateLastClassLoader实行最后的查找策略。使用DelegateLastClassLoader来加载每个类和资源，使用的是以下顺序：双亲委托机制Android类加载器通过loadClass加载目标类，下面是加载的源码由上述源码，我们可以总结：以上这么做的好处是：一方面防止目标类的重复加载，另外一方面主要考虑安全因素，防止有人重写原生类，比如说java.lang.String这样的数据类型，替换原生的String类，加载到JVM中，造成严重的安全问题。双亲委托机制在Android热修复领域中也有着广泛的应用。每个ClassLoader可以有多个dex文件，每个dex文件是一个Element，多个dex文件组成一个dexElements，类加载器寻找类的时候，会遍历dexElements中的dex文件，再通过dex文件遍历目标类。由于