热修复

最新推荐文章于 2024-07-01 12:07:03 发布

小李飞飞砖

最新推荐文章于 2024-07-01 12:07:03 发布

阅读量453

点赞数

分类专栏： android

本文链接：https://blog.csdn.net/shinecjj/article/details/84800889

版权

android 专栏收录该内容

38 篇文章 0 订阅

订阅专栏

文章目录

概述：
一、底层方法替换原理：
二、类加载原理：
二、主流热更新框架介绍

参考1

概述：

热修复有两种方式：一方面是阿里系为代表的底层方法替换，另一方面是以腾讯系为代表的类加载方案。前者支持立即生效，但是限制比较多；后者必须冷启动生效，相对较稳定，修复范围广。之前分析过微信的热修复框架 Tinker 即属于后者，《Tinker 接入及源码分析》。本篇文章主要分析以 AndFix 为代表的底层方法替换方案，并且实现了《深入探索 Android 热修复技术原理》中提到的方法替换新方案。

一、底层方法替换原理：

参考
方法替换是 AndFix 的热修复方案的关键，虚拟机在加载一个类的时候会将类中方法解析成 ArtMethod 结构体，结构体中保存着一些运行时的必要信息以及需要执行的指令指针地址。那么我们只要在 native 层将原方法的 ArtMethod 结构体替换成新方法的结构体，那么执行原方法的时候便会执行到新方法的指令，完成了方法替换。

二、类加载原理：

1、java类加载机制

http://liuwangshu.cn/application/classloader/1-java-classloader-.html

1、启动类加载器 BootStrapClassLoader
启动类加载器主要加载的是JVM自身需要的类，这个类加载使用C++语言实现的，负责加载<JAVA_HOME>/lib目录下的类，是虚拟机自身的一部分。

2、扩展类加载器 ExtensionClassLoader
扩展类加载器是由Java语言实现的，是Launcher的静态内部类，它负责加载<JAVA_HOME>/lib/ext目录下或者由系统变量-Djava.ext.dir指定位路径中的类库。

3、系统类加载器 SystemClassLoader
它负责加载系统类路径java -classpath或-D java.class.path 指定路径下的类库，也就是我们经常用到的classpath路径，开发者可以直接使用系统类加载器，一般情况下该类加载是程序中默认的类加载器，通过ClassLoader#getSystemClassLoader()方法可以获取到该类加载器。

4、自定义类加载器

1.JVM的类加载机制主要有如下3种。

全盘负责：所谓全盘负责，就是当一个类加载器负责加载某个Class时，该Class所依赖和引用其他Class也将由该类加载器负责载入，除非显示使用另外一个类加载器来载入。
双亲委派：所谓的双亲委派，则是先让父类加载器试图加载该Class，只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类。通俗的讲，就是某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父加载器，依次递归，如果父加载器可以完成类加载任务，就成功返回；只有父加载器无法完成此加载任务时，才自己去加载。
缓存机制。缓存机制将会保证所有加载过的Class都会被缓存，当程序中需要使用某个Class时，类加载器先从缓存区中搜寻该Class，只有当缓存区中不存在该Class对象时，系统才会读取该类对应的二进制数据，并将其转换成Class对象，存入缓冲区中。这就是为很么修改了Class后，必须重新启动JVM，程序所做的修改才会生效的原因。

2、这里说明一下双亲委派机制：

双亲委派机制，其工作原理的是，如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行，如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器，如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式，即每个儿子都很懒，每次有活就丢给父亲去干，直到父亲说这件事我也干不了时，儿子自己才想办法去完成。

双亲委派机制的优势：采用双亲委派模式的是好处是Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关可以避免类的重复加载，当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次。其次是考虑到安全因素，java核心api中定义类型不会被随意替换，假设通过网络传递一个名为java.lang.Integer的类，通过双亲委托模式传递到启动类加载器，而启动类加载器在核心Java API发现这个名字的类，发现该类已被加载，并不会重新加载网络传递的过来的java.lang.Integer，而直接返回已加载过的Integer.class，这样便可以防止核心API库被随意篡改。

2、Android类加载机制

在这里插入图片描述

1）、DexClassLoader 主要是加载一些dex文件，jar包，apk包；
2）、PathClassLoade 主要是用来加载系统类和应用的类；
BootClassLoader是在Zygote进程的入口方法中创建的，PathClassLoader则是在Zygote进程创建SystemServer进程时创建的。

public class BaseDexClassLoader extends ClassLoader {
    ...
    public BaseDexClassLoader(String dexPath, File optimizedDirectory, String libraryPath, ClassLoader parent){
        super(parent);
        this.pathList = new DexPathList(this, dexPath, libraryPath, optimizedDirectory);
    }
    ...
}

dexPath：要加载的程序文件（一般是dex文件，也可以是jar/apk/zip文件）所在目录。
optimizedDirectory：dex文件的输出目录（因为在加载jar/apk/zip等压缩格式的程序文件时会解压出其中的dex文件，该目录就是专门用于存放这些被解压出来的dex文件的）。
(不过，从Android 8.0开始，BaseDexClassLoader的构造函数逻辑发生了变化，optimizedDirectory过时，不再生效，详情可查看Android 8.0的BaseDexClassLoader.java源码)
libraryPath：加载程序文件时需要用到的库路径。
parent：父加载器

在这里插入图片描述

DexClassLoader
PathClassLoader
DexPathList
BaseDexClassLoader
总体来说，DexPathList的构造函数是将一个个的程序文件（可能是dex、apk、jar、zip）封装成一个个Element对象，最后添加到Element集合中。

final class DexPathList {
    private final Element[] dexElements;
    public DexPathList(ClassLoader definingContext, String dexPath, String libraryPath, File optimizedDirectory) {
        this.dexElements = makeDexElements(splitDexPath(dexPath), optimizedDirectory, suppressedExceptions);
    }
    //通过对splitDexPath(dexPath)的源码追溯，发现该方法的作用其实就是将dexPath目录下的所有程序文件转变成一个File集合。而且还发现，dexPath是一个用冒号（":"）作为分隔符把多个程序文件目录拼接起来的字符串(如：/data/dexdir1:/data/dexdir2:...)。

   private static Element[] makeDexElements(ArrayList<File> files, File optimizedDirectory, ArrayList<IOException> suppressedExceptions) {
    // 1.创建Element集合
    ArrayList<Element> elements = new ArrayList<Element>();
    // 2.遍历所有dex文件（也可能是jar、apk或zip文件）
    for (File file : files) {
        ZipFile zip = null;
        DexFile dex = null;
        String name = file.getName();
        ...
        // 如果是dex文件
        if (name.endsWith(DEX_SUFFIX)) {
            dex = loadDexFile(file, optimizedDirectory);

        // 如果是apk、jar、zip文件（这部分在不同的Android版本中，处理方式有细微差别）
        } else {
            zip = file;
            dex = loadDexFile(file, optimizedDirectory);
        }
        ...
        // 3.将dex文件或压缩文件包装成Element对象，并添加到Element集合中
        if ((zip != null) || (dex != null)) {
            elements.add(new Element(file, false, zip, dex));
        }
    }
    // 4.将Element集合转成Element数组返回
    return elements.toArray(new Element[elements.size()]);
}

//结合DexPathList的构造函数，其实DexPathList的findClass()方法很简单，就只是对Element数组进行遍历，一旦找到类名与name相同的类时，就直接返回这个class，找不到则返回null。

//为什么是调用DexFile的loadClassBinaryName()方法来加载class？这是因为一个Element对象对应一个dex文件，而一个dex文件则包含多个class。也就是说Element数组中存放的是一个个的dex文件，而不是class文件！！！这可以从Element这个类的源码和dex文件的内部结构看出。

public Class findClass(String name, List<Throwable> suppressed) {
    for (Element element : dexElements) {
        // 遍历出一个dex文件
        DexFile dex = element.dexFile;

        if (dex != null) {
            // 在dex文件中查找类名与name相同的类
            Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
            if (clazz != null) {
                return clazz;
            }
        }
    }
    return null;
}

 static class Element {
       private final File file;
       private final boolean isDirectory;
       private final File zip;
       private final DexFile dexFile;

       public Element(File file, boolean isDirectory, File zip, DexFile dexFile) {
            this.file = file;
            this.isDirectory = isDirectory;
            this.zip = zip;
            this.dexFile = dexFile;
 }

在这里插入图片描述

3、热修复实现原理

经过对PathClassLoader、DexClassLoader、BaseDexClassLoader、DexPathList的分析，我们知道，安卓的类加载器在加载一个类时会先从自身DexPathList对象中的Element数组中获取（Element[] dexElements）到对应的类，之后再加载。采用的是数组遍历的方式，不过注意，遍历出来的是一个个的dex文件。
在for循环中，首先遍历出来的是dex文件，然后再是从dex文件中获取class，所以，我们只要让修复好的class打包成一个dex文件，放于Element数组的第一个元素，这样就能保证获取到的class是最新修复好的class了（当然，有bug的class也是存在的，不过是放在了Element数组的最后一个元素中，所以没有机会被拿到而已）。

当ClassLoader加载到正确的类之后就不会去加载错误的类了，所以可以在dexElements中将正确的类放在错误类的前面就可以了。找到错误的类之后，将错误的类打包程dex文件，将其放在dexElements中的最前方。
在这里插入图片描述
例如：

/**
 * @创建者 CSDN_LQR
 * @描述 热修复工具(只认后缀是dex、apk、jar、zip的补丁)
 */
public class FixDexUtils {

    private static final String DEX_SUFFIX = ".dex";
    private static final String APK_SUFFIX = ".apk";
    private static final String JAR_SUFFIX = ".jar";
    private static final String ZIP_SUFFIX = ".zip";
    public static final String DEX_DIR = "odex";
    private static final String OPTIMIZE_DEX_DIR = "optimize_dex";
    private static HashSet<File> loadedDex = new HashSet<>();

    static {
        loadedDex.clear();
    }

    /**
     * 加载补丁，使用默认目录：data/data/包名/files/odex
     *
     * @param context
     */
    public static void loadFixedDex(Context context) {
        loadFixedDex(context, null);
    }

    /**
     * 加载补丁
     *
     * @param context       上下文
     * @param patchFilesDir 补丁所在目录
     */
    public static void loadFixedDex(Context context, File patchFilesDir) {
        if (context == null) {
            return;
        }
        // 遍历所有的修复dex
        File fileDir = patchFilesDir != null ? patchFilesDir : new File(context.getFilesDir(), DEX_DIR);// data/data/包名/files/odex（这个可以任意位置）
        File[] listFiles = fileDir.listFiles();
        for (File file : listFiles) {
            if (file.getName().startsWith("classes") &&
                    (file.getName().endsWith(DEX_SUFFIX)
                            || file.getName().endsWith(APK_SUFFIX)
                            || file.getName().endsWith(JAR_SUFFIX)
                            || file.getName().endsWith(ZIP_SUFFIX))) {
                loadedDex.add(file);// 存入集合
            }
        }
        // dex合并之前的dex
        doDexInject(context, loadedDex);
    }

    private static void doDexInject(Context appContext, HashSet<File> loadedDex) {
        String optimizeDir = appContext.getFilesDir().getAbsolutePath() + File.separator + OPTIMIZE_DEX_DIR;// data/data/包名/files/optimize_dex（这个必须是自己程序下的目录）
        File fopt = new File(optimizeDir);
        if (!fopt.exists()) {
            fopt.mkdirs();
        }
        try {
            // 1.加载应用程序的dex
            PathClassLoader pathLoader = (PathClassLoader) appContext.getClassLoader();
            for (File dex : loadedDex) {
                // 2.加载指定的修复的dex文件
                DexClassLoader dexLoader = new DexClassLoader(
                        dex.getAbsolutePath(),// 修复好的dex（补丁）所在目录
                        fopt.getAbsolutePath(),// 存放dex的解压目录（用于jar、zip、apk格式的补丁）
                        null,// 加载dex时需要的库
                        pathLoader// 父类加载器
                );
                // 3.合并
                Object dexPathList = getPathList(dexLoader);
                Object pathPathList = getPathList(pathLoader);
                Object leftDexElements = getDexElements(dexPathList);
                Object rightDexElements = getDexElements(pathPathList);
                // 合并完成
                Object dexElements = combineArray(leftDexElements, rightDexElements);
                // 重写给PathList里面的Element[] dexElements;赋值
                Object pathList = getPathList(pathLoader);// 一定要重新获取，不要用pathPathList，会报错
                setField(pathList, pathList.getClass(), "dexElements", dexElements);
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    /**
     * 反射给对象中的属性重新赋值
     */
    private static void setField(Object obj, Class<?> cl, String field, Object value) throws NoSuchFieldException, IllegalAccessException {
        Field declaredField = cl.getDeclaredField(field);
        declaredField.setAccessible(true);
        declaredField.set(obj, value);
    }

    /**
     * 反射得到对象中的属性值
     */
    private static Object getField(Object obj, Class<?> cl, String field) throws NoSuchFieldException, IllegalAccessException {
        Field localField = cl.getDeclaredField(field);
        localField.setAccessible(true);
        return localField.get(obj);
    }


    /**
     * 反射得到类加载器中的pathList对象
     */
    private static Object getPathList(Object baseDexClassLoader) throws ClassNotFoundException, NoSuchFieldException, IllegalAccessException {
        return getField(baseDexClassLoader, Class.forName("dalvik.system.BaseDexClassLoader"), "pathList");
    }

    /**
     * 反射得到pathList中的dexElements
     */
    private static Object getDexElements(Object pathList) throws NoSuchFieldException, IllegalAccessException {
        return getField(pathList, pathList.getClass(), "dexElements");
    }

    /**
     * 数组合并
     */
    private static Object combineArray(Object arrayLhs, Object arrayRhs) {
        Class<?> componentType = arrayLhs.getClass().getComponentType();
        int i = Array.getLength(arrayLhs);// 得到左数组长度（补丁数组）
        int j = Array.getLength(arrayRhs);// 得到原dex数组长度
        int k = i + j;// 得到总数组长度（补丁数组+原dex数组）
        Object result = Array.newInstance(componentType, k);// 创建一个类型为componentType，长度为k的新数组
        System.arraycopy(arrayLhs, 0, result, 0, i);
        System.arraycopy(arrayRhs, 0, result, i, j);
        return result;
    }
}

二、主流热更新框架介绍

参考

1、Tinker

在这里插入图片描述
通过修复好的 class.dex 和原有的 class.dex 比较差生差量包补丁文件 patch.dex，在手机上这个 patch.dex 会和原有的 class.dex 合并生成新的文件 fix_class.dex，用这个新的 fix_class.dex 整体替换原有的 dexPathList 的中的内容，这是从根本上把 bug 给干掉了

至于两个 dex 是如何比较得出差异化文件 patch.dex 还有如何合并的，就是 Tinker 的核心算法 DexDiff / DexPatch 了

值得注意的是：

Tinker 可以新增字段、新增类，但不支持新增四大组件
在下次进程启动时 patch 才会生效，patch 安装好后应用会闪退

3、AndFix

AndFix 提供了一种在 Native 层实现方法替换的解决方案
在这里插入图片描述
AndF 只能修复方法级别的 bug，在比较生成的 patch 中，AndFix 会用注解标注那些修改过的方法。在加载 patch 时，AndFix 首先通过注解找到所有需要被替换的方法，接着通过 jni 的方式在 Native 层对 dex 文件进行操作，实现方法的替换，这种方式可以达到即时生效无需重启的效果。
对于 Native 层具体是如何操作的，由于对 Native 不熟悉，此处略去不表

值得注意的是：

AndFix 只能修复方法级别的 bug，不能新增类和字段
由于 AndFix 是在 Native 层进行的操作，而国内各大手机厂商又喜欢定制自己的 ROM，所以很多底层实现的差异，导致 AndFix 的兼容性并不是很好。

4、Nuwa

小李飞飞砖

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
热修复

文章目录一、热更新的流程二、主流热更新框架介绍1、Dexposed2、AndFix3、Nuwa三、热更新原理1、Android类加载机制2、热修复机制一、热更新的流程二、主流热更新框架介绍1、Dexposed2、AndFix3、Nuwa三、热更新原理1、Android类加载机制1）、DexClassLoader 主要是加载一些dex文件，jar包，apk包；2）、PathCla...
复制链接

扫一扫