Android插件化框架系列之类加载器

过去的一两年android插件化，热修复等技术发展迅速，并且还在持续的探索中，也许插件化技术最终会在android工程中退出舞台，但里面包含的技术是非常值得我们学习的。最近，会就android动态加载等技术进行研究总结。
本篇文章作为插件化框架第一篇，首先分析android中的类加载器，并实现在android中动态加载一个外部apk中的类，从以下三部分进行介绍。

一. java类加载器双亲委派机制
二. android中的类加载器介绍
三. android中动态加载实现类加载

一. java类加载器双亲委派机制
学过java的同学都知道类加载器是采用双亲委派机制来进行类加载的。双亲委派机制从ClassLoader.java可以清晰的看出来。

   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) {                long t0 = System.nanoTime();                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.                    long t1 = System.nanoTime();                    c = findClass(name);//调用当前类加载器的findClass方法进行加载                    // this is the defining class loader; record the stats                }            }            return c;    }

简单来说，java的双亲委派机制分为三个过程，在ClassLoader的loadClass方法中会先判断该类是否已经加载，若加载了直接返回，若没加载过则先调用父类加载器的loadClass方法进行类加载，若父类加载器没有找到，则会调用当前正在查找的类加载器的findClass方法进行加载。这里就涉及到类加载器的两个很重要的方法loadClass和findClass。在自定义类加载器中会涉及到这两个方法，具体二者有什么区别呢？

由上文的双亲委派机制的代码可以看出来，如果想保证自定义的类加载器符合双亲委派机制，则覆写findClass方法；如果想打破双亲委派机制，则覆写loadClass方法。，双亲委派机制保证了同一个类不会被重复加载，但是某些情况下，是需要限定名相同的多个类被多个类加载器分别加载的，比如容器插件应用场景。这时就可以在自定义类加载器时覆写loadClass方法，摆脱双亲委派机制来直接加载。例如：

 public class MyClassLoader extends DexClassLoader{    public MyClassLoader(String dexPath, String optimizedDirectory, String librarySearchPath, ClassLoader parent) {        super(dexPath, optimizedDirectory, librarySearchPath, parent);    }    @Override    protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {        if(xxx){//条件判断是否自己加载            return this.loadClass(name);        }else{//双亲委派机制加载            return super.loadClass(name, resolve);        }    }}

二. android中的类加载器介绍
android中的类加载器中主要包括三类BootClassLoader，PathClassLoader和DexClassLoader。
BootClassLoader主要用于加载系统的类，包括java和android系统的类库。
PathClassLoader主要用于加载应用内中的类。路径是固定的，只能加载
/data/app中的apk，无法指定解压释放dex的路径。所以PathClassLoader是无法实现动态加载的。
DexClassLoader可以用于加载任意路径的zip,jar或者apk文件。可以实现动态加载。下面来具体看看应用程序中的类加载器。

 Log.i("ljj", "Context的类加载器："+ Context.class.getClassLoader()); Log.i("ljj", "TextView的类加载器： "+ TextView.class.getClassLoader());

打印结果：

02-14 12:37:49.161 22341-22341/com.ljj.host I/ljj: Context的类加载器：[email protected]02-14 12:37:49.162 22341-22341/com.ljj.host I/ljj: TextView的类加载器： [email protected]

可见系统的类都是由BootClassLoader加载完成。

 Log.i("ljj", "classLoader:"+getClassLoader());

02-14 13:19:23.730 20518-20518/com.ljj.host I/ljj: classLoader:dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.ljj.host-2/base.apk"],nativeLibraryDirectories=[/data/app/com.ljj.host-2/lib/arm64, /vendor/lib64, /system/lib64]]]

可见直接调用getClassLoader调用的是应用的PathClassLoader，DexPathList为/data/app/com.ljj.host-2/base.apk。

除了BootClassLoader和应用的PathClassLoader外，还有一个classLoader，比较难以理解，我们可以打印出来看看。

Log.i("ljj", "classLoader:"+ClassLoader.getSystemClassLoader());

02-14 13:32:01.747 4482-4482/com.ljj.host I/ljj: classLoader:dalvik.system.PathClassLoader[DexPathList[[directory "."],nativeLibraryDirectories=[/vendor/lib64, /system/lib64]]]

可见调用ClassLoader.getSystemClassLoader()得到的也是一个PathClassLoader，但是DexPathList为“.”。这就奇怪了，为什么路径会为“.”,有必要查看一下源码。

 static private class SystemClassLoader {        public static ClassLoader loader = ClassLoader.createSystemClassLoader();    }

   private static ClassLoader createSystemClassLoader() {        String classPath = System.getProperty("java.class.path", ".");        String librarySearchPath = System.getProperty("java.library.path", "");        return new PathClassLoader(classPath, librarySearchPath, BootClassLoader.getInstance());    }

从源码中可以看出，getSystemClassLoader()方法获得的pathClassLoader的path是由classPath来指定的

   String classPath = System.getProperty("java.class.path", ".");

打印发现输出为"."，没有从源码中找到对于"java.class.path"变量的赋值过程，希望了解的人可以指教一下。至于这个classLoader什么时候用，我的看法是当我们自定义classLoader时，假设是一个插件工程，想与host工程不冲突，独立运行，关注插件工程中的类的加载，而不关注host工程中的类的加载造成的冲突，此时可以将自定义类加载器的parent指定为此classLoader。

至于PathClassLoader我们只要知道它的路径是指定的，必须是已经安装的apk，应用的classLoader默认为PathClassLoader即可。下面我们将重点分析一下DexClassLoader。先从源码的角度进行简单分析。

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

DexClassLoader的源码很简单，只包含一个构造函数，看来所有的工作都是在BaseDexClassLoader中完成的。这里再看BaseDexClassLoader前，先说一下DexClassLoader构造函数的四个参数。
dexPath：是加载apk/dex/jar的路径
optimizedDirectory：是dex的输出路径(因为加载apk/jar的时候会解压除dex文件，这个路径就是保存dex文件的)
librarySearchPath：是加载的时候需要用到的lib库，这个一般不用，可以传入Null
parent：给DexClassLoader指定父加载器
下面继续分析BaseClassLoader。

public class BaseDexClassLoader extends ClassLoader {    private final DexPathList pathList;    public BaseDexClassLoader(String dexPath, File optimizedDirectory,            String librarySearchPath, ClassLoader parent) {        super(parent);        this.pathList = new DexPathList(this, dexPath, librarySearchPath, optimizedDirectory);    }   @Override    protected Class<?> findClass(String name) throws ClassNotFoundException {        List suppressedExceptions = new ArrayList();        Class c = pathList.findClass(name, suppressedExceptions);        if (c == null) {            ClassNotFoundException cnfe = new ClassNotFoundException("Didn't find class \"" + name + "\" on path: " + pathList);            for (Throwable t : suppressedExceptions) {                cnfe.addSuppressed(t);            }            throw cnfe;        }        return c;    }

可以看出，DexClassLoader会通过传入的路径构造出一个DexPathList对象，作为pathList。从findClass方法可以看出来加载的类都是从pathList中查找。至于DexPathList对象的源码就不往下具体分析了，简单的理解就是将每个dex都构建成Element元素，放入到dexElements数组中，多说一句，这个dexElements数组的用处很大，MultiDex方案以及由此衍生出的QQ空间热更新方案都是通过改变dexElements数组的元素位置来实现的。感兴趣的同学可以去学习一下。

三. android中动态加载实现类加载
类加载器知识介绍完毕后，我们来具体实现利用DexClassLoader来动态加载一个apk中的类。最简单的实现方式，我们可以将一个java文件打包成jar或者转化成dex后压缩成apk，然后利用DexClassLoader加载后，反射调用里面的方法来验证效果，不过这个实例不太好说明问题，而且在项目中我们一般也不这样用。
在项目中我们可能更多的是这样使用，一个插件工程，一个宿主工程，二者间的联系通过公共接口来完成。下面来具体操作以下。
第一步：将接口打包成jar
我们新建一个接口，打包出PayService.jar。

public interface IPay {    public void pay(int money);    public String getOrder(String userName);    public String getUserName();}

我电脑里装有eclipse，打jar包非常方便。如果没有安装eclipse，也可以用jar命令或者gradle任务来完成。

第二步：新建一个android工程，命名为PluginPro
将PayService.jar放入libs目录，新建一个PayServiceImpl类实现IPay接口，为了方便起见，具体实现中只打印了log。

public class PayServiceImpl implements IPay {        @Override    public void pay(int money) {        Log.i("ljj", "pay: "+money+" 元");    }    @Override    public String getOrder(String s) {        return "0001";    }    @Override    public String getUserName() {        return "ljj";    }}

以compile的形式打包进apk。

 compile fileTree(include: ['*.jar'], dir: 'libs')

第三步：新建一个android工程，命名为HostPro
将PluginPro工程生成的apk放入assets目录下，至于为什么放入到assets目录，目前插件框架中的插件都是放入到assets目录上进行打包的，这里虽然不存在插件框架，但是尽量模拟一下这种动态加载的场景。我们分为以下几种情况进行分析。

1. PayService.jar在PluginPro和HostPro均以compile的形式进行依赖，DexClassLoader的parent设置为应用默认的PathClassLoader

public class MainActivity extends AppCompatActivity {    @Override    protected void onCreate(Bundle savedInstanceState) {        super.onCreate(savedInstanceState);        setContentView(R.layout.activity_main);        //创建apk加载路径        String src=this.getFilesDir().getAbsolutePath()+ File.separator+"plugin.apk";        //作为odex的释放路径        String des= this.getFilesDir().getAbsolutePath()+ File.separator+"plugin"+File.separator;        try {            copyPlugin(src);//将assets下的插件apk拷贝到src路径下            //创建DexClassLoader,parent指定为应用默认的PathClassLoader            DexClassLoader classLoader=new DexClassLoader(src,des,null,getClassLoader());            Class class1=classLoader.loadClass("com.ljj.plugin.serviceimpl.PayServiceImpl");            Object instance=class1.newInstance();            IPay payService=(IPay)instance;            String userName=payService.getUserName();            String order=payService.getOrder("ss");            payService.pay(10);            Log.i("ljj", "userName: "+userName);            Log.i("ljj", "order: "+order);        } catch (Exception e) {            e.printStackTrace();        }    }    private void copyPlugin(String path) throws Exception{        InputStream in=this.getAssets().open("app-release-unsigned.apk");        OutputStream os=new FileOutputStream(path);        byte[] temp=new byte[1024];        int len=-1;        while((len=in.read(temp))!=-1){            os.write(temp,0,len);        }        in.close();        os.flush();        os.close();    }}

使用android5.0系统的手机进行测试一把，结果如下，能够正常运行，正常调用到了插件apk中的函数：

02-15 16:21:04.750 8875-8875/com.ljj.host I/art: Can not find class: Lcom/ljj/plugin/serviceimpl/PayServiceImpl;02-15 16:21:04.750 8875-8875/com.ljj.host I/ljj: pay: 10 元02-15 16:21:04.750 8875-8875/com.ljj.host I/ljj: userName: ljj02-15 16:21:04.750 8875-8875/com.ljj.host I/ljj: order: 0001

保持代码不变，又搞了个android4.2系统的手机测试一把，结果挂了：

02-15 08:50:32.346 3897-3897/? E/AndroidRuntime: FATAL EXCEPTION: main                                                 java.lang.IllegalAccessError: Class ref in pre-verified class resolved to unexpected implementation                                                     at dalvik.system.DexFile.defineClass(Native Method)                                                     at dalvik.system.DexFile.loadClassBinaryName(DexFile.java:211)                                                     at dalvik.system.DexPathList.findClass(DexPathList.java:313)                                                     at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:51)                                                     at java.lang.ClassLoader.loadClass(ClassLoader.java:501)                                                     at java.lang.ClassLoader.loadClass(ClassLoader.java:461)                                                     at com.ljj.host.MainActivity.onCreate(MainActivity.java:35)

我们来分析一下为什么出现这种结果。首先在插件apk和宿主apk中都包含了IPay接口，我们定义的DexClassLoader指定的parent为应用默认的PathClassLoader，两个classLoader的DexPathList的路径如下所示。之所以出现这种原因可能是art和Dalvik虚拟机的内部加载细节的差异。下面针对两种情况进行分析。

02-15 09:27:28.020 6666-6666/? I/ljj: onCreate: dalvik.system.DexClassLoader[DexPathList[[zip file "/data/data/com.ljj.host/files/plugin.apk"],nativeLibraryDirectories=[/vendor/lib, /system/lib]]]02-15 09:27:28.020 6666-6666/? I/ljj: onCreate: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.ljj.host-1.apk"],nativeLibraryDirectories=[/data/app-lib/com.ljj.host-1, /vendor/lib, /system/lib]]]

在art虚拟机中，当我们执行loadClass("com.ljj.plugin.serviceimpl.PayServiceImpl");时，根据双亲委派机制，PathClassLoader会先在宿主apk中查找，此时肯定找不到"PayServiceImpl",接着由DexClassLoader从插件apk中查找PayServiceImpl，毫无疑问，可以查找PayServiceImpl，同时发现其实现了IPay接口，此时仍然会由PathClassLoader去宿主apk中查找，很明显可以找到IPay接口，所以IPay接口是由应用的PathClassLoader加载的。这样就正常的完成了整个类加载过程。
在dalvik虚拟机中，虚拟机在首次加载dex的时候，会进行dexopt过程，进行预校验。具体来解释下抛出此异常的原因。当一个class文件和其直接引用的类在同一个dex中时，就会被打上CLASS_ISPREVERIFIED标记，而如果加载过程中，发现该类和其引用又不是在同一个dex中加载的，此时就会抛出该异常，该异常是由Resolve.cpp的dvmResolveClass函数定义的。在本文的例子中，插件apk中，PayServiceImpl引用了IPay接口并且他们都在同一个插件dex中，所以PayServiceImpl会被标记CLASS_ISPREVERIFIED，而IPay接口由双亲委派机制可以看出是由PathClassLoader在宿主apk中加载到的，此时虚拟机会认为IPay接口不在插件dex中，与之前标记的CLASS_ISPREVERIFIED冲突，从而抛出异常。很明显，当A类和其引用的B类如果不在同一个dex中，那么A类就不会被打上CLASS_ISPREVERIFIED标记，那么我们插件采用provided方式，则虚拟机会发现插件中没有IPay类，就不会对PayServiceImpl打标记了，也就不会再抛异常了。可参考文章安卓App热补丁动态修复技术介绍。这个问题就是QZone热更新方案所遇到的坑。有兴趣的可以了解下。

所以我们在插件开发中，尽量保证只在宿主（插件）中使用compile方式，而在插件可以（宿主）中使用provided进行依赖，就可以完全避免java.lang.IllegalAccessError: Class ref in pre-verified class resolved to unexpected implementation的产生。

下面我们使用分析好的方式继续探索。
2. PayService.jar在PluginPro采用provided方式，在HostPro中以compile的形式进行依赖，DexClassLoader的parent设置为系统默认的PathClassLoader

代码与上文中保持不变，可以正确的完成动态加载，但是我们尝试着将parent设置为ClassLoader.getSystemClassLoader()

 DexClassLoader classLoader=new DexClassLoader(src,des,null,ClassLoader.getSystemClassLoader());

再次运行，会发现结果又报错了。。。。

02-15 21:53:15.820 3070-3070/com.ljj.host W/System.err: java.lang.ClassNotFoundException: Didn't find class "com.ljj.plugin.serviceimpl.PayServiceImpl" on path: DexPathList[[zip file "/data/data/com.ljj.host/files/plugin.apk"],nativeLibraryDirectories=[/vendor/lib64, /system/lib64]]02-15 21:53:15.820 3070-3070/com.ljj.host W/System.err:     Caused by: java.lang.ClassNotFoundException: Didn't find class "com.ljj.test.interfaces.IPay" on path: DexPathList[[zip file "/data/data/com.ljj.host/files/plugin.apk"],nativeLibraryDirectories=[/vendor/lib64, /system/lib64]]

看log可以大致猜出来是由于没有加载到IPay接口，导致PayServiceImpl失败。宿主中明明有IPay接口，为什么会找不到呢，原因就在于我们的parent设置为了系统的pathClassLoader，前面分析了该类加载器的 DexPathList的路径为".",也就是什么都加载不到，接着会转由DexClassLoader去加载PayServiceImpl，要想成功加载PayServiceImpl，必须能够加载到IPay接口，而插件是以provided的方式依赖的PayService.jar，所以DexClassLoader无法成功加载PayServiceImpl，也就出现了log中所示内容。

3. PayService.jar在PluginPro和HostPro均以compile的形式进行依赖，DexClassLoader的parent设置为系统默认的PathClassLoader

02-15 22:16:35.750 19600-19600/com.ljj.host W/System.err: java.lang.ClassCastException: com.ljj.plugin.serviceimpl.PayServiceImpl cannot be cast to com.ljj.test.interfaces.IPay02-15 22:16:35.750 19600-19600/com.ljj.host W/System.err:     at com.ljj.host.MainActivity.onCreate(MainActivity.java:39)02-15 22:16:35.750 19600-19600/com.ljj.host W/System.err:     at android.app.Activity.performCreate(Activity.java:6013)

又出错了，这次报了java.lang.ClassCastException，首先需要明白，Java虚拟机不仅要看类的全名是否相同，还要看加载此类的类加载器是否一样。只有两者都相同的情况，才认为两个类是相同的。即便是同样的字节代码，被不同的类加载器加载之后所得到的类，也是不同的。当我们调用loadClass的时候，很明显，PayServiceImpl和其实现的接口IPay都是由DexClassLoader在插件apk中加载的，而执行到IPay payService=(IPay)instance;时，宿主apk中的IPay是由应用默认的PathClassLoader加载的，二者并不是同一个类，所以强转时会报错。

通过以上三种情况，主要是为了更加深刻的理解类加载器的知识，同时得出我们在开发插件时，尽量避免出现插件和宿主中都compile依赖，只保证compile一次，其他provided即可，此外在自定义DexClassLoader的parent时要特别注意，不能随意设置，一般设置成应用默认的classLoader。

关于android的类加载器相关知识就介绍到里，也可能有的地方理解的不到位，欢迎多多交流。

更多相关文章

随机推荐