Android类加载基础之ClassLoder

一下文章摘录自Android插件化学习之路(二)之ClassLoader完全解析并添加了一些属于自己的理解

介绍

Android的Dalvik/ART虚拟机如同标准的JAVA的JVM虚拟机一样,在程序运行时首先需要将对应的类加载到内存中。因此,我们可以利用这一点,在程序运行时手动加载Class,从而达到动态加载可执行文件的目的。Android的Dalvik/ART虚拟机虽然与标准的JVM虚拟机不一样,ClassLoader棘突的加载细节不一样,但是工作机制都是类似的,也就是说在Android中同样可以采用类似的动态加载插件的功能,只是在Android应用中动态加载一个插件的工作要比Eclipse加载一个插件复杂许多。

java默认提供ClassLoader实例

1.BootStrap ClassLoader:称为启动类加载器,是Java类加载层次中最顶层的类加载器,负责加载JDK中的核心类库,如:rt.jar、resources.jar、charsets.jar等,可通过如下程序获得该类加载器从哪些地方加载了相关的jar或class文件。
2.Extension ClassLoader:称为扩展类加载器,负责加载Java的扩展类库,默认加载JAVA_HOME/jre/lib/ext/目下的所有jar
3.App ClassLoader:称为系统类加载器,负责加载应用程序classpath目录下的所有jar和class文件

注意: 除了Java默认提供的三个ClassLoader之外,用户还可以根据需要定义自已的ClassLoader,而这些自定义的ClassLoader都必须继承自java.lang.ClassLoader类,也包括Java提供的另外二个ClassLoader(Extension ClassLoader和App ClassLoader)在内,但是Bootstrap ClassLoader不继承自ClassLoader,因为它不是一个普通的Java类,底层由C++编写,已嵌入到了JVM内核当中,当JVM启动后,Bootstrap ClassLoader也随着启动,负责加载完核心类库后,并构造Extension ClassLoader和App ClassLoader类加载器

Android平台下的ClassLoader实例

我们先来看下在Android SDK 中ClassLoader的继承关系图:


image.png

其实跟我们热修复和插件化相关的是我圈出来的三个类:BaseDexClassLoader、PathClassLoader和DexClassLoader。
动态加载的基础是ClassLoader,它就是专门用来处理类加载工作的,所以它也叫类加载器,而且一个运行的APP不仅仅只有一个类加载器。
当我们在Activity的onCreate中调用以下代码时:

 ClassLoader classLoader = getClassLoader();
        if (classLoader != null) {
            Log.v(TAG, "MainActivity classLoader===>" + classLoader.toString());
            while (classLoader.getParent() != null) {
                classLoader = classLoader.getParent();
                Log.v(TAG, "MainActivity classLoader===>" + classLoader.toString());
            }
        }

会打印出以下日志


image.png

由此我们可以得出以下结论:一般一个app最少都会有两个ClassLoader,即PathClassLoader和BootClassLoader。下面就来介绍下两个ClassLoader:

BootClassLoader:Android系统启动时会使用BootClassLoader来预加载常用类,与Java中的BootClassLoader不同,它并不是由C/C++代码实现,而是由Java实现的。BootClassLoader是ClassLoader的内部类,并继承自ClassLoader。BootClassLoader是一个单例类,需要注意的是BootClassLoader的访问修饰符是默认的,只有在同一个包中才可以访问,因此我们在应用程序中是无法直接调用的
PathClassLoader:Android系统使用PathClassLoader来加载系统类和应用程序的类,如果是加载非系统应用程序类,则会加载data/app/目录下的dex文件以及包含dex的apk文件或jar文件,不管是加载那种文件,最终都是要加载dex文件,在这里为了方便理解,我们将dex文件以及包含dex的apk文件或jar文件统称为dex相关文件。PathClassLoader不建议开发直接使用。PathClassLoader继承自BaseDexClassLoader,很明显PathClassLoader的方法实现都在BaseDexClassLoader中。从PathClassLoader的构造方法也可以看出它遵循了双亲委托模式。

要了解Java和Android的ClassLoader的区别请参考:
Android解析ClassLoader(二)Android中的ClassLoader

创建我们自己的ClassLoader

如果我们要加载外部的dex文件,往往都会创建我们自己的ClassLoader实例来来加载dex中的Class,首先我们来看下ClassLoader的构造函数

private ClassLoader(Void unused, ClassLoader parent) {
        this.parent = parent;
    }

我们看到我们在创建自己的ClassLoader对象的时候会强制让我们传入一个现有的ClassLoader实例作为新创建的实例的Parent。这样一来,一个Android应用,甚至整个Android系统里所有的ClassLoader实例都会被一颗树所关联起来,这也是ClassLoader双亲委托得到特点。

在JVM中ClassLoader通过defineClass方法加载jar里面的Class,而在Android中这个方法被废弃了。


image.png

取而代之的方法是loadClass方法

protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
            // First, check if the class has already been loaded
            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) {
                    // If still not found, then invoke findClass in order
                    // to find the class.
                    c = findClass(name);
                }
            }
            return c;
    }

通过上面的代码我们可以发现类的加载过程如下:

1.查询当前实例是否已经被加载过,如果已经被加载过则直接返回
2.如果没有加载过,则查询parent是否已经加载过,如果已经加载过则直接返回
3.如果继承路上的ClassLoader都没有加载过,才由当前的ClassLoader执行加载工作

这样就做到了双亲委托的功能,加入一个类已经被父ClassLoader加载过,那么子ClassLoader就不会再去重新加载了。

如果你希望通过动态加载的方式,加载一个外部的dex文件,使用里面的新类去替换旧类,从而达到bug的修复,那么你必须保证新类在旧类之前被加载,否则新类则永远不会被加载了。
如果我们的旧类始终在新类之前被加载,我们也可以使用一个与加载旧类的ClassLoader没有树继承关系的另一个ClassLoader来加载新类,不过这里又会出现另一个问题,在Java中,当两个实例的类名、包名、以及其加载器都相同时,才会被认为是同一种类型。所以使用行的ClassLoader加载的新类与旧类并不是同一种类型,在实际使用过程中,会出现类型不匹配的问题。

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

DexClassLoader与PathClassLoader

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

class PathClassLoader extends BaseDexClassLoader {
    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做了一层封装,具体的实现还是交给了父类。两者在调用父类构造方法时只是入参不同。我们来看下这个optimizedDirectory具体干什么的?

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

public DexPathList(ClassLoader definingContext, String dexPath, String libraryPath, File optimizedDirectory) {
……
    this.dexElements = makeDexElements(splitDexPath(dexPath), optimizedDirectory);
}

private static Element[] makeDexElements(ArrayList<File> files, File optimizedDirectory) {
    ArrayList<Element> elements = new ArrayList<Element>();
    for (File file : files) {
        ZipFile zip = null;
        DexFile dex = null;
        String name = file.getName();
        if (name.endsWith(DEX_SUFFIX)) {
            dex = loadDexFile(file, optimizedDirectory);
        } else if (name.endsWith(APK_SUFFIX) || name.endsWith(JAR_SUFFIX) || name.endsWith(ZIP_SUFFIX)) {
            zip = new ZipFile(file);
        }
        ……
        if ((zip != null) || (dex != null)) {
            elements.add(new Element(file, zip, dex));
        }
    } return elements.toArray(new Element[elements.size()]);
}

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);
    }
} 

/**
 * Converts a dex/jar file path and an output directory to an      * output file path for an associated optimized dex file.
 */
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里面的。

类的加载过程

上面只是创建了类加载器的实例,然后内部创建了一个DexFile实例,用来保存dex文件,我们猜想这个实例就是用来加载类的。
Android中,ClassLoader用loadClass方法来加载我们需要的类。

 public Class<?> loadClass(String className) throws ClassNotFoundException {
        return loadClass(className, false);
    }

    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方法调用了findClass方法,而BaseDexClassLoader重载了这个方法,得到BaseDexClassLoader看看

@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
    Class clazz = pathList.findClass(name);
    if (clazz == null) {
        throw new ClassNotFoundException(name);
    }
    return clazz;
}

结果还是调用了DexPathList的findClass

public Class findClass(String name) {
    for (Element element : dexElements) {
        DexFile dex = element.dexFile;
        if (dex != null) {
            Class clazz = dex.loadClassBinaryName(name, definingContext);
            if (clazz != null) {
                return clazz;
            }
        }
    }
    return null;
}

这里遍历了之前所有的DexFile实例,其实也就是遍历了所有加载过的dex文件,再调用loadClassBinaryName方法一个个尝试能不能加载想要的类,真是简单粗暴

public Class loadClassBinaryName(String name, ClassLoader loader) {
        return defineClass(name, loader, mCookie);
    }

    private native static Class defineClass(String name, ClassLoader loader, int cookie);

看到这里想必大家都明白了,loadClassBinaryName中调用了Native方法defineClass加载类。
至此,ClassLoader的创建和加载类的过程的完成了。有趣的是,标准JVM中,ClassLoader是用defineClass加载类的,而Android中defineClass被弃用了,改用了loadClass方法,而且加载类的过程也挪到了DexFile中,在DexFile中加载类的具体方法也叫defineClass,不知道是Google故意写成这样的还是巧合.

Android程序比起使用动态加载时麻烦在哪里

通过上面的分析,我们知道使用ClassLoader动态加载一个外部的类是非常容易的事情,所以很容易就能实现动态加载新的可执行代码的功能,但是比起一般的Java程序,在Android程序中使用动态加载主要有两个麻烦的问题:

  1. Android中许多组件类(如Activity、Service等)是需要在Manifest文件里面注册后才能工作的(系统会检查该组件有没有注册),所以即使动态加载了一个新的组件类进来,没有注册的话还是无法工作;

  2. Res资源是Android开发中经常用到的,而Android是把这些资源用对应的R.id注册好,运行时通过这些ID从Resource实例中获取对应的资源。如果是运行时动态加载进来的新类,那类里面用到R.id的地方将会抛出找不到资源或者用错资源的异常,因为新类的资源ID根本和现有的Resource实例中保存的资源ID对不上;

推荐阅读更多精彩内容