Android热修复技术初探（二）：ClassLoader

在Java所编写的应用程序里，实质上都是ClassLoader来负责加载类的。有隐式加载类：如new一个实例对象，会自动触发ClassLoader来加载该类；有显示加载类：如直接调用ClassLoader的loadClass()方法来加载。实现热修复的关键技术之一就是ClassLoader，我们通过自定义ClassLoader来动态加载类，以实现热修复的目的。JVM的ClassLoader采用的是双亲委派模型，从上往下有BootstrapClassLoader、ExtClassLoader、AppClassLoader，它们都有不同的职责。Android平台同样也采用了双亲委派模型，但是Android运行的是dex文件，JVM运行的是class文件，所以Android平台没有采用JVM那一套机制，而是自己重新实现了自己特有的ClassLoader。我们必须先了解清楚Android平台的ClassLoader是怎么一回事，才能着手进行热修复的实践。

1. Android的ClassLoader层次结构

Android ClassLoader类层次结构.png

从图中可以看到，Android中实际用到的ClassLoader是PathClassLoader和DexClassLoader，它们都继承自BaseDexClassLoader，而BaseDexClassLoader继承自java.lang.ClassLoader。注意这里它们都是父子继承关系，以前我们讲到ClassLoader的双亲委派模型时，是通过组合的方式来实现的。

我们来看个具体的例子，打印出不同类的ClassLoader是什么：

String str = new String("abc");
System.out.println(str.getClass().getClassLoader());
ClassLoader classLoader = MainActivity.this.getClassLoader();
do {
    System.out.println(classLoader);
    classLoader = classLoader.getParent();
} while (classLoader != null);
System.out.println(Button.class.getClassLoader());

截取部分执行结果如下：

java.lang.BootClassLoader@32a45faa
dalvik.system.PathClassLoader......
java.lang.BootClassLoader@32a45faa
java.lang.BootClassLoader@32a45faa

可以看到String类是由一个名为BootClassLoader的启动类加载的，而由我们自己编写的类MainActivity则是由PathClassLoader来加载的，PathClassLoader的双亲直接为启动类BootClassLoader，Button类也是由BootClassLoader来加载的。

Android中几个主要的ClassLoader及其作用为：

• BootClassLoader：顶层的启动类加载器，Android SDK里的类都是直接由它加载的；
• PathClassLoader：Android系统默认的类加载器，只能加载系统中已经安装过的apk；
• DexClassLoader：可以加载任何路径的apk/dex/jar，所以要实现Android的动态加载，一般采用DexClassLoader来实现；

2. PathClassLoader

PathClassLoader有两个构造函数：

public PathClassLoader(String dexPath, ClassLoader parent) 

public PathClassLoader(String dexPath, String librarySearchPath, ClassLoader parent)

其几个参数的含义为：
dexPath：dex/apk等文件路径列表，多个文件用":"分隔
librarySearchPath：lib库的搜索路径，多个以":"分隔
parent：父类加载器

前面的例子中，我们看看控制台里打印出的完整的PathClassLoader信息：

dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.bwton.hjydemo-2/base.apk"],nativeLibraryDirectories=[/vendor/lib, /system/lib]]]

从中可以看到，dexPath值为"/data/app/com.bwton.hjydemo-2/base.apk"，这是我们的apk实际安装路径，librarySearchPath的值为"/vendor/lib, /system/lib"。

通常情况下，调用Context.getClassLoader()方法获取到的就是PathClassLoader。

3. DexClassLoader

DexClassLoader的构造函数为：

public DexClassLoader(String dexPath, String optimizedDirectory, String librarySearchPath, ClassLoader parent)

与PathClassLoader相比，DexClassLoader的构造函数只多了一个参数optimizedDirectory。
optimizedDirectory：经过优化后的dex文件(odex)输出目录

4. PathClassLoader与DexClassLoader的区别

从网上找了下这2个类的源码，大概如下：

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

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

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

从源码中可以看到，这两个类及其相似，两者都是继承自BaseDexClassLoader，唯一的差别是DexClassLoader多了一个参数optimizedDirectory，而PathClassLoader里该值必定为null。由此我们可以判断，必定是这个optimizedDirectory搞的鬼，所以还得看看BaseDexClassLoader里的源码。

先看看构造函数：

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

发现主要是生成了一个DexPathList对象，其他什么都没做，我们再来看看DexPathList是个什么东西：

public DexPathList(ClassLoader definingContext, String dexPath,
            String libraryPath, File optimizedDirectory) {
    //检查classLoader不能为空
    if (definingContext == null) {
        throw new NullPointerException("definingContext == null");
    }
   
    //检查jar/apk等文件路径不能为空
    if (dexPath == null) {
        throw new NullPointerException("dexPath == null");
    }

    //判断dex优化后的文件存储路径是否为空，前面介绍到PathClassLoader的optimizedDirectory为null，
    //而DexClassLoader多了这个参数，所以它俩的差别就是在这里体现的
    if (optimizedDirectory != null) {
        //optimizedDirectory目录必须事先创建好
        if (!optimizedDirectory.exists())  {
            throw new IllegalArgumentException(
                    "optimizedDirectory doesn't exist: "
                    + optimizedDirectory);
        }
        //optimizedDirectory目录必须能读写
        if (!(optimizedDirectory.canRead()
                        && optimizedDirectory.canWrite())) {
            throw new IllegalArgumentException(
                    "optimizedDirectory not readable/writable: "
                    + optimizedDirectory);
        }
    }

    this.definingContext = definingContext;
    ArrayList<IOException> suppressedExceptions = new ArrayList<IOException>();
    //根据传入的jar/apk文件路径，创建dex element
    this.dexElements = makeDexElements(splitDexPath(dexPath), optimizedDirectory,
                                       suppressedExceptions);
    if (suppressedExceptions.size() > 0) {
        this.dexElementsSuppressedExceptions =
            suppressedExceptions.toArray(new IOException[suppressedExceptions.size()]);
    } else {
        dexElementsSuppressedExceptions = null;
    }
    this.nativeLibraryDirectories = splitLibraryPath(libraryPath);
}

里面的关键代码在makeDexElements，字面意思是根据jar/apk路径创建出dex element，我们继续看该方法：

//files表示传入的所有jar/apk文件列表
private static Element[] makeDexElements(ArrayList<File> files, File optimizedDirectory,
                                             ArrayList<IOException> suppressedExceptions) {
    ArrayList<Element> elements = new ArrayList<Element>();
    //遍历所有的文件，然后逐一生成DexFile
    for (File file : files) {
        File zip = null;
        DexFile dex = null;
        String name = file.getName();
        
        //如果是以.dex结尾的dex文件，可以直接加载
        if (name.endsWith(DEX_SUFFIX)) {
            // Raw dex file (not inside a zip/jar).
            try {
                dex = loadDexFile(file, optimizedDirectory);
            } catch (IOException ex) {
                System.logE("Unable to load dex file: " + file, ex);
            }
        } else if (name.endsWith(APK_SUFFIX) || name.endsWith(JAR_SUFFIX)
                || name.endsWith(ZIP_SUFFIX)) {
            //如果是.apk、.jar、.zip文件，则采用loadDexFile方法加载
            zip = file;

            try {
                dex = loadDexFile(file, optimizedDirectory);
            } catch (IOException suppressed) {
                /*
                 * IOException might get thrown "legitimately" by the DexFile constructor if the
                 * zip file turns out to be resource-only (that is, no classes.dex file in it).
                 * Let dex == null and hang on to the exception to add to the tea-leaves for
                 * when findClass returns null.
                 */
                suppressedExceptions.add(suppressed);
            }
        } else if (file.isDirectory()) {
            // We support directories for looking up resources.
            // This is only useful for running libcore tests.
            //如果是个文件目录
            elements.add(new Element(file, true, null, null));
        } else {
            System.logW("Unknown file type for: " + file);
        }

        if ((zip != null) || (dex != null)) {
            elements.add(new Element(file, false, zip, dex));
        }
    }

    return elements.toArray(new Element[elements.size()]);
}

从代码里可以看到，支持加载的文件类型有：.dex、.jar、.zip、.apk共4种，其他文件类型都不支持，最终进行加载动作的都是loadDexFile()方法，所以不管是jar包也好，apk包也罢，其内部加载时都会返回DexFile，再继续跟进去看看该方法实现：

private static DexFile loadDexFile(File file, File optimizedDirectory)
            throws IOException {
    if (optimizedDirectory == null) {
        //如果dex优化后的存储路径为空，则直接创建DexFile
        //PathClassLoader加载的时候，就会执行到这里
        return new DexFile(file);
    } else {
        //DexClassLoader加载的时候，会执行到这里
        //在dex优化文件存储路径上，创建一个同名的.dex文件
        String optimizedPath = optimizedPathFor(file, optimizedDirectory);
        return DexFile.loadDex(file.getPath(), optimizedPath, 0);
    }
}

从这里可以看出，根据optimizedDirectory的不同，生成的DexFile对象也不同。实际的load操作是在DexFile.loadDex()方法里执行的，我们继续跟下去：

static public DexFile loadDex(String sourcePathName, String outputPathName,
        int flags) throws IOException {
        //这里直接返回一个DexFile对象
        return new DexFile(sourcePathName, outputPathName, flags);
    }

再来看看DexFile的构造函数：

/**
 * Opens a DEX file from a given filename. This will usually be a ZIP/JAR
 * file with a "classes.dex" inside.
 *
 * The VM will generate the name of the corresponding file in
 * /data/dalvik-cache and open it, possibly creating or updating
 * it first if system permissions allow.  Don't pass in the name of
 * a file in /data/dalvik-cache, as the named file is expected to be
 * in its original (pre-dexopt) state.
 *
 * @param fileName
 *            the filename of the DEX file
 *
 * @throws IOException
 *             if an I/O error occurs, such as the file not being found or
 *             access rights missing for opening it
 */
public DexFile(String fileName) throws IOException {
    mCookie = openDexFile(fileName, null, 0);
    mFileName = fileName;
    guard.open("close");
}

/**
 * Opens a DEX file from a given filename, using a specified file
 * to hold the optimized data.
 *
 * @param sourceName 
 *  Jar or APK file with "classes.dex".
 * @param outputName dex数据优化后的存储目录
 *  File that will hold the optimized form of the DEX data.
 * @param flags
 *  Enable optional features.
 */
private DexFile(String sourceName, String outputName, int flags) throws IOException {
    if (outputName != null) {
        try {
            String parent = new File(outputName).getParent();
            if (Libcore.os.getuid() != Libcore.os.stat(parent).st_uid) {
                throw new IllegalArgumentException("Optimized data directory " + parent
                        + " is not owned by the current user. Shared storage cannot protect"
                        + " your application from code injection attacks.");
            }
        } catch (ErrnoException ignored) {
            // assume we'll fail with a more contextual error later
        }
    }

    mCookie = openDexFile(sourceName, outputName, flags);
    mFileName = sourceName;
    guard.open("close");
    //System.out.println("DEX FILE cookie is " + mCookie);
}

最终的实现逻辑又是在openDexFile()方法里来实现的，该方法里实际是调用了native方法来实现的，native里的方法这里不再跟踪了。

Android在载入dex文件时，首先会对原dex文件进行优化，然后将优化后的dex数据(odex文件)存储到某个缓存文件里，最后再加载缓存里的dex文件，如果发现已经优化过，则直接读取缓存里的dex文件。

从前面的代码中可以分析出，PathClassLoader是通过new DexFile(file)来载入dex文件的，而应用程序在安装阶段已经生成了形如/data/dalvik-cache/xxx@classes.dex的dex优化文件，PahtClassLoader在载入dex时不需要先优化dex，而是会直接读取/data/dalvik-cache目录下的缓存dex文件，所以说PathClassLoader只能加载系统已经安装过的应用程序。但这种说法并不准确，因为只是PathClassLoader默认的优化dex缓存路径固定为/data/dalvik-cache而已，而这个目录通常只是在安装应用时系统来操作，但如果我们拥有root权限，实际上PathClassLoader应该也是能加载其他路径的dex文件的。

DexClassLoader来加载dex时，会先优化原来的dex文件，然后将优化后的dex文件缓存在optimizedDirectory目录，优化这个操作通常只执行一次，后续会直接加载缓存目录的dex文件了。

5. 小结

PathClassLoader与DexClassLoader唯一的差别就是，后者能够指定dex优化文件的缓存目录，而前者的缓存目录固定为/data/dalvik-cache，通常情况下应用是没有该目录的读写权限的，只有应用安装时会在该目录下生成缓存dex文件，所以我们一般采用DexClassLoader来实现动态加载。