盒子
盒子
文章目录
  1. 普通java程序的类加载机制
    1. Java类的加载流程
      1. ClassLoader的创建
      2. 双亲委托
    2. 自定义ClassLoader
    3. Context ClassLoader
  2. 安卓中的ClassLoader
    1. PathClassLoader
    2. DexClassLoader
    3. 生成dex文件
    4. 动态加载dex文件
      1. 使用反射的反射加载
      2. 使用接口的方式加载

Android温故而知新 - ClassLoader

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

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

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

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

普通java程序的类加载机制

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

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

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

然后需要说明的是java类不是一次性全部加载的,而是只有在用到的时候才会去加载。

因为全部加载的话会加载一些没有用到的类,造成资源的浪费。所以当程序需要用到某个类时,才会通过ClassLoader在系统的特定路径搜索这个类的class文件并将它加载到jvm去执行。

ExtClassLoader和AppClassLoader都是URLClassLoader的子类,他们内部保存了URL列表用于指定搜索路径。我们可以通过URLClassLoader.getURLs()方法获取到这个URL列表。

BootstrapClassLoader虽然不是URLClassLoader的子类,但我们也可以从sun.misc.Launcher.getBootstrapClassPath().getURLs()方法获取到BootstrapClassLoader的搜索路径。

下面的代码打印了各个ClassLoader的搜索路径:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
import java.net.URL;
import java.net.URLClassLoader;

public class ClassLoaderURLs {
public static void main(String[] args) {
System.out.println("BootstrapClassLoader urls :");
URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();
for (URL url : urls) {
System.out.println(url);
}

URLClassLoader extClassLoader = (URLClassLoader) ClassLoader.getSystemClassLoader().getParent();
System.out.println("\n" + extClassLoader + " urls :");
urls = extClassLoader.getURLs();
for (URL url : urls) {
System.out.println(url);
}

URLClassLoader appClassLoader = (URLClassLoader) ClassLoader.getSystemClassLoader();
System.out.println("\n" + appClassLoader + " urls :");
urls = appClassLoader.getURLs();
for (URL url : urls) {
System.out.println(url);
}
}
}

打印如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
BootstrapClassLoader urls :
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre/lib/resources.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre/lib/rt.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre/lib/sunrsasign.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre/lib/jsse.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre/lib/jce.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre/lib/charsets.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre/lib/jfr.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre/classes

sun.misc.Launcher$ExtClassLoader@74a14482 urls :
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre/lib/ext/cldrdata.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre/lib/ext/dnsns.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre/lib/ext/jfxrt.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre/lib/ext/localedata.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre/lib/ext/nashorn.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre/lib/ext/sunec.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre/lib/ext/sunjce_provider.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre/lib/ext/sunpkcs11.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre/lib/ext/zipfs.jar
file:/System/Library/Java/Extensions/AppleScriptEngine.jar
file:/System/Library/Java/Extensions/dns_sd.jar
file:/System/Library/Java/Extensions/j3daudio.jar
file:/System/Library/Java/Extensions/j3dcore.jar
file:/System/Library/Java/Extensions/j3dutils.jar
file:/System/Library/Java/Extensions/jai_codec.jar
file:/System/Library/Java/Extensions/jai_core.jar
file:/System/Library/Java/Extensions/libAppleScriptEngine.jnilib
file:/System/Library/Java/Extensions/libJ3D.jnilib
file:/System/Library/Java/Extensions/libJ3DAudio.jnilib
file:/System/Library/Java/Extensions/libJ3DUtils.jnilib
file:/System/Library/Java/Extensions/libmlib_jai.jnilib
file:/System/Library/Java/Extensions/mlibwrapper_jai.jar
file:/System/Library/Java/Extensions/MRJToolkit.jar
file:/System/Library/Java/Extensions/vecmath.jar
file:/usr/lib/java/libjdns_sd.jnilib

sun.misc.Launcher$AppClassLoader@28d93b30 urls :
file:/Users/linjw/workspace/class_loader_demo/

我们可以看到这些url有指向jar包的,也有指向一个目录的(还有指向.jnilib文件的,这个我们可以不用管)。

ClassLoader从指定的路径下搜索class文件。而jar包其实是一个压缩包,将class文件打包在一起,所以ClassLoader也可以从jar包中搜索需要用到的class。

Java类的加载流程

ClassLoader的创建

我们先从ClassLoader的创建开始说起。我们可以直接看sun.misc.Launcher的源码,它在构造函数中创建了ExtClassLoader和AppClassLoader:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public Launcher() {
// Create the extension class loader
ClassLoader extcl;
try {
extcl = ExtClassLoader.getExtClassLoader();
} catch (IOException e) {
throw new InternalError(
"Could not create extension class loader", e);
}

// Now create the class loader to use to launch the application
try {
loader = AppClassLoader.getAppClassLoader(extcl);
} catch (IOException e) {
throw new InternalError(
"Could not create application class loader", e);
}

// Also set the context class loader for the primordial thread.
Thread.currentThread().setContextClassLoader(loader);

...
}

ExtClassLoader.getExtClassLoader()是一个工厂方法:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public static ExtClassLoader getExtClassLoader() throws IOException
{
final File[] dirs = getExtDirs();

try {
// Prior implementations of this doPrivileged() block supplied
// aa synthesized ACC via a call to the private method
// ExtClassLoader.getContext().

return AccessController.doPrivileged(
new PrivilegedExceptionAction<ExtClassLoader>() {
public ExtClassLoader run() throws IOException {
int len = dirs.length;
for (int i = 0; i < len; i++) {
MetaIndex.registerDirectory(dirs[i]);
}
return new ExtClassLoader(dirs);
}
});
} catch (java.security.PrivilegedActionException e) {
throw (IOException) e.getException();
}
}

AppClassLoader.getAppClassLoader(final ClassLoader extcl)也是一个工厂方法,它需要传入一个ClassLoader作为AppClassLoader的父ClassLoader。而我们将ExtClassLoader传了进去,也就是说ExtClassLoader是AppClassLoader的父ClassLoader:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public static ClassLoader getAppClassLoader(final ClassLoader extcl)
throws IOException
{
final String s = System.getProperty("java.class.path");
final File[] path = (s == null) ? new File[0] : getClassPath(s);

// Note: on bugid 4256530
// Prior implementations of this doPrivileged() block supplied
// a rather restrictive ACC via a call to the private method
// AppClassLoader.getContext(). This proved overly restrictive
// when loading classes. Specifically it prevent
// accessClassInPackage.sun.* grants from being honored.
//
return AccessController.doPrivileged(
new PrivilegedAction<AppClassLoader>() {
public AppClassLoader run() {
URL[] urls =
(s == null) ? new URL[0] : pathToURLs(path);
return new AppClassLoader(urls, extcl);
}
});
}

每一个ClassLoader都有一个父ClassLoader,我们可以通过ClassLoader.getParent()方法获取。同时我们也能使用Class.getClassLoader()获取加载这个类的ClassLoader。所以让我们来看看下面的代码:

1
2
3
4
5
6
7
8
public class GetClassLoader {
public static void main(String[] args) {
ClassLoader loader = GetClassLoader.class.getClassLoader();
do {
System.out.println(loader);
} while ((loader = loader.getParent()) != null);
}
}

查看打印我们可以知道, GetClassLoader是AppClassLoader加载的,而AppClassLoader的父ClassLoader是ExtClassLoader:

1
2
sun.misc.Launcher$AppClassLoader@28d93b30
sun.misc.Launcher$ExtClassLoader@74a14482

但是如果我们查看String的ClassLoader又会发现它是null的:

1
2
3
4
5
6
public class GetClassLoader {
public static void main(String[] args) {
ClassLoader loader = String.class.getClassLoader();
System.out.println("loader : " + loader);
}
}
1
loader : null

那是不是说String不是由ClassLoader加载的?当然不是!其实String是BootstrapClassLoader加载的。BootstrapClassLoader负责加载java的核心类。

但是为什么String.class.getClassLoader()拿到的是null呢?

原因是BootstrapClassLoader实际上不是一个java类,它是由C/C++编写的,它本身是虚拟机的一部分。所以在java中当然没有办法获取到它的引用。

双亲委托

相信大家如果知道ClassLoader的话应该有听说过双亲委托,那下面我们就来讲一下双亲委托究竟是怎么一回事。

我们知道ClassLoader.loadClass()的方法可以加载一个类,所以研究一个类的加载流程,最好的方法当然还是去看源码啦:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// 首先,从缓存中查询该类是不是被加载过,如果加载过就可以直接返回
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {
//判断它的父ClassLoader是否为空,如果不为空就调用父ClassLoader的loadClass方法去加载该类
c = parent.loadClass(name, false);
} else {
//如果它的父ClassLoader为空,则调用BootstrapClassLoader去加载该类,所以此时从逻辑上来讲BootstrapClassLoader是父ClassLoader
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {

}

if (c == null) {
long t1 = System.nanoTime();

//如果父ClassLoader不能加载该类才由自己去加载,这个方法从本ClassLoader的搜索路径中查找该类
c = findClass(name);

sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}

从代码中我们可以看到,加载一个类的时候,ClassLoader先会让父类去加载,如果父类加载失败,才会由它自己去加载,这就是我们说的双亲委托。

为什么类加载需要设计成双亲委托的方式呢?原因就在于双亲委托可以防止类被重复加载。如果父ClassLoader已经加载过一个类了,子ClassLoader就不会再次加载,可以防止同一个类被两个ClassLoader重复加载的问题。

这里还需要说的是,当我们自定义一个ClassLoader的时候,最好将AppClassLoader设为父ClassLoader。这样的话可以保证我们自定义的ClassLoader找加载类失败的时候还能从父ClassLoader中加载这个类。

双亲委托模式的流程如下图所示:

自定义ClassLoader

有时候我们可以继承ClassLoader实现自己的类加载器。自定义ClassLoader有两种方式:

  1. 重写loadClass方法
  2. 重写findClass方法

他们有什么区别呢,还记得上一级ClassLoader.loadClass()的源码吗?loadClass方法内会先调用父ClassLoader的loadClass方法,如果父ClassLoader没有加载过该类才会调用本ClassLoader的findClass方法去加载类。

所以如果想要打破双亲委托机制的话就可以loadClass(),而如果还想继续沿用双亲委托机制的话就只需要重写findClass就好了。

我们写个小例子:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
public class MyClassLoader extends ClassLoader {
public String mClassDir;

public MyClassLoader(String classDir) {
this.mClassDir = classDir;
}


@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
File file = new File(mClassDir, getClassFileName(name));
if (file.exists()) {
try {
FileInputStream is = new FileInputStream(file);

ByteArrayOutputStream buf = new ByteArrayOutputStream();
int len;
while ((len = is.read()) != -1) {
buf.write(len);
}

byte[] data = buf.toByteArray();
is.close();
buf.close();

return defineClass(name, data, 0, data.length);
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
}

return super.findClass(name);
}

private String getClassFileName(String fullName) {
int index = fullName.lastIndexOf(".");
if (index == -1) {
return fullName + ".class";
} else {
return fullName.substring(index + 1) + ".class";
}
}
}

因为我们不需要打破双亲委托机制所以只需要重写findClass方法就可以了。我们自定义的ClassLoader会从指定的路径中搜索class文件,将它读入内存,然后通过调用ClassLoader.defineClass()方法去加载这个类。

我们在/Users/linjw/workspace/class_loader_demo目录下创建了一个Test.java:

1
2
3
4
5
6
package linjw.demo.classloader;
public class Test {
public String getData() {
return "Hello World";
}
}

然后通过javac命令编译出Test.class文件,同样放在/Users/linjw/workspace/class_loader_demo目录下。

然后用我们的MyClassLoader去加载它:

1
2
3
4
5
6
7
8
9
10
11
MyClassLoader loader = new MyClassLoader("/Users/linjw/workspace/class_loader_demo");
Class clazz = loader.loadClass("linjw.demo.classloader.Test");
if (clazz != null) {
Object obj = clazz.newInstance();
Method method = clazz.getDeclaredMethod("getData");
String result = (String) method.invoke(obj);
System.out.println(result);
System.out.println("ClassLoader : " + clazz.getClassLoader());
} else {
System.out.println("can't load class");
}

可以看到下面的打印,说明我们已经成功用MyClassLoader加载了Test这个类:

1
2
Hello World
ClassLoader : linjw.demo.classloader.MyClassLoader@66cd51c3

这里还有一个小的知识点,如果一个类是由某个ClassLoader加载的,那么它import的类也会由这个ClassLoader去加载。这里我们可以做一个实验:

1
2
3
4
5
6
7
8
9
package linjw.demo.classloader;

import linjw.demo.classloader.Test;

public class Test2 {
public String getData(){
return "Test ClassLoader : " + Test.class.getClassLoader();
}
}

我们写一个Test2类,它会import Test并返回Test的ClassLoader。让我们写个demo看看这个Test的ClassLoader:

1
2
3
4
5
6
7
8
9
10
MyClassLoader loader = new MyClassLoader("/Users/linjw/workspace/class_loader_demo");
Class clazz = loader.loadClass("linjw.demo.classloader.Test2");
if (clazz != null) {
Object obj = clazz.newInstance();
Method method = clazz.getDeclaredMethod("getData");
String result = (String) method.invoke(obj);
System.out.println(result);
} else {
System.out.println("can't load class");
}

通过打印可以知道Test也是由MyClassLoader加载的:

1
linjw.demo.classloader.MyClassLoader@66cd51c3

Context ClassLoader

Context ClassLoader并不是一个实际的类,它只是Thread的一个成员变量:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class Thread implements Runnable {
private ClassLoader contextClassLoader;

private void init2(Thread parent) {
this.contextClassLoader = parent.getContextClassLoader();
...
}

public ClassLoader getContextClassLoader() {
return contextClassLoader;
}

public void setContextClassLoader(ClassLoader cl) {
contextClassLoader = cl;
}

...
}

每个Thread都有一个相关联的ClassLoader,子线程默认使用父线程的ClassLoader。

而线程的默认ClassLoader是AppClassLoader:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public Launcher() {
...

try {
loader = AppClassLoader.getAppClassLoader(extcl);
} catch (IOException e) {
throw new InternalError(
"Could not create application class loader", e);
}

//设置AppClassLoader为当前线程的Context ClassLoader
Thread.currentThread().setContextClassLoader(loader);

...
}

Context ClassLoader的存在是为了解决使用双亲委托机制下父ClassLoader无法找到子ClassLoader的问题。假如有下面的委托链:

ClassLoaderA -> AppClassLoader -> ExtClassLoader -> BootstrapClassLoader

那么委派链左边的ClassLoader就可以很自然的使用右边的ClassLoader所加载的类。

但如果是右边的ClassLoader想要反过来使用左边的ClassLoader所加载的类就无能为力了。

这个时候如果使用Context ClassLoader就能从线程中获得左边的ClassLoader了。

那什么时候会出现右边的ClassLoader想要反过来使用左边的ClassLoader所加载的类的情况呢?

我们上一节刚刚说过:“如果一个类是由某个ClassLoader加载的,那么它import的类也会由这个ClassLoader去加载”。

举个例子,Java 提供了很多服务提供者接口(Service Provider Interface,SPI),允许第三方为这些接口提供实现。如JAXP(XML处理的Java API)的SPI__接口__定义包含在 javax.xml.parsers包中,它是由BootstrapClassLoader加载的。

但是它的实现代码很可能是作为Java应用所依赖的jar包被包含进来,如实现了JAXP SPI的Apache Xerces所包含的jar包,它由AppClassLoader加载。

我们用javax.xml.parsers.DocumentBuilderFactory类中的newInstance()方法用来生成一个新的DocumentBuilderFactory的实例, DocumentBuilderFactory是一个抽象类,它定是java核心库的一部分,由BootstrapClassLoader去加载。因此,DocumentBuilderFactory里面import的类都由BootstrapClassLoader去加载。

但是DocumentBuilderFactory的实现类却是在org.apache.xerces.jaxp.DocumentBuilderFactoryImpl中定义的, BootstrapClassLoader无法加载它。这个时候就需要在DocumentBuilderFactory. newInstance()的代码中使用Context ClassLoader,找到AppClassLoader去加载DocumentBuilderFactoryImpl这个实现类。

安卓中的ClassLoader

安卓的的类也是通过ClassLoader加载的,但是并不是java中的BootstrapClassLoader、 ExtClassLoader或者AppClassLoader。写个小demo看看安卓中加载类的是哪些ClassLoader:

1
2
3
4
5
6
Log.d("DxClassLoader", "BootClassLoader :" + String.class.getClassLoader());

ClassLoader loader = MainActivity.class.getClassLoader();
do {
Log.d("DxClassLoader", "loader :" + loader);
} while ((loader = loader.getParent()) != null);

打印如下:

1
2
3
09-27 23:11:03.432 21151-21151/? D/DxClassLoader: BootClassLoader :java.lang.BootClassLoader@ad96016
09-27 23:11:03.432 21151-21151/? D/DxClassLoader: loader :dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/linjw.demo.classloader-2/base.apk"],nativeLibraryDirectories=[/data/app/linjw.demo.classloader-2/lib/arm64, /vendor/lib64, /system/lib64]]]
09-27 23:11:03.433 21151-21151/? D/DxClassLoader: loader :java.lang.BootClassLoader@ad96016

我们可以看到安卓中用的了PathClassLoader和BootClassLoader两个ClassLoader,其中BootClassLoader是PathClassLoader的parent。

而和在java程序不同的是String是由BootClassLoader加载的。安卓的BootClassLoader其实就相当于java的BootstrapClassLoader,只不过它是由java实现的而不是由c/c++实现的。

PathClassLoader

我们在上一节中将PathClassLoader打印出来的时候可以看到一个apk路径:

1
[zip file "/data/app/linjw.demo.classloader-2/base.apk"]

apk其实是一个也是一个zip压缩包,我们可以将一个apk文件后缀改成.zip然后就可以直接解压了。PathClassLoader的作用其实就是在这个zip包中加载dex文件,我们通过它甚至可以加载其他应用的代码,但它只能加载已安装的应用。

例如我们可以新建一个ext工程,它的包名为linjw.demo.classloader.ext,然后在里面创建Test类:

1
2
3
4
5
6
7
package linjw.demo.classloader.ext;

public class Test {
public String getData() {
return "Hello World";
}
}

然后编译出apk来,并且安装。之后就能从这个apk中加载出Test类了:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
String path = null;
PackageManager pm = getPackageManager();
try {
path = pm.getApplicationInfo("linjw.demo.classloader.ext", 0).sourceDir;
} catch (PackageManager.NameNotFoundException e) {
e.printStackTrace();
}

PathClassLoader loader = new PathClassLoader(path, ClassLoader.getSystemClassLoader());

try {
Class clazz = loader.loadClass("linjw.demo.classloader.ext.Test");

if (clazz != null) {
Object obj = clazz.newInstance();
Method method = clazz.getDeclaredMethod("getData");
String result = (String) method.invoke(obj);
Log.d("DxClassLoader", result);
} else {
Log.d("DxClassLoader", "can't load class");
}
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (NoSuchMethodException e) {
e.printStackTrace();
} catch (InstantiationException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (InvocationTargetException e) {
e.printStackTrace();
}

可以得到打印:

1
09-27 23:39:16.571 24077-24077/? D/DxClassLoader: Hello World

DexClassLoader

PathClassLoader只能加载已经安装的应用里面的类,但是DexClassLoader却能加载未安装的应用里面的类。例如我们将apk放到存储卡目录下而不去安装它:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
String dir = Environment.getExternalStorageDirectory().getAbsolutePath();
File apk = new File(dir, "Ext.apk");
File dexOutputDir = this.getDir("dex", 0);
DexClassLoader loader = new DexClassLoader(
apk.getAbsolutePath(),
dexOutputDir.getAbsolutePath(),
null, getClassLoader());

try {
Class clazz = loader.loadClass("linjw.demo.classloader.ext.Test");

if (clazz != null) {
Object obj = clazz.newInstance();
Method method = clazz.getDeclaredMethod("getData");
String result = (String) method.invoke(obj);
Log.d("DxClassLoader", result);
} else {
Log.d("DxClassLoader", "can't load class");
}
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (NoSuchMethodException e) {
e.printStackTrace();
} catch (InstantiationException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (InvocationTargetException e) {
e.printStackTrace();
}

同样可以得到打印:

1
09-27 23:54:29.206 25472-25472/? D/DxClassLoader: Hello World

我们可以看到, DexClassLoader的构造函数的参数比PathClassLoader的要多出一个optimizedDirectory:

1
2
3
4
5
6
public class DexClassLoader extends BaseDexClassLoader {
public DexClassLoader(String dexPath, String optimizedDirectory, String librarySearchPath, ClassLoader parent) {
super((String)null, (File)null, (String)null, (ClassLoader)null);
throw new RuntimeException("Stub!");
}
}
1
2
3
4
5
6
7
8
9
10
11
public class PathClassLoader extends BaseDexClassLoader {
public PathClassLoader(String dexPath, ClassLoader parent) {
super((String)null, (File)null, (String)null, (ClassLoader)null);
throw new RuntimeException("Stub!");
}

public PathClassLoader(String dexPath, String librarySearchPath, ClassLoader parent) {
super((String)null, (File)null, (String)null, (ClassLoader)null);
throw new RuntimeException("Stub!");
}
}

那这个optimizedDirectory到底有什么作用呢?其实optimizedDirectory是用来存放从apk中解压出来的dex文件的。

DexClassLoader和PathClassLoader其实归根结底都是通过DexFile这个类去加载的dex文件,并不是直接读取的apk。因为如果每次都需要解压才能加载代码的话效率实在太低了。

DexClassLoader可以主动解压apk,所以可以加载未安装的应用中的代码。但PathClassLoader不会主动解压apk,它是读取的已经安装的apk在cache中存在缓存的dex文件,所以它只能加载已安装应用中的代码。

生成dex文件

DexClassLoader和PathClassLoader最后都是加载的dex文件。所以我们可以直接将dex文件的路径传给他们去加载。但dex文件又是个什么东西呢?

普通的java程序中,JVM虚拟机可以通过ClassLoader去加载jar到的加载类的目的。但是android使用的Dalvik/ART虚拟机不能直接加载jar包,需要把.jar文件优化成.dex文件才能加载。所以实际上dex文件是优化过的jar包。

我们可以用Android SDK提供的DX工具把.jar文件优化成.dex文件。我们用之前的Test.java做例子,具体步骤如下:

1.使用javac命令编译Test.java得到Test.class文件(我这边的java环境是1.8的,如果不指定用1.7的话生成dex也会失败,报com.android.dx.cf.iface.ParseException: bad class file magic (cafebabe) or version (0034.0000))

1
javac -source 1.7 -target 1.7 Test.java

2.将创建目录子目录linjw/demo/classloader/ext并将Test.class移动到子目录中(因为Test的package是linjw.demo.classloader.ext,所以要根据它生成同样的目录,要不然生成dex会失败)

1
2
mkdir -p linjw/demo/classloader/ext
mv Test.class linjw/demo/classloader/ext

3.使用jar命令将linjw目录打包成jar包

1
jar -cf Test.jar linjw

4.用dx工具将jar包优化成dex包

1
/Users/linjw/androidsdk/android-sdk-macosx/build-tools/19.1.0/dx --dex --output=Test.dex Test.jar

动态加载dex文件

然后我们就能将它放到存储卡中用DexClassLoader或者PathClassLoader去加载了。

使用反射的反射加载

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

String dir = Environment.getExternalStorageDirectory().getAbsolutePath();
File dex = new File(dir, "Test.dex");
File dexOutputDir = this.getDir("dex", 0);

//使用PathClassLoader加载dex
//PathClassLoader loader = new PathClassLoader(dex.getAbsolutePath(), getClassLoader());

//使用DexClassLoader加载dex
DexClassLoader loader = new DexClassLoader(
dex.getAbsolutePath(),
dexOutputDir.getAbsolutePath(),
null,
getClassLoader());

try {
Class clazz = loader.loadClass("linjw.demo.classloader.ext.Test");

if (clazz != null) {
Object obj = clazz.newInstance();
Method method = clazz.getDeclaredMethod("getData");
String result = (String) method.invoke(obj);
Log.d("DxClassLoader", result);
} else {
Log.d("DxClassLoader", "can't load class");
}
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (NoSuchMethodException e) {
e.printStackTrace();
} catch (InstantiationException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (InvocationTargetException e) {
e.printStackTrace();
}

使用接口的方式加载

或者我们也可以使用接口的方式:

1.添加ITest接口:

1
2
3
4
5
package linjw.demo.classloader.ext;

public interface ITest {
String getData();
}

2.Test类实现ITest接口:

1
2
3
4
5
6
7
8
package linjw.demo.classloader.ext;

public class Test implements ITest {
@Override
public String getData() {
return "Hello World";
}
}

3.将它们一起打包到Test.dex

1
2
3
4
5
6
7
8
9
10
11
javac -source 1.7 -target 1.7 Test.java ITest.java

mkdir -p linjw/demo/classloader/ext

mv Test.class linjw/demo/classloader/ext

mv Test.class linjw/demo/classloader

jar -cf Test.jar linjw

/Users/linjw/androidsdk/android-sdk-macosx/build-tools/19.1.0/dx --dex --output=Test.dex Test.jar

4.在安卓项目中导入ITest接口并调整代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
String dir = Environment.getExternalStorageDirectory().getAbsolutePath();
File dex = new File(dir, "Test.dex");
File dexOutputDir = this.getDir("dex", 0);

//使用PathClassLoader加载dex
//PathClassLoader loader = new PathClassLoader(dex.getAbsolutePath(), getClassLoader());

//使用DexClassLoader加载dex
DexClassLoader loader = new DexClassLoader(
dex.getAbsolutePath(),
dexOutputDir.getAbsolutePath(),
null,
getClassLoader());

try {
Class clazz = loader.loadClass("linjw.demo.classloader.ext.Test");

if (clazz != null) {
//注意这里,使用的是ITest
ITest obj = (ITest) clazz.newInstance();
String result = obj.getData();
Log.d("DxClassLoader", result);
} else {
Log.d("DxClassLoader", "can't load class");
}
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (InstantiationException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
}

其实我比较推荐使用在程序主体中定义接口,加载外部实现代码的这种方法。一方面它比反射的效率高,另一方面也比较容易阅读。