热修复——深入浅出原理与实现

热修复——深入浅出原理与实现热修复无疑是这2年较火的新技术,是作为安卓工程师必学的技能之一。在热修复出现之前,一个已经上线的app中如果出现了bug,即使是一个非常小的bug,不及时更新的话有可能存在风险,若要及时更新就得将app重新打包发布到应用市场后,让用户再一次下载,这样就大大降低了用户体验,当热修…

一、简述

热修复无疑是这2年较火的新技术,是作为安卓工程师必学的技能之一。在热修复出现之前,一个已经上线的app中如果出现了bug,即使是一个非常小的bug,不及时更新的话有可能存在风险,若要及时更新就得将app重新打包发布到应用市场后,让用户再一次下载,这样就大大降低了用户体验,当热修复出现之后,这样的问题就不再是问题了。

目前较火的热修复方案大致分为两派,分别是:

  1. 阿里系:DeXposed、andfix:从底层二进制入手(c语言)。
  2. 腾讯系:tinker:从java加载机制入手。

本篇的主题并非讲述上面两种方案的使用,而是基于java加载机制,来研究热修复的原理与实现。(类似tinker,当然tinker没这么简单)

二、Android中如何动态修复bug

关于bug的概念自己百度百科吧,我认为的bug一般有2种(可能不太准确):

  • 代码功能不符合项目预期,即代码逻辑有问题。
  • 程序代码不够健壮导致App运行时崩溃。

这两种情况一般是一个或多个class出现了问题,在一个理想的状态下,我们只需将修复好的这些个class更新到用户手机上的app中就可以修复这些bug了。但说着简单,要怎么才能动态更新这些class呢?其实,不管是哪种热修复方案,肯定是如下几个步骤:

  1. 下发补丁(内含修复好的class)到用户手机,即让app从服务器上下载(网络传输)
  2. app通过**”某种方式”**,使补丁中的class被app调用(本地更新)

这里的**”某种方式”**,对本篇而言,就是使用Android的类加载器,通过类加载器加载这些修复好的class,覆盖对应有问题的class,理论上就能修复bug了。所以,下面就先来了解和分析Android中的类加载器吧。

三、Android中的类加载器

Android跟java有很大的渊源,基于jvm的java应用是通过ClassLoader来加载应用中的class的,但我们知道Android对jvm优化过,使用的是dalvik,且class文件会被打包进一个dex文件中,底层虚拟机有所不同,那么它们的类加载器当然也是会有所区别,在Android中,要加载dex文件中的class文件就需要用到 PathClassLoaderDexClassLoader 这两个Android专用的类加载器。

1、源码查看

一般的源码在Android Studio中可以查到,但 PathClassLoaderDexClassLoader 的源码是属于系统级源码,所以无法在Android Studio中直接查看。不过,有两种方式可以在外部进行查看:第一种是通过下载Android镜像源码的方式进行查看,但一般镜像源码体积较大,不好下载,而且就只是为了看3、4个文件的源码动不动就下载3、4个g的源码,确实不太明智,所以我们一般采用第二种方式:到androidxref.com这个网站上直接查看,下面会列出之后要分析的几个类的源码地址,供看客们方便浏览。

以下是Android 5.0中的部分源码:

2、PathClassLoader与DexClassLoader的区别

1)使用场景

  • PathClassLoader:只能加载已经安装到Android系统中的apk文件(/data/app目录),是Android默认使用的类加载器。
  • DexClassLoader:可以加载任意目录下的dex/jar/apk/zip文件,比PathClassLoader更灵活,是实现热修复的重点。

2)代码差异

因为PathClassLoader与DexClassLoader的源码都很简单,我就直接将它们的全部源码复制过来了:

// PathClassLoader
public class PathClassLoader extends BaseDexClassLoader {
    public PathClassLoader(String dexPath, ClassLoader parent) {
        super(dexPath, null, null, parent);
    }

    public PathClassLoader(String dexPath, String librarySearchPath, ClassLoader parent) {
        super(dexPath, null, librarySearchPath, parent);
    }
}

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

通过比对,可以得出2个结论:

  • PathClassLoader与DexClassLoader都继承于BaseDexClassLoader。
  • PathClassLoader与DexClassLoader在构造函数中都调用了父类的构造函数,但DexClassLoader多传了一个optimizedDirectory。
热修复——深入浅出原理与实现

3、BaseDexClassLoader

通过观察PathClassLoader与DexClassLoader的源码我们就可以确定,真正有意义的处理逻辑肯定在BaseDexClassLoader中,所以下面着重分析BaseDexClassLoader源码。

1)构造函数

先来看看BaseDexClassLoader的构造函数都做了什么:

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文件的)。
  • libraryPath:加载程序文件时需要用到的库路径。
  • parent:父加载器

***tip:**上面说到的”程序文件”这个概念是我自己定义的,因为从一个完整App的角度来说,程序文件指定的就是apk包中的classes.dex文件;但从热修复的角度来看,程序文件指的是补丁。

因为PathClassLoader只会加载已安装包中的dex文件,而DexClassLoader不仅仅可以加载dex文件,还可以加载jar、apk、zip文件中的dex,我们知道jar、apk、zip其实就是一些压缩格式,要拿到压缩包里面的dex文件就需要解压,所以,DexClassLoader在调用父类构造函数时会指定一个解压的目录。

不过,从Android 8.0开始,BaseDexClassLoader的构造函数逻辑发生了变化,optimizedDirectory过时,不再生效,详情可查看Android 8.0的BaseDexClassLoader.java源码

2)获取class

类加载器肯定会提供有一个方法来供外界找到它所加载到的class,该方法就是findClass(),不过在PathClassLoader和DexClassLoader源码中都没有重写父类的findClass()方法,但它们的父类BaseDexClassLoader就有重写findClass(),所以来看看BaseDexClassLoader的findClass()方法都做了哪些操作,代码如下:

private final DexPathList pathList;

@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
    List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
	// 实质是通过pathList的对象findClass()方法来获取class
    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;
}

可以看到,BaseDexClassLoader的findClass()方法实际上是通过DexPathList对象(pathList)的findClass()方法来获取class的,而这个DexPathList对象恰好在之前的BaseDexClassLoader构造函数中就已经被创建好了。所以,下面就来看看DexPathList类中都做了什么。

热修复——深入浅出原理与实现

4、DexPathList

在分析一个代码量较多的源码之前,我们要明确要从这段源码中要知道些什么?这样才不会在“码海”中迷失方向,我自己就定了2个小目标,分别是:

  • DexPathList的构造函数做了什么事?
  • DexPathList的findClass()方法是怎么获取class的?

为什么是这2个目标?因为在BaseDexClassLoader的源码中主要就用到了DexPathList的构造函数和findClass()方法。

1)构造函数

private final Element[] dexElements;

public DexPathList(ClassLoader definingContext, String dexPath, String libraryPath, File optimizedDirectory) {
    ...
	this.definingContext = definingContext;
    this.dexElements = makeDexElements(splitDexPath(dexPath), optimizedDirectory,suppressedExceptions);
    ...
}

这个构造函数中,保存了当前的类加载器definingContext,并调用了makeDexElements()得到Element集合。

通过对splitDexPath(dexPath)的源码追溯,发现该方法的作用其实就是将dexPath目录下的所有程序文件转变成一个File集合。而且还发现,dexPath是一个用冒号(”:”)作为分隔符把多个程序文件目录拼接起来的字符串(如:/data/dexdir1:/data/dexdir2:…)。

那接下来无疑是分析makeDexElements()方法了,因为这部分代码比较长,我就贴出关键代码,并以注释的方式进行分析:

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的构造函数是将一个个的程序文件(可能是dex、apk、jar、zip)封装成一个个Element对象,最后添加到Element集合中。

其实,Android的类加载器(不管是PathClassLoader,还是DexClassLoader),它们最后只认dex文件,而loadDexFile()是加载dex文件的核心方法,可以从jar、apk、zip中提取出dex,但这里先不分析了,因为第1个目标已经完成,等到后面再来分析吧。

2)findClass()

再来看DexPathList的findClass()方法:

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;
            }
        }
    }
    if (dexElementsSuppressedExceptions != null) {
        suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
    }
    return null;
}

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

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

热修复——深入浅出原理与实现

四、热修复的实现原理

  终于进入主题了,经过对PathClassLoader、DexClassLoader、BaseDexClassLoader、DexPathList的分析,我们知道,安卓的类加载器在加载一个类时会先从自身DexPathList对象中的Element数组中获取(Element[] dexElements)到对应的类,之后再加载。采用的是数组遍历的方式,不过注意,遍历出来的是一个个的dex文件。

  在for循环中,首先遍历出来的是dex文件,然后再是从dex文件中获取class,所以,我们只要让修复好的class打包成一个dex文件,放于Element数组的第一个元素,这样就能保证获取到的class是最新修复好的class了(当然,有bug的class也是存在的,不过是放在了Element数组的最后一个元素中,所以没有机会被拿到而已)。

热修复——深入浅出原理与实现

五、热修复的简单实现

通过前面的一堆理论之后,是时候实践一把了。

1、得到dex格式补丁

1)修复好有问题的java文件

这一步根据bug的实际情况修改代码即可。

2)将java文件编译成class文件

在修复bug之后,可以使用Android Studio的Rebuild Project功能将代码进行编译,然后从build目录下找到对应的class文件。

热修复——深入浅出原理与实现

将修复好的class文件复制到其他地方,例如桌面上的dex文件夹中。需要注意的是,在复制这个class文件时,需要把它所在的完整包目录一起复制。假设上图中修复好的class文件是SimpleHotFixBugTest.class,则到时复制出来的目录结构是:

热修复——深入浅出原理与实现

3)将class文件打包成dex文件

a. dx指令程序

要将class文件打包成dex文件,就需要用到dx指令,这个dx指令类似于java指令。我们知道,java的指令有javac、jar等等,之所以可以使用这类指令,是因为我们有安装过jdk,jdk为我们提供了java指令,相同的,dx指令也需要有程序来提供,它就在Android SDK的build-tools目录下各个Android版本目录之中。

热修复——深入浅出原理与实现

b. dx指令的使用

dx指令的使用跟java指令的使用条件一样,有2种选择:

  • 配置环境变量(添加到classpath),然后命令行窗口(终端)可以在任意位置使用。
  • 不配环境变量,直接在build-tools/安卓版本 目录下使用命令行窗口(终端)使用。

第一种方式参考java环境变量配置即可,这里我选用第二种方式。下面我们需要用到的命令是:

dx –dex –output=dex文件完整路径 (空格) 要打包的完整class文件所在目录,如:

dx –dex –output=C:\Users\Administrator\Desktop\dex\classes2.dex C:\Users\Administrator\Desktop\dex

具体操作看下图:

热修复——深入浅出原理与实现

在文件夹目录的空白处,按住shift+鼠标右击,可出现“在此处打开命令行窗口”。

2、加载dex格式补丁

根据原理,可以做一个简单的工具类:

/** * @创建者 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)Class ref in pre-verified class resolved to unexpected implementation

经反馈,这个是大家遇到的最多的一个问题,这里我把注意事项和我的解决方法写清楚:

a.FixDexUtils

// 合并完成
Object dexElements = combineArray(leftDexElements, rightDexElements);
// 重写给PathList里面的Element[] dexElements;赋值
Object pathList = getPathList(pathLoader);// 一定要重新获取,不要用pathPathList,会报错
setField(pathList, pathList.getClass(), "dexElements", dexElements);

在合并守Element数组后,一定要再重新获取一遍App中的原有的pathList,不要复用前面的pathPathList,绝对会报错(Class ref in pre-verified class resolved to unexpected implementation)。

b.Instant Run

Android Studio的Instant Run功能也是用到了热修复的原理,在重新安装app时并不会完整安装,只会动态修改有更新的class部分,它会影响到测试结果,在跟着本文做试验的同学请确保Instant Run已经关闭。

热修复——深入浅出原理与实现

c.模拟器

我在测试的过程中,使用的是Genymotion,发现Android 4.4的模拟器一直无法打上补丁,但是Android 5.0的模拟器却可以,真机测试也没问题,所以建议不要使用Android 5.0以下的模拟器来测试,强烈建议用真机测试!!

2)dexPath与optimizedDirectory的目录问题

DexClassLoader dexLoader = new DexClassLoader(
        dex.getAbsolutePath(),// 修复好的dex(补丁)所在目录
        fopt.getAbsolutePath(),// 存放dex的解压目录(用于jar、zip、apk格式的补丁)
        null,// 加载dex时需要的库
        pathLoader// 父类加载器

上面的代码是创建一个DexClassLoader对象,其中第1个和第2个参数有个细节需要注意:

  • 参数1是dexPath,指的是补丁所有目录,可以是多个目录(用冒号拼接),而且可以是任意目录,比如说SD卡。
  • 参数2是optimizedDirectory,就是存放从压缩包时解压出来的dex文件的目录,但不能是任意目录,它必须是程序所属的目录才行,比如:data/data/包名/xxx。

如果你把optimizedDirectory指定成SD卡目录,则会报如下错误:

热修复——深入浅出原理与实现

java.lang.IllegalArgumentException: Optimized data directory /storage/emulated/0/opt_dex is not owned by the current user. Shared storage cannot protect your application from code injection attacks.

意思是说SD卡目录不属于当前用户。此外,这里再校正之前的一个小问题,optimizedDirectory不仅仅存放从压缩包出来的dex文件,如果补丁文件就是一个dex文件,那么它也会将这个补丁文件复制到optimizedDirectory目录下。

3、加载jar、apk、zip格式补丁

前面已经说了很多次DexClassLoader可以加载jar、apk、zip格式补丁文件了,那这类格式的补丁文件有什么要求吗?
答案是:这类压缩包中必须放着一个dex文件,而且对名字有要求,必须是classes.dex。Why?这就需要分析DexPathList类中的loadDexFile()方法了。

private static DexFile loadDexFile(File file, File optimizedDirectory) throws IOException {
	// 如果optimizedDirectory为null,其实就是PathClassLoader加载dex文件的处理方式
    if (optimizedDirectory == null) {
        return new DexFile(file);
    } 
	// 如果optimizedDirectory不是null,这就是DexClassLoader加载dex文件的处理方式了,重点看这个
	else {
        String optimizedPath = optimizedPathFor(file, optimizedDirectory);
        return DexFile.loadDex(file.getPath(), optimizedPath, 0);
    }
}

参数一file,可能是dex文件,也可能是jar、apk、zip文件。

从上面的源码中,不难看出else分支才是DexClassLoader加载dex文件的处理方式,它调用的是optimizedPathFor()方法拿到之后dex文件在optimizedDirectory目录下的全路径:

private static String optimizedPathFor(File path, File optimizedDirectory) {
    String fileName = path.getName();
    if (!fileName.endsWith(DEX_SUFFIX)) {
        int lastDot = fileName.lastIndexOf(".");
		// 如果补丁没有后缀,就给它加一个".dex"后缀
        if (lastDot < 0) {
            fileName += DEX_SUFFIX;
        } 
		// 不管补丁后缀是dex、jar、apk还是zip,最终放到optimizedDirectory目录下的一定是dex文件
		else {
            StringBuilder sb = new StringBuilder(lastDot + 4);
            sb.append(fileName, 0, lastDot);
            sb.append(DEX_SUFFIX);
            fileName = sb.toString();
        }
    }

    File result = new File(optimizedDirectory, fileName);
    return result.getPath();
}

前面已经说过了,Android的类加载器最终只认dex文件,即使补丁是jar、apk、zip等压缩文件,它也会把其中的dex文件解压出来,所以该方法得到的文件名一定是以dex结尾的。好了,这个optimizedPathFor()方法并不是重点,回头看loadDexFile()中的else分支还有一个DexFile.loadDex()方法,这个方法就相当重要了。

static public DexFile loadDex(String sourcePathName, String outputPathName, int flags) throws IOException {
    return new DexFile(sourcePathName, outputPathName, flags);
}

这个方法中就调用了一下自己的构造函数,并传入各个参数,接着来看看DexFile的构造函数:

/** * Open a DEX file, specifying the file in which the optimized DEX * data should be written. If the optimized form exists and appears * to be current, it will be used; if not, the VM will attempt to * regenerate it. * * This is intended for use by applications that wish to download * and execute DEX files outside the usual application installation * mechanism. This function should not be called directly by an * application; instead, use a class loader such as * dalvik.system.DexClassLoader. * * @param sourcePathName * Jar or APK file with "classes.dex". (May expand this to include * "raw DEX" in the future.) * @param outputPathName * File that will hold the optimized form of the DEX data. * @param flags * Enable optional features. (Currently none defined.) * @return * A new or previously-opened DexFile. * @throws IOException * If unable to open the source or output file. */
private DexFile(String sourceName, String outputName, int flags) throws IOException {
    if (outputName != null) {
        try {
            String parent = new File(outputName).getParent();
            if (Libcore.os.getuid() != Libcore.os.stat(parent).st_uid) {
                throw new IllegalArgumentException("Optimized data directory " + parent
                        + " is not owned by the current user. Shared storage cannot protect"
                        + " your application from code injection attacks.");
            }
        } catch (ErrnoException ignored) {
            // assume we'll fail with a more contextual error later
        }
    }

    mCookie = openDexFile(sourceName, outputName, flags);
    mFileName = sourceName;
    guard.open("close");
    //System.out.println("DEX FILE cookie is " + mCookie + " sourceName=" + sourceName + " outputName=" + outputName);
}

奇怪吗,这次我没有把构造函数的注释去掉,原因是在它的注释中就已经有我们想要的答案了:

@param sourcePathName Jar or APK file with "classes.dex".  (May expand this to include "raw DEX" in the future.)

这名注释的意思就是说,jar或apk格式的补丁文件中需要有一个classes.dex。至此,对于压缩格式的补丁文件的要求就弄明白了。那么接下来就只需要生成这几种格式的补丁试一试就好了。制作这类压缩文件也很简单,直接用压缩软件压缩成zip文件,然后改下后缀就可以。

六、测试

这部分其实本不想写的,因为比较简单,但想了想不写又觉得不完整,那接下来就来测试一波吧。

1、代码

1)Activity

布局文件就俩按钮,很简单就不贴布局文件代码了,看这两个按钮的点击事件就行。

public class SimpleHotFixActivity extends AppCompatActivity {

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_simple_hot_fix);
    }

	// “修复”按钮的点击事件
    public void fix(View view) {
        FixDexUtils.loadFixedDex(this, Environment.getExternalStorageDirectory());
    }

	// “计算”按钮的点击事件
    public void clac(View view) {
        SimpleHotFixBugTest test = new SimpleHotFixBugTest();
        test.getBug(this);
    }
}

可以看到,“修复”按钮的点击事件是去加载SD卡目录下的补丁文件。

2)SimpleHotFixBugTest

public class SimpleHotFixBugTest {
    public void getBug(Context context) {
        int i = 10;
        int a = 0;
        Toast.makeText(context, "Hello,I am CSDN_LQR:" + i / a, Toast.LENGTH_SHORT).show();
    }
}

会发生什么事呢?除数是0异常,一个简单的运行时异常,修复它也很简单,把a的值改为非0即可。

2、演示

1、bug

不多说,看操作。

热修复——深入浅出原理与实现

妥妥的ArithmeticException。

Caused by: java.lang.ArithmeticException: divide by zero

热修复——深入浅出原理与实现

2、动态修复bug

首先,我将补丁文件classes2.dex放到手机的SD目录下。

热修复——深入浅出原理与实现

然后先点击修复按钮,再点计算按钮。

热修复——深入浅出原理与实现

大功告成,压缩格式的补丁跟dex格式的补丁一样,直接丢掉SD卡目录下就行了,但一定要注意,压缩格式的补丁中的文件一定是classes.dex!!!

最后贴下Demo地址

github.com/GitLqr/HotF…

权限申请:本文的提供的Demo是读取SD卡下的补丁文件,但却没有为Android6.0以上适配动态权限申请,如果你有使用该demo进行测试,那要注意自己测试机的Android版本,若是6.0以上,请务必先为Demo分配SD卡读写操作权限,否则App崩溃都不知道是不是因为bug造成的 ,切记。

热修复——深入浅出原理与实现

欢迎关注微信公众号:全栈行动

今天的文章热修复——深入浅出原理与实现分享到此就结束了,感谢您的阅读。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/19712.html

(0)
编程小号编程小号

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注