android动态加载ClassLoader机制

1, 概述

平时做开发有时会导入第三方jar包, 在运行程序时首先需要将apk对应的类加载到内存中, 动态加载是指加载动态库以及jar包等。

Android的Dalvik/ART虚拟机如同标准JAVA的JVM虚拟机一样，在运行程序时首先需要将对应的类加载到内存中。

因此，可以利用这一点，在程序运行时手动加载Class，从而达到代码动态加载可执行文件的目的。

Android的Dalvik/ART虚拟机虽然与标准Java的JVM虚拟机不一样，ClassLoader具体的加载细节不一样，

但是工作机制是类似的，也就是说在Android中同样可以采用类似的动态加载插件的功能。

ClassLoader实例

动态加载的基础是ClassLoader，从名字也可以看出，ClassLoader就是专门用来处理类加载工作的，

所以也叫类加载器，而且一个运行中的APP 不仅只有一个类加载器。

其实，在Android系统启动的时候会创建一个BootClassLoader类型的ClassLoader实例，

用于加载一些系统Framework层级需要的类，的Android应用里也需要用到一些系统的类，

所以APP启动的时候也会把这个Boot类型的ClassLoader传进来。

此外，APP也有自己的类，这些类保存在APK的dex文件里面，所以APP启动的时候，

也会创建一个自己的ClassLoader实例，用于加载自己dex文件中的类。

public class MainActivity extends Activity {    private String TAG = “ClassLoader”;    @Override    protected void onCreate(Bundle savedInstanceState) {        super.onCreate(savedInstanceState);        ClassLoader classLoader = getClassLoader();        if (classLoader != null){            Log.d(TAG, " classLoader: " + classLoader.toString());            while (classLoader.getParent()!=null){                classLoader = classLoader.getParent();                Log.d(TAG, " classLoader: " + classLoader.toString());            }        }    }}

会输出2个ClassLoader,

dalvik.system.PathClassLoader。

java.lang.BootClassLoader。

由此也可以看出，一个运行的Android应用至少有2个ClassLoader。

2, 原理分析

2.1创建ClassLoader实例

动态加载外部的dex文件的时候，也可以使用自己创建的ClassLoader实例来加载dex里面的Class，

不过ClassLoader的创建方式有点特殊，先看看它的构造方法,

ClassLoader(ClassLoader parentLoader, boolean nullAllowed) {        if (parentLoader == null && !nullAllowed) {            throw new NullPointerException("parentLoader == null && !nullAllowed");        }        parent = parentLoader;    }

创建一个ClassLoader实例的时候，需要使用一个现有的ClassLoader实例作为新创建的实例的Parent,

当然，这只是一个假父类。这样一来，一个Android应用，甚至整个Android系统里所有的ClassLoader实例都会被一棵树关联起来，

这也是ClassLoader的 双亲代理模型（Parent-DelegationModel）的特点。

2.2双亲代理模型

JVM中ClassLoader通过defineClass方法加载jar里面的Class，而Android中使用loadClass方法。ClassLoader的loadClass方法如下,

protected Class<?> loadClass(String className, boolean resolve) throws ClassNotFoundException {        Class<?> clazz = findLoadedClass(className);        if (clazz == null) {            ClassNotFoundException suppressed = null;            try {                clazz = parent.loadClass(className, false);            } catch (ClassNotFoundException e) {                suppressed = e;            }            if (clazz == null) {                try {                    clazz = findClass(className);                } catch (ClassNotFoundException e) {                    e.addSuppressed(suppressed);                    throw e;                }            }        }        return clazz;    }

从源码中可以看出，loadClass方法在加载一个类的实例的时候，

1,会先查询当前ClassLoader实例是否加载过此类，有就返回；

2,如果没有。查询Parent是否已经加载过此类，如果已经加载过，就直接返回Parent加载的类；

3,如果继承路线上的ClassLoader都没有加载，才由Child执行类的加载工作；

这样做有个明显的特点，如果一个类被位于树根的ClassLoader加载过，那么在以后整个系统的生命周期内，

这个类永远不会被重新加载。这样有什么作用呢?

首先是共享功能，一些Framework层级的类一旦被顶层的ClassLoader加载过就缓存在内存里面，

以后任何地方用到都不需要重新加载。除此之外还有隔离功能，不同继承路线上的ClassLoader加载的类肯定不是同一个类，

这样的限制避免了用户自己的代码冒充核心类库的类访问核心类库包可见成员的情况。

这也好理解，一些系统层级的类会在系统初始化的时候被加载，比如java.lang.String，

如果在一个应用里面能够简单地用自定义的String类把这个系统的String类给替换掉，那将会有严重的安全问题。

使用ClassLoader一些需要注意的问题

可以通过动态加载获得新的类，从而升级一些代码逻辑，这里有几个问题要注意一下。

1,如果希望通过动态加载的方式，加载一个新版本的dex文件，使用里面的新类替换原有的旧类，

从而修复原有类的BUG，那么必须保证在加载新类的时候，旧类还没有被加载，因为如果已经加载过旧类，那么ClassLoader会一直优先使用旧类。

2,如果旧类总是优先于新类被加载，也可以使用一个与加载旧类的ClassLoader没有树的继承关系的另一个ClassLoader来加载新类，

因为ClassLoader只会检查其Parent有没有加载过当前要加载的类，如果两个ClassLoader没有继承关系，

那么旧类和新类都能被加载。不过这样一来又有另一个问题了，在Java中，只有当两个实例的类名、包名以及加载其的ClassLoader都相同

，才会被认为是同一种类型。上面分别加载的新类和旧类，虽然包名和类名都完全一样，但是由于加载的ClassLoader不同，

所以并不是同一种类型，在实际使用中可能会出现类型不符异常。

同一个Class = 相同的 ClassName + PackageName + ClassLoader

2.3 DexClassLoader 和 PathClassLoader

在Android中，ClassLoader是一个抽象类，实际开发过程中，一般是使用其具体的子类DexClassLoader、PathClassLoader这些类加载器来加载类的，不同之处是：

DexClassLoader可以加载jar/apk/dex，可以从SD卡中加载未安装的apk；

PathClassLoader只能加载系统中已经安装过的apk；

这2个类都继承于BaseDexClassLoader, BaseDexClassLoader继承于ClassLoader。

DexClassLoader的构造方法如下,

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

PathClassLoader有2个构造方法,

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

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

都只是简单的对BaseDexClassLoader做了一下封装，具体的实现还是在父类里。

不过这里也可以看出，PathClassLoader的optimizedDirectory只能是null。

BaseDexClassLoader的构造方法如下,

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

在此,主要关注的是optimizedDirectory参数到底如何处理,主要的流程图如下,

DexPathList的loadDexFile方法如下,

private static DexFile loadDexFile(File file, File optimizedDirectory)            throws IOException {        if (optimizedDirectory == null) {            return new DexFile(file);        } else {            String optimizedPath = optimizedPathFor(file, optimizedDirectory);            return DexFile.loadDex(file.getPath(), optimizedPath, 0);        }    }

optimizedPathFor方法如下,

private static String optimizedPathFor(File path,File optimizedDirectory) {        String fileName = path.getName();        if (!fileName.endsWith(DEX_SUFFIX)) {            int lastDot = fileName.lastIndexOf(".");            if (lastDot < 0) {                fileName += DEX_SUFFIX;            } else {                StringBuilder sb = new StringBuilder(lastDot + 4);                sb.append(fileName, 0, lastDot);                sb.append(DEX_SUFFIX);                fileName = sb.toString();            }        }        File result = new File(optimizedDirectory, fileName);        return result.getPath();    }

看到这里豁然开朗，optimizedDirectory是用来缓存需要加载的dex文件的，并创建一个DexFile对象，如果它为null，

那么会直接使用dex文件原有的路径来创建DexFile对象。

optimizedDirectory必须是一个内部存储路径，无论哪种动态加载，加载的可执行文件一定要存放在内部存储。

DexClassLoader可以指定自己的optimizedDirectory，所以它可以加载外部的dex，

因为这个dex会被复制到内部路径的optimizedDirectory；而PathClassLoader没有optimizedDirectory，

所以它只能加载内部的dex，这些大都是存在系统中已经安装过的apk里面的。

2.4类加载过程

上面还只是创建了类加载器的实例，其中创建了一个DexFile实例，用来保存dex文件，这个实例应该就是用来加载类的。

   Android中，ClassLoader用loadClass方法来加载需要的类,流程图如下,

DexPathList的findClass方法如下,

public Class findClass(String name, List<Throwable> suppressed) {        for (Element element : dexElements) {            DexFile dex = element.dexFile;            if (dex != null) {                Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);                if (clazz != null) {                    return clazz;                }            }        }        if (dexElementsSuppressedExceptions != null) {            suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));        }        return null;    }

遍历了之前所有的DexFile实例，其实也就是遍历了所有加载过的dex文件，

再调用loadClassBinaryName方法逐个加载类,最后调用Native方法defineClassNative加载类。

2.5自定义ClassLoader

平时进行动态加载开发的时候，使用DexClassLoader就够了。但也可以创建自己的类去继承ClassLoader，

需要注意的是loadClass方法并不是final类型的，所以可以重载loadClass方法并改写类的加载逻辑。

通过前面分析，ClassLoader双亲代理的实现很大一部分就是在loadClass方法里，可以通过重写loadClass方法避开双亲代理的框架，

这样一来就可以在重新加载已经加载过的类，也可以在加载类的时候注入一些代码。这是一种Hack的开发方式，

采用这种开发方式的程序稳定性可能比较差，但是却可以实现一些“黑科技”的功能。

Android程序比起一般Java程序在使用动态加载时容易出错地方,使用ClassLoader动态加载一个外部的类是非常容易的事情，

所以很容易就能实现动态加载新的可执行代码的功能，但是比起一般的Java程序，在Android程序中使用动态加载主要有两个麻烦的问题：

Android中许多组件类（如Activity、Service等）是需要在Manifest文件里面注册后才能工作的（系统会检查该组件有没有注册），

所以即使动态加载了一个新的组件类进来，没有注册的话还是无法工作；Res资源是Android开发中经常用到的，

而Android是把这些资源用对应的R.id注册好，运行时通过这些ID从Resource实例中获取对应的资源。

如果是运行时动态加载进来的新类，那类里面用到R.id的地方将会抛出找不到资源或者用错资源的异常，

因为新类的资源ID根本和现有的Resource实例中保存的资源ID对不上；

说到底，抛开虚拟机的差别不说，一个Android程序和标准的Java程序最大的区别就在于他们的上下文环境（Context）不同。

Android中，这个环境可以给程序提供组件需要用到的功能，也可以提供一些主题、Res等资源，

其实上面说到的两个问题都可以统一说是这个环境的问题，而现在的各种Android动态加载框架中，

核心要解决的东西也正是“如何给外部的新类提供上下文环境”的问题。