Android热修复及插件化原理

1.前言

热修复一直是这几年来很热门的话题，主流方案大致有两种，一种是微信Tinker的dex文件替换，另一种是阿里的Native层的方法替换。这里重点介绍Tinker的大致原理。

2.类加载机制

介绍Tinker原理之前，我们先来回顾一下类加载机制。

我们编译好的class文件，需要先加载到虚拟机然后才会执行，这个过程是通过ClassLoader来完成的。

双亲委派模型：

• 1.加载某个类的时候，这个类加载器不会自己立刻去加载，它会委托给父类去加载
• 2.如果这个父类还存在父类加载器，则进一步委托，直到最顶层的类加载器
• 3.如果父类加载器可以完成加载任务，就成功返回，否则就再委派给子类加载器
• 4.如果都未加载成功就抛出ClassNotFoundException

作用：
1.避免类的重复加载。
比如有两个类加载器，他们都要加载同一个类，这时候如果不是委托而是自己加载自己的，则会将类重复加载到方法区。
2.避免核心类被修改。
比如我们在自定义一个 java.lang.String 类，执行的时候会报错，因为 String 是 java.lang 包下的类，应该由启动类加载器加载。

JVM并不会一开始就加载所有的类，它是当你使用到的时候才会去通知类加载器去加载。

3.Android类加载

当我们new一个类时，首先是Android的虚拟机（Dalvik/ART虚拟机）通过ClassLoader去加载dex文件到内存。
Android中的ClassLoader主要是PathClassLoader和DexClassLoader,这两者都继承自BaseDexClassLoader。它们都可以理解成应用类加载器。

PathClassLoader和DexClassLoader的区别：

• PathClassLoader只能指定加载apk包路径，不能指定dex文件解压路径。该路径是写死的在/data/dalvik-cache/路径下。所以只能用于加载已安装的apk。

• DexClassLoader可以指定apk包路径和dex文件解压路径（加载jar、apk、dex文件）

当ClassLoader加载类时，会调用它的findclass方法去查找该类。
下方是BaseDexClassLoader的findClass方法实现：

public class BaseDexClassLoader extends ClassLoader {
   
   
...

    @UnsupportedAppUsage
    private final DexPathList pathList;

    ...

     @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
   
   
        // 首先检查该类是否存在shared libraries中.
        if (sharedLibraryLoaders != null) {
   
   
            for (ClassLoader loader : sharedLibraryLoaders) {
   
   
                try {
   
   
                    return loader.loadClass(name);
                } catch (ClassNotFoundException ignored) {
   
   
                }
            }
        }
        //再调用pathList.findClass去查找该类，结果为null则抛出错误。
        List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
        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;
    }
}

接下来我们再来看看DexPathList的findClass实现：

 public DexPathList(ClassLoader definingContext, String librarySearchPath) {
   
   
...
    /**
     * List of dex/resource (class path) elements.
     * 存放dex文件的一个数组
     */
    @UnsupportedAppUsage
    private Element[] dexElements;

...

    public Class<?> findClass(String name, List<Throwable> suppressed) {
   
   
     	 //遍历Element数组，去查寻对应的类，找到后就立刻返回了
        for (Element element : dexElements) {
   
   
            Class<?> clazz = element.findClass(name, definingContext, suppressed);
            if (clazz != null) {
   
   
                return clazz;
            }
        }

        if (dexElementsSuppressedExceptions != null) {
   
   
            suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
        }
        return null;
    }
...
}

4.Tinker原理

• 1.使用DexClassLoader加载补丁包的dex文件
• 2.通过反射获取DexClassLoader类的pathList，再次通过反射获得dexElements数组。
• 3.获取加载应用类的PathClassLoader，同样通过反射获取它的dexElements数组。
• 4.合并两个dexElements数组，且将补丁包的dex文件放在前面。
  根据类加载机制，一个类只会被加载一次，DexPathList.findClass方法中是顺序遍历数组，所以将补丁的dex文件放在前面，这样bug修复类会被优先加载，而原来的bug类不会被加载，达到了替换bug类的功能（补丁包中的修复类名、包名要和bug类相同）
• 5.再次通过反射将合并后的dexElements数组赋值给PathClassLoader.dexElements属性。
  加载类时，Dalvik/ART虚拟机会通过PathClassLoader去查找已安装的apk文件中的类。

Ok，这样就替换成功了，重启App，再调用原来的bug类，将会优先使用补丁包中的修复类。
为什么要重启：因为双亲委派模型，一个类只会被ClassLoader加载一次，且加载过后的类不能卸载。

代码实现

接下来我们动手撸一个乞丐版的Tinker。
首先我们写一个bug类。

package com.baima.plugin;

class BugClass {
   
   
    public String getTitle(){
   
   
        return "这是个Bug";
    }
}

接着我们新建一个module来生成补丁包apk。