Android进阶（八）热修复基本原理

时间 2019-11-07

原文原文链接

1、代码修复

一、类加载方案

（1）Dex分包原理

单个Dex文件里面方法数不能超过65536个方法。java

（1）缘由：
由于android会把每个类的方法id检索起来，存在一个链表结构里面。可是这个链表的长度是用一个short类型来保存的， short占两个字节（保存-2的15次方到2的15次方-1，即-32768~32767），最大保存的数量就是65536。android

（2）解决方案：数组

精简方法数量,删除没用到的类、方法、第三方库。
使用ProGuard去掉一些未使用的代码
对部分模块采用本地插件化的方式。
分割Dex

Dex分包方案主要作的是在打包时将应用代码分红多个Dex，将应用启动时必须用到的类和这些类的直接引用类放到主Dex中，其余代码放到次Dex中。当应用启动时先加载主Dex，等到应用启动后再动态的加载次Dex。bash

（2）类加载修复方案

若是Key.Class文件中存在异常，将该Class文件修复后，将其打入Patch.dex的补丁包
(1) 方案一：
经过反射获取到PathClassLoader中的DexPathList，而后再拿到 DexPathList中的Element数组，将Patch.dex放在Element数组dexElements的第一个元素，最后将数组进行合并后并从新设置回去。在进行类加载的时候，因为ClassLoader的双亲委托机制，该类只被加载一次，也就是说Patch.dex中的Key.Class会被加载。微信

(2)方案二：
提供dex差量包patch.dex,将patch.dex与应用的classes.dex合并成一个完整的dex，完整dex加载后获得dexFile对象，做为参数构建一个Element对象，而后总体替换掉旧的dex-Elements数组。（Tinker）

（3）类加载方案的限制

方案一：框架

因为类是没法进行卸载，因此类若是须要从新加载，则须要重启App，因此类加载修复方案不是即时生效的。
在ART模式下，若是类修改告终构，就会出现内存错乱的问题。为了解决这个问题，就必须把全部相关的调用类、父类子类等等所有加载到patch.dex中，致使补丁包大，耗时严重。

方案二：性能

下次启动修复
dex合并内存消耗可能致使OOM，最终dex合并失败

二、底层替换方案

（1）基本方案

主要是在Native层替换原有方法，ArtMethod结构体中包含了Java方法的全部信息，包括执行入口、访问权限、所属类和代码执行地址等。替换ArtMethod结构体中的字段或者替换整个ArtMethod结构体，就是底层替换方案。因为直接替换了方法，能够当即生效不须要重启。gradle

（2）优缺点

（1）缺点ui

不可以增减原有类的方法和字段，若是咱们增长了方法数，那么方法索引数也会增长，这样访问方法时会没法经过索引找到正确的方法。
平台兼容性问题，若是厂商对ArtMethod结构体进行了修改，替换机制就有问题。

（2）优势this

Bug修复的即时性
生成的PATCH体积小，性能影响低

2、资源修复

一、Instant Run

核心代码:runtime/MonkeyPatcher.java

#MonkeyPatcher
public static void monkeyPatchExistingResources(@Nullable Context context,
                                                @Nullable String externalResourceFile,
                                                @Nullable Collection<Activity> activities) {
    ......                                        
    try {
        // Create a new AssetManager instance and point it to the resources installed under
        // (1)经过反射建立了一个newAssetManager，调用addAssetPath添加了sdcard上的资源包
        AssetManager newAssetManager = AssetManager.class.getConstructor().newInstance();
        Method mAddAssetPath = AssetManager.class.getDeclaredMethod("addAssetPath", String.class);
        mAddAssetPath.setAccessible(true);
        if (((Integer) mAddAssetPath.invoke(newAssetManager, externalResourceFile)) == 0) {
            throw new IllegalStateException("Could not create new AssetManager");
        }
        // Kitkat needs this method call, Lollipop doesn't. However, it doesn't seem to cause any harm
        // in L, so we do it unconditionally.
        Method mEnsureStringBlocks = AssetManager.class.getDeclaredMethod("ensureStringBlocks");
        mEnsureStringBlocks.setAccessible(true);
        mEnsureStringBlocks.invoke(newAssetManager);
        if (activities != null) {
            //(2)反射获取Activity中AssetManager的引用，替换成新建立的newAssetManager
            for (Activity activity : activities) {
                Resources resources = activity.getResources();
                try {
                    Field mAssets = Resources.class.getDeclaredField("mAssets");
                    mAssets.setAccessible(true);
                    mAssets.set(resources, newAssetManager);
                } catch (Throwable ignore) {
                    Field mResourcesImpl = Resources.class.getDeclaredField("mResourcesImpl");
                    mResourcesImpl.setAccessible(true);
                    Object resourceImpl = mResourcesImpl.get(resources);
                    Field implAssets = resourceImpl.getClass().getDeclaredField("mAssets");
                    implAssets.setAccessible(true);
                    implAssets.set(resourceImpl, newAssetManager);
                }
                Resources.Theme theme = activity.getTheme();
                try {
                    try {
                        Field ma = Resources.Theme.class.getDeclaredField("mAssets");
                        ma.setAccessible(true);
                        ma.set(theme, newAssetManager);
                    } catch (NoSuchFieldException ignore) {
                        Field themeField = Resources.Theme.class.getDeclaredField("mThemeImpl");
                        themeField.setAccessible(true);
                        Object impl = themeField.get(theme);
                        Field ma = impl.getClass().getDeclaredField("mAssets");
                        ma.setAccessible(true);
                        ma.set(impl, newAssetManager);
                    }
                ......
        }
        //(3)遍历Resource弱引用的集合，将AssetManager替换成newAssetManager
        for (WeakReference<Resources> wr : references) {
            Resources resources = wr.get();
            if (resources != null) {
                // Set the AssetManager of the Resources instance to our brand new one
                try {
                    Field mAssets = Resources.class.getDeclaredField("mAssets");
                    mAssets.setAccessible(true);
                    mAssets.set(resources, newAssetManager);
                } catch (Throwable ignore) {
                    Field mResourcesImpl = Resources.class.getDeclaredField("mResourcesImpl");
                    mResourcesImpl.setAccessible(true);
                    Object resourceImpl = mResourcesImpl.get(resources);
                    Field implAssets = resourceImpl.getClass().getDeclaredField("mAssets");
                    implAssets.setAccessible(true);
                    implAssets.set(resourceImpl, newAssetManager);
                }
                resources.updateConfiguration(resources.getConfiguration(), resources.getDisplayMetrics());
            }
        }
    } catch (Throwable e) {
        throw new IllegalStateException(e);
    }
}
复制代码

反射构建新的AssetManager，并反射调用addAssertPath加载sdcard中的新资源包，这样就获得一个含有全部新资源的AssetManager
将原来引用到AssetManager的地方，经过反射把引用处替换为新的AssetManager

二、资源包替换（Sophix）

默认由Android SDK编译出来的apk，其资源包的package id为0x7f。framework-res.jar的资源package id为0x01

构造一个package id为0x66的资源包（非0x7f和0x01），只包含已经改变的资源项。
因为不与已经加载的Ox7f冲突，因此能够经过原有的AssetManager的addAssetPath加载这个包。

3、SO库修复

本质是对native方法的修复和替换

一、so库加载

(1)经过如下方法加载so库

#System
public static void loadLibrary(String libname) {
    Runtime.getRuntime().loadLibrary0(VMStack.getCallingClassLoader(), libname);
}
参数为so库名称，位于apk的lib目录下

public static void load(String filename) {
    Runtime.getRuntime().load0(VMStack.getStackClass1(), filename);
}
加载外部自定义so库文件，参数为so库在磁盘中的完整路径
复制代码

private static native String nativeLoad(String filename, ClassLoader loader, String librarySearchPath);
复制代码

最终都是调用了native方法nativeLoad，参数fileName为so在磁盘中的完整路径名

(2)遍历nativeLibraryDirectories目录

#DexPathList
public String findLibrary(String libraryName) {
    String fileName = System.mapLibraryName(libraryName);
    for (File directory : nativeLibraryDirectories) {
        File file = new File(directory, fileName);
        if (file.exists() && file.isFile() && file.canRead()) {
            return file.getPath();
        }
    }
    return null;
}
复制代码

相似于类加载的findClass方法，在数组中每个元素对应一个so库，最终返回了so的路径。若是将so补丁添加到数组的最前面，在调用方法加载so库时，会先将补丁so的路径返回。

二、SO修复方案

（1）接口替换

提供方法替代System.loadLibrary方法

若是存在补丁so，则加载补丁so库，不去加载apk安装目录下的so库
若是不存在补丁so，调用System.loadLibrary去加载安装apk目录下的so库

（2）反射注入

由于加载so库会遍历nativeLibraryDirectories

经过反射将补丁so库的路径插入到nativeLibraryDirectories数组的最前面
遍历nativeLibraryDirectories时，就会将补丁so库进行返回并加载，从而达到修复目的

4、热修复框架分析

底层替换方案：阿里的AndFix、HotFix
类加载方案：QQ空间补丁技术、微信的Tinker方案、饿了么的Amigo
两者结合：Sophix

参考资料：

主流热修复方案分析
Android热修复技术，你会怎么选？
《Android进阶解密》
《深刻探索Android热修复技术原理》