类加载器与插件化解析

2.1 类装载器 DexClassLoader

首先，我们需要了解关于java代码本地import的一些知识：

import中所引用的类有两个特点：

1.必须存在于本地，当程序运行时需要该类时，内部类装载器会自动装载该类，这对程序员来讲是透明的，即程序员感知不到该过程

2.编译时必须在现场，否则编译过程会因为找不到引用文件而不能正常编译。

使用ClassLoader的必要说明，多用于动态加载一些自定义的类。

一般情况下，应用程序不需要创建一个全新的ClassLoader，而是使用当前环境中已经存在的ClassLoader。因为Java的Runtime环境在初始化时，其内部会创建一个ClassLoader对象用于加载Runtime所需的各种Java类。

每个ClassLoader必须有一个父ClassLoader，在装载Class文件时，子ClassLoader会先请求其父ClassLoader加载该Class文件，只有当其父ClassLoader找不到该Class时，子ClassLoader才会继续装载该类，这是一种安全机制。

Android使用的是DexClassLoader。

下面简单介绍下DexClassLoader的使用方法

假设这里有两个APK，第一个叫做Host，第二个叫做Plugin，其中Plugin中定义了一个PluginClass，该类中定义了一个函数，functionl(),代码如下：

public class PluginClass {

public PluginClass(){

Log.i( "Plugin" , "PluginClass client initialized" ) ;

}

public int functionl( int a, int b ) {

return a + b;

}

}

我们剩下要做的就是在这个Host APK中去掉用我们PluginClass的functionl()方法。

这里用注释解释下代码

public void useDexClassLoader(){

//确定目标class所在的位置

Intent intent = new Intent("com.haiii.android.plugin.client",null);

//通过PackageManager获取信息。

PackageManager pm = getPackageManager();

final List plugins = pm.queryIntentActivities(intent,0);

ResolveInfo info = plugins.get(0);

ActivityInfo ainfo = info.activityInfo;

//当存在多个dexPath路径时，需要此分隔符

String div = System.getProperty("npath.separator");

//报名

String packageName = ainfo.packageName;

//目标全路径

String dexPath = ainfo.applicationInfo.sourceDir;

//本地解析输出路径

String dexOutputDir = getApplicationInfo().dataDir;

//目标lib(C/C++)文件存放路径

String libPath = ainfo.applicationInfo.nativeLibraryDir;

//创建我们自己的ClassLoader

DexClassLoader cl = new DexClassLoader(dexPath,dexOutputDir,libPath,this.getClass().getClassLoader());

try {

//通过反射机制去调用方法

Class> clazz = cl.loadClass(packageName+".PluginClass");

Object obj = clazz.newInstance();

Class[] params = new Class[2];

params[0] = Integer.TYPE;

params[1] = Integer.TYPE;

Method action = clazz.getMethod("functionl",params);

Integer ret = (Integer)action.invoke(obj,12,34);

Log.i("Host","returnvalueis"+ret);

} catch (ClassNotFoundException e) {

e.printStackTrace();

} catch (InstantiationException e) {

e.printStackTrace();

} catch (IllegalAccessException e) {

e.printStackTrace();

} catch (NoSuchMethodException e) {

e.printStackTrace();

} catch (IllegalArgumentException e) {

e.printStackTrace();

} catch (InvocationTargetException e) {

e.printStackTrace();

}catch(Exception e){

Log.e("Host", "Something wrong has happened!");

}

}

上面的注释应该挺明确的，这里主要对DexClassLoader的初始化做下说明：

dexPath，指目标类所在的APK或Jar文件的路径。类装载器将从该路径中寻找指定的目标类，该路径必须是APk或Jar的全路径，比如/data/app/com.haiii.android.plugin.apk。如果要包含多个路径，路径之间必须用特定分隔符进行分割，即上面的System.getProperty(“path.sepator”)。

dexOutputDir，由于dex文件被包含在APk或者Jar中，因此在装载目标类之前需要从APk或jar中解压出dex文件，该参数就是指定解压出的dex文件存放路径。在Android系统中，一个应用程序一般对应一个Linux用户id，应用程序仅对属于自己的数据目录路径有写的权限，因此，该参数可以使用该程序的数据路径。

libPath，指目标类中所使用的C/C++库存放路径。

parent，指该装载器的父装载器，一般为当前执行类的装载器。

通过类装载器装载class之后会返回一个class对象，但这个class对象，我们本地是没有对其定义的，所以我们无法使用它的方法，而且此时也没有生成我们需要的PluginClass对象，只是装载了PluginClass的代码而已。所以这里就需要用到反射去创建对象并调用相应的方法。

2.2 基于类装载器设计的”插件“架构

目前市场上也有不少关于插件化的东西，这里将简单介绍下关于使用类装载器实现插件化的思想与方法。

上面的关于DexClassLoader的介绍，我们发现，整个调用都还算简单，但到了最后使用反射这一块太过于繁琐，既然我们知道我们要调用的类和方法，那么为什么不考虑下，使用接口机制呢？？相信看这篇文章的人都有一定的Android基础，那么应该都了解service远程aidl机制里，有一个asInterface的方式，我们可以模仿下。

首先定义一个接口，这个接口仅仅定义函数的输入和输出，不定义具体实现。这个接口要同时参与Host与Plugin两个项目(APK)的编译。

//接口定义如下

public interface Comm{

public int functionl( int a, int b ) ;

}

然后修改下PluginClass的代码

public class PluginClass implements Comm{

public PluginClass(){

Log.i( "Plugin" , "PluginClass client initialized" ) ;

}

public int functionl( int a, int b ) {

return a + b;

}

}

然后在Host中，我们对于Class对象newInstance()之后返回的对象就可以强制转换为Comm接口对象了，修改下代码：

try{

Class> clazz = cl.loadClass(packageName + ".PluginClass");

Comm comm = (Comm)clazz.newInstance();

Integer ret = comm.functionl(12,34);

Log.i("Host","return value is " + ret);

}

这段代码执行结果与上一段代码的结果是相同的。

我们来看下，当前市场中关于插件的描述：

1.一种逻辑概念，不是技术标准；

2.插件不能独立运行，必须运行与一个宿主程序中，由宿主程序去调用插件程序。

3.宿主程序中可以管理不同的插件，包括数量，禁用或使用，主题

设置等。多个插件，应该能做到切换插件。

4.宿主程序需要保证向下兼容，新版本应该能运行老版本的插件。

注意点：

1.接口一般定义在Host中，如本例的Comm.java。

2.Plugin项目中需要使用Comm是，必须通过一个外部的jar包，这个jar包必须是以Library方式添加到Plugin的build

path中，不能以外部jar包的方式添加，因为我们只需要在Host中存在我们定义的接口，而不想在Plugin中也编译进去，如果都编译进去，就会产生包名相同但验证码不同的文件，导致”Class

ref in pre-verified class resolved to unexpected implementation”.