class加载到JVM里头运行,其中用到的技术不外乎加

作者:美狮美高梅官方网站

安卓插件化越来越流行,其中用到的技术不外乎加载外部的资源和加载外部的代码,关于加载外部资源我之前写过一篇文章《安卓皮肤包机制的原理》,感兴趣的同学可以去看一下。

Java ClassLoader简介

java 开发中编写的都是.java的对象文件,当我们需要运行当前的项目的时候,当前项目会被编译,编译后需要用到的.java文件就会被被编译成.class文件。但是Java程序 .class文件并不是本地可执行的,当运行Java程序时,首先运行JVM(Java虚拟机),然后再把Java class加载到JVM里头运行,负责加载Java class的这部分就叫做ClassLoader

JVM本身包含了一个ClassLoader称为Bootstrap ClassLoader,和JVM一样,Bootstra pClassLoader是用C++语言实现的。另外JVM还会提供了ExtClassLoader和AppClassLoader,它们都是用Java语言编写的,由BootstrapClassLoader加载。

JDK提供的三个ClassLoader,根据层级从高到低为:

  • 美狮美高梅官方网站 ,BootstrapClassLoader ,主要加载JVM自身工作需要的类。
  • ExtClassLoaderr,主要加载%JAVA_HOME%libext目录下的库类。
  • AppClassLoader,主要加载Classpath指定的库类,一般情况下这是程序中的默认类加载器,也是ClassLoader.getSystemClassLoader() 的返回值。(这里的Classpath默认指的是环境变量中配置的Classpath,但是可以在执行Java命令的时候使用-cp 参数来修改当前程序使用的Classpath)

新美高梅网站 1

ClassLoader的继承关系

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

加载外部代码的作用在于热更新。程序主体定义接口,具体实现放在外部。只需要替换外部代码,就能修复bug甚至是更新功能。相比传统的ota手段更加省流量,用户体验也更加的好,毕竟有很多的用户是不喜欢更新的。

Android ClassLoader简介

新美高梅网站 ,android应用程序,本质上使用的是java开发,使用标准的java编译器编译出Class文件,和普通的java开发不同的地方是把class文件再重新打包成dex类型的文件。Android虚拟机运行的dex字节码,一种对class文件优化的产物,传统Class文件是一个Java源码文件会生成一个.class文件,而Android是把所有Class文件进行合并,优化,然后生成一个最终的class.dex。
加载这样特殊的.dex文件就需要特殊的类装载器,所以android中提供了DexClassLoader类。

Android系统中类加载器有:

  • BootClassLoader,Android系统启动时会使用BootClassLoader来预加载常用类,它是由java实现的。
  • PathClassLoader,Android系统使用PathClassLoader来加载系统类和应用程序的类
  • DexClassLoader,可以加载dex文件以及包含dex的apk文件或jar文件

新美高梅网站 2

Android ClassLoad继承关系

PathClassLoader和DexClassLoader继承自BaseDexClassLoader,并且它们具体方法实现都在BaseDexClassLoader中。
Android系统使用PathClassLoader来加载系统类和应用程序的类,如果是加载非系统应用程序类,则会加载data/app/目录下的dex文件以及包含dex的apk文件或jar文件。PathClassLoader不建议开发直接使用。
libcore/dalvik/src/main/java/dalvik/system/PathClassLoader.java

public class PathClassLoader extends BaseDexClassLoader {
//*   dexPath:dex文件以及包含dex的apk文件或jar文件的路径集合,多个路径用文件分隔符分隔,默认文件分隔符为‘:’。
//*   librarySearchPath:包含 C/C++ 库的路径集合,多个路径用文件分隔符分隔分割,可以为null。
//*   parent:ClassLoader的parent。
    public PathClassLoader(String dexPath, ClassLoader parent) {
        super(dexPath, null, null, parent);
    }
    public PathClassLoader(String dexPath, String librarySearchPath, ClassLoader parent) {
        super(dexPath, null, librarySearchPath, parent);
    }
}

DexClassLoader可以加载dex文件以及包含dex的apk文件或jar文件,也支持从SD卡进行加载,这也就意味着DexClassLoader可以在应用未安装的情况下加载dex相关文件。因此,它是热修复和插件化技术的基础。来查看它的代码,如下所示。
libcore/dalvik/src/main/java/dalvik/system/DexClassLoader.java

public class DexClassLoader extends BaseDexClassLoader {
//多一个optimizedDirectory参数
    public DexClassLoader(String dexPath, String optimizedDirectory,
            String librarySearchPath, ClassLoader parent) {
        super(dexPath, new File(optimizedDirectory), librarySearchPath, parent);
        }
}

DexClassLoader构造方法的参数要比PathClassLoader多一个optimizedDirectory参数,参数optimizedDirectory代表什么呢?我们知道应用程序第一次被加载的时候,为了提高以后的启动速度和执行效率,Android系统会对dex相关文件做一定程度的优化,并生成一个ODEX文件,此后再运行这个应用程序的时候,只要加载优化过的ODEX文件就行了,省去了每次都要优化的时间,而参数optimizedDirectory就是代表存储ODEX文件的路径,这个路径必须是一个内部存储路径。
PathClassLoader没有参数optimizedDirectory,这是因为PathClassLoader已经默认了参数optimizedDirectory的路径为:/data/dalvik-cache

1. Android的ClassLoader层次结构

新美高梅网站 3

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来实现;

这篇文章我想复习一下ClassLoader的相关知识,它是加载外部代码的核心原理。

ClassLoader双亲委托机制

JVM以及Dalvik均是通过ClassLoader来加载类的,加载类的实现方式我们称为 双亲委托模型。

如果一个类加载器收到了类加载的请求,他首先不会自己去尝试加载这个类,而是把这个请求委托给自己的父加载器,每一层的类加载器都是如此,因此所有的类加载请求最终都应该传送到顶层的Bootstrap ClassLoader中,只有当父加载器反馈自己无法完成加载请求时,子加载器才会尝试自己加载。

新美高梅网站 4

java中ClassLoader加载顺序

双亲委托模型的重要用途是为了解决类载入过程中的安全性问题。

假设有一个开发者自己编写了一个名为java.lang.Object的类,想借此欺骗JVM。现在他要使用自定义ClassLoader来加载自己编写的java.lang.Object类。然而幸运的是,双亲委托模型不会让他成功。因为JVM会优先在BootstrapClassLoader的路径下找到java.lang.Object类,并载入它。

双亲委托的代码实现java.lang.ClassLoader#loadClass,系统自带的其他的子类都继承了此方法且没有进行复写。

protected Class<?> loadClass(String className, boolean resolve) throws ClassNotFoundException {
//判断该类有没有加载各国
        Class<?> clazz = findLoadedClass(className);
        if (clazz == null) {
            ClassNotFoundException suppressed = null;
//先尝试由父ClassLoader去加载
            try {
                clazz = parent.loadClass(className, false);
            } catch (ClassNotFoundException e) {
                suppressed = e;
            }
//如果父ClassLoader没找到该类,调用自己的findClass方法。
            if (clazz == null) {
                try {
                    clazz = findClass(className);
                } catch (ClassNotFoundException e) {
                    e.addSuppressed(suppressed);
                    throw e;
                }
            }
        }
        return clazz;
    }

参考:
http://blog.csdn.net/markzy/article/details/53192993
https://www.cnblogs.com/linux007/p/5782677.html
http://blog.csdn.net/Mr_LiaBill/article/details/50497055
http://blog.csdn.net/itachi85/article/details/78088701

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。

虽然android自己实现了一个特殊的虚拟机,它的类加载机制和普通的java程序有点区别。但是我还是想从普通的java程序讲起,一方面多知道点东西总是好的,另一方面它们的基本原理是一样的,对我们理解安卓的类加载机制也有很大的帮助。

3. DexClassLoader

DexClassLoader的构造函数为:

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

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

我们都知道java代码需要先编译成class文件才能被jvm加载运行。那jvm又是如何加载class文件的呢?

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文件了。

其实class文件是通过ClassLoader加载到jvm的。java自带了三个ClassLoader,分别是:

5. 小结

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

  • BootstrapClassLoader 用于加载核心类库
  • ExtClassLoader 用于加载拓展库
  • AppClassLoader 用于加载当前应用的类

本文由美狮美高梅官方网站发布,转载请注明来源

关键词: