Android 热修复技术原理与主流方案对比

怎么选择合适的热修复方案

怎么选？这个只能说一切看需求。如果公司综合实力强，完全考虑自研都没问题，但需要综合考虑成本及维护。下面给出几点建议：

1. 项目需求

   • 只需要简单的方法级别 Bug 修复？
   • 需要资源及 so 库的修复？
   • 对平台兼容性要求及成功率要求？
   • 有需求对分发进行控制，对监控数据进行统计，补丁包进行管理？
   • 公司资源是否支持商业付费？

2. 学习及使用成本

   • 集成难度
   • 代码侵入性
   • 调试维护

3. 选择大厂

   • 技术性能有保障
   • 有专人维护
   • 热度高，开源社区活跃

4. 推荐选择

   • 如果考虑付费，推荐选择阿里的 Sophix，Sophix 是综合优化的产物，功能完善、开发简单透明、提供分发及监控管理。
   • 如果不考虑付费，只需支持方法级别的 Bug 修复，不支持资源及 so，推荐使用 Robust。
   • 如果考虑需要同时支持资源及 so，推荐使用 Tinker。
   • 最后如果公司综合实力强，可考虑自研，灵活性及可控制最强。

热修复技术方案原理

技术分类

NativeHook 原理

原理及实现

NativeHook 的原理是直接在 native 层进行方法的结构体信息对换，从而实现完美的方法新旧替换，从而实现热修复功能。 下面以 AndFix 的一段 jni 代码来进行说明，如下：

void replace_6_0(JNIEnv* env, jobject src, jobject dest) {
    // 通过 Method 对象得到底层 Java 函数对应 ArtMethod 的真实地址
    art::mirror::ArtMethod* smeth =
            (art::mirror::ArtMethod*) env->FromReflectedMethod(src);

    art::mirror::ArtMethod* dmeth =
            (art::mirror::ArtMethod*) env->FromReflectedMethod(dest);

    reinterpret_cast<art::mirror::Class*>(dmeth->declaring_class_)->class_loader_ =
    reinterpret_cast<art::mirror::Class*>(smeth->declaring_class_)->class_loader_; //for plugin classloader
    reinterpret_cast<art::mirror::Class*>(dmeth->declaring_class_)->clinit_thread_id_ =
    reinterpret_cast<art::mirror::Class*>(smeth->declaring_class_)->clinit_thread_id_;
    reinterpret_cast<art::mirror::Class*>(dmeth->declaring_class_)->status_ = reinterpret_cast<art::mirror::Class*>(smeth->declaring_class_)->status_-1;
    //for reflection invoke
    reinterpret_cast<art::mirror::Class*>(dmeth->declaring_class_)->super_class_ = 0;
    //把旧函数的所有成员变量都替换为新函数的
    smeth->declaring_class_ = dmeth->declaring_class_;
    smeth->dex_cache_resolved_methods_ = dmeth->dex_cache_resolved_methods_;
    smeth->dex_cache_resolved_types_ = dmeth->dex_cache_resolved_types_;
    smeth->access_flags_ = dmeth->access_flags_ | 0x0001;
    smeth->dex_code_item_offset_ = dmeth->dex_code_item_offset_;
    smeth->dex_method_index_ = dmeth->dex_method_index_;
    smeth->method_index_ = dmeth->method_index_;

    smeth->ptr_sized_fields_.entry_point_from_interpreter_ =
    dmeth->ptr_sized_fields_.entry_point_from_interpreter_;

    smeth->ptr_sized_fields_.entry_point_from_jni_ =
    dmeth->ptr_sized_fields_.entry_point_from_jni_;
    smeth->ptr_sized_fields_.entry_point_from_quick_compiled_code_ =
    dmeth->ptr_sized_fields_.entry_point_from_quick_compiled_code_;

    LOGD("replace_6_0: %d , %d",
         smeth->ptr_sized_fields_.entry_point_from_quick_compiled_code_,
         dmeth->ptr_sized_fields_.entry_point_from_quick_compiled_code_);
}

void setFieldFlag_6_0(JNIEnv* env, jobject field) {
    art::mirror::ArtField* artField =
            (art::mirror::ArtField*) env->FromReflectedField(field);
    artField->access_flags_ = artField->access_flags_ & (~0x0002) | 0x0001;
    LOGD("setFieldFlag_6_0: %d ", artField->access_flags_);
}

每一个 Java 方法在 art 中都对应一个 ArtMethod，ArtMethod 记录了这个 Java 方法的所有信息，包括访问权限及代码执行地址等。通过 env->FromReflectedMethod 得到方法对应的 ArtMethod 的真正开始地址，然后强转为 ArtMethod 指针，从而对其所有成员进行修改。 这样以后调用这个方法时就会直接走到新方法的实现中，达到热修复的效果。

优点

• 即时生效
• 没有性能开销，不需要任何编辑器的插桩或代码改写

缺点

• 存在稳定及兼容性问题。ArtMethod 的结构基本参考 Google 开源的代码，各大厂商的 ROM 都可能有所改动，可能导致结构不一致，修复失败。
• 无法增加变量及类，只能修复方法级别的 Bug，无法做到新功能的发布

javaHook 原理

原理及实现

以美团的 Robust 为例，Robust 的原理可以简单描述为：

1. 打基础包时插桩，在每个方法前插入一段类型为 ChangeQuickRedirect 静态变量的逻辑，插入过程对业务开发是完全透明
2. 加载补丁时，从补丁包中读取要替换的类及具体替换的方法实现，新建 ClassLoader 加载补丁 dex。当 changeQuickRedirect 不为 null 时，可能会执行到 accessDispatch 从而替换掉之前老的逻辑，达到 fix 的目的

下面通过 Robust 的源码来进行分析。 首先看一下打基础包是插入的代码逻辑，如下：

public static ChangeQuickRedirect u;
protected void onCreate(Bundle bundle) {
        //为每个方法自动插入修复逻辑代码，如果 ChangeQuickRedirect 为空则不执行
        if (u != null) {
            if (PatchProxy.isSupport(new Object[]{bundle}, this, u, false, 78)) {
                PatchProxy.accessDispatchVoid(new Object[]{bundle}, this, u, false, 78);
                return;
            }
        }
        super.onCreate(bundle);
        ...
    }

Robust 的核心修复源码如下：

public class PatchExecutor extends Thread {
    @Override
    public void run() {
        ...
        applyPatchList(patches);
        ...
    }
    /**
     * 应用补丁列表
     */
    protected void applyPatchList(List<Patch> patches) {
        ...
        for (Patch p : patches) {
            ...
            currentPatchResult = patch(context, p);
            ...
            }
    }
     /**
     * 核心修复源码
     */
    protected boolean patch(Context context, Patch patch) {
        ...
        //新建 ClassLoader
        DexClassLoader classLoader = new DexClassLoader(patch.getTempPath(), context.getCacheDir().getAbsolutePath(),
                null, PatchExecutor.class.getClassLoader());
        patch.delete(patch.getTempPath());
        ...
        try {
            patchsInfoClass = classLoader.loadClass(patch.getPatchesInfoImplClassFullName());
            patchesInfo = (PatchesInfo) patchsInfoClass.newInstance();
            } catch (Throwable t) {
             ...
        }
        ...
        //通过遍历其中的类信息进而反射修改其中 ChangeQuickRedirect 对象的值
        for (PatchedClassInfo patchedClassInfo : patchedClasses) {
            ...
            try {
                oldClass = classLoader.loadClass(patchedClassName.trim());
                Field[] fields = oldClass.getDeclaredFields();
                for (Field field : fields) {
                    if (TextUtils.equals(field.getType().getCanonicalName(), ChangeQuickRedirect.class.getCanonicalName()) && TextUtils.equals(field.getDeclaringClass().getCanonicalName(), oldClass.getCanonicalName())) {
                        changeQuickRedirectField = field;
                        break;
                    }
                }
                ...
                try {
                    patchClass = classLoader.loadClass(patchClassName);
                    Object patchObject = patchClass.newInstance();
                    changeQuickRedirectField.setAccessible(true);
                    changeQuickRedirectField.set(null, patchObject);
                    } catch (Throwable t) {
                    ...
                }
            } catch (Throwable t) {
                 ...
            }
        }
        return true;
    }
}

优点

• 高兼容性（Robust 只是在正常的使用 DexClassLoader）、高稳定性，修复成功率高达 99.9%
• 补丁实时生效，不需要重新启动
• 支持方法级别的修复，包括静态方法
• 支持增加方法和类
• 支持 ProGuard 的混淆、内联、优化等操作

缺点

• 代码是侵入式的，会在原有的类中加入相关代码
• so 和资源的替换暂时不支持
• 会增大 apk 的体积，平均一个函数会比原来增加 17.47 个字节，10 万个函数会增加 1.67M

java mulitdex 原理

原理及实现

Android 内部使用的是 BaseDexClassLoader、PathClassLoader、DexClassLoader 三个类加载器实现从 DEX 文件中读取类数据，其中 PathClassLoader 和 DexClassLoader 都是继承自 BaseDexClassLoader 实现。dex 文件转换成 dexFile 对象，存入 Element[]数组，findclass 顺序遍历 Element 数组获取 DexFile，然后执行 DexFile 的 findclass。源码如下：

// 加载名字为 name 的 class 对象
public Class findClass(String name, List<Throwable> suppressed) {
    // 遍历从 dexPath 查询到的 dex 和资源 Element
    for (Element element : dexElements) {
        DexFile dex = element.dexFile;
        // 如果当前的 Element 是 dex 文件元素
        if (dex != null) {
            // 使用 DexFile.loadClassBinaryName 加载类
            Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
            if (clazz != null) {
                return clazz;
            }
        }
    }
    if (dexElementsSuppressedExceptions != null) {
        suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
    }
    return null;
}

所以此方案的原理是 Hook 了 ClassLoader.pathList.dexElements[]，将补丁的 dex 插入到数组的最前端。因为 ClassLoader 的 findClass 是通过遍历 dexElements[]中的 dex 来寻找类的。所以会优先查找到修复的类。从而达到修复的效果。

下面使用 Nuwa 的关键实现源码进行说明如下：

public static void injectDexAtFirst(String dexPath, String defaultDexOptPath) throws NoSuchFieldException, IllegalAccessException, ClassNotFoundException {
        //新建一个 ClassLoader 加载补丁 Dex
        DexClassLoader dexClassLoader = new DexClassLoader(dexPath, defaultDexOptPath, dexPath, getPathClassLoader());
        //反射获取旧 DexElements 数组
        Object baseDexElements = getDexElements(getPathList(getPathClassLoader()));
        //反射获取补丁 DexElements 数组
        Object newDexElements = getDexElements(getPathList(dexClassLoader));
        //合并，将新数组的 Element 插入到最前面
        Object allDexElements = combineArray(newDexElements, baseDexElements);
        Object pathList = getPathList(getPathClassLoader());
        //更新旧 ClassLoader 中的 Element 数组
        ReflectionUtils.setField(pathList, pathList.getClass(), "dexElements", allDexElements);
    }

    private static PathClassLoader getPathClassLoader() {
        PathClassLoader pathClassLoader = (PathClassLoader) DexUtils.class.getClassLoader();
        return pathClassLoader;
    }

    private static Object getDexElements(Object paramObject)
            throws IllegalArgumentException, NoSuchFieldException, IllegalAccessException {
        return ReflectionUtils.getField(paramObject, paramObject.getClass(), "dexElements");
    }

    private static Object getPathList(Object baseDexClassLoader)
            throws IllegalArgumentException, NoSuchFieldException, IllegalAccessException, ClassNotFoundException {
        return ReflectionUtils.getField(baseDexClassLoader, Class.forName("dalvik.system.BaseDexClassLoader"), "pathList");
    }

    private static Object combineArray(Object firstArray, Object secondArray) {
        Class<?> localClass = firstArray.getClass().getComponentType();
        int firstArrayLength = Array.getLength(firstArray);
        int allLength = firstArrayLength + Array.getLength(secondArray);
        Object result = Array.newInstance(localClass, allLength);
        for (int k = 0; k < allLength; ++k) {
            if (k < firstArrayLength) {
                Array.set(result, k, Array.get(firstArray, k));
            } else {
                Array.set(result, k, Array.get(secondArray, k - firstArrayLength));
            }
        }
        return result;
    }

优点

• 不需要考虑对 dalvik 虚拟机和 art 虚拟机做适配
• 代码是非侵入式的，对 apk 体积影响不大

缺点

• 需要下次启动才修复
• 性能损耗大，为了避免类被加上 CLASS_ISPREVERIFIED，使用插桩，单独放一个帮助类在独立的 dex 中让其他类调用。

dex 替换

原理及实现

为了避免 dex 插桩带来的性能损耗，dex 替换采取另外的方式。原理是提供 dex 差量包，整体替换 dex 的方案。差量的方式给出 patch.dex，然后将 patch.dex 与应用的 classes.dex 合并成一个完整的 dex，完整 dex 加载得到 dexFile 对象作为参数构建一个 Element 对象然后整体替换掉旧的 dex-Elements 数组。

这也是微信 Tinker 采用的方案，并且 Tinker 自研了 DexDiff/DexMerge 算法。Tinker 还支持资源和 So 包的更新，So 补丁包使用 BsDiff 来生成，资源补丁包直接使用文件 md5 对比来生成，针对资源比较大的（默认大于 100KB 属于大文件）会使用 BsDiff 来对文件生成差量补丁。

下面我们关键看看 Tinker 的实现源码，当然具体的实现算法很复杂，我们只看关键的实现，最后的修复在 UpgradePatch 中的 tryPatch 方法，如下：

  @Override
    public boolean tryPatch(Context context, String tempPatchPath, PatchResult patchResult) {
        //省略一堆校验
        ... ....

        //下面是关键的 diff 算法及合并实现，实现相对复杂，感兴趣可以再仔细阅读源码
        //we use destPatchFile instead of patchFile, because patchFile may be deleted during the patch process
        if (!DexDiffPatchInternal.tryRecoverDexFiles(manager, signatureCheck, context, patchVersionDirectory, destPatchFile)) {
            TinkerLog.e(TAG, "UpgradePatch tryPatch:new patch recover, try patch dex failed");
            return false;
        }

        if (!BsDiffPatchInternal.tryRecoverLibraryFiles(manager, signatureCheck, context, patchVersionDirectory, destPatchFile)) {
            TinkerLog.e(TAG, "UpgradePatch tryPatch:new patch recover, try patch library failed");
            return false;
        }

        if (!ResDiffPatchInternal.tryRecoverResourceFiles(manager, signatureCheck, context, patchVersionDirectory, destPatchFile)) {
            TinkerLog.e(TAG, "UpgradePatch tryPatch:new patch recover, try patch resource failed");
            return false;
        }

        // check dex opt file at last, some phone such as VIVO/OPPO like to change dex2oat to interpreted
        if (!DexDiffPatchInternal.waitAndCheckDexOptFile(patchFile, manager)) {
            TinkerLog.e(TAG, "UpgradePatch tryPatch:new patch recover, check dex opt file failed");
            return false;
        }

        if (!SharePatchInfo.rewritePatchInfoFileWithLock(patchInfoFile, newInfo, patchInfoLockFile)) {
            TinkerLog.e(TAG, "UpgradePatch tryPatch:new patch recover, rewrite patch info failed");
            manager.getPatchReporter().onPatchInfoCorrupted(patchFile, newInfo.oldVersion, newInfo.newVersion);
            return false;
        }

        TinkerLog.w(TAG, "UpgradePatch tryPatch: done, it is ok");
        return true;
    }

优点

• 兼容性高
• 补丁小
• 开发透明，代码非侵入式

缺点

• 冷启动修复，下次启动修复
• Dex 合并内存消耗在 vm head 上，容易 OOM，最后导致合并失败

资源修复原理

Instant Run

1. 构建一个新的 AssetManager，并通过反射调用 addAssertPath，把这个完整的新资源包加入到 AssetManager 中。这样就得到一个含有所有新资源的 AssetManager
2. 找到所有值钱引用到原有 AssetManager 的地方，通过反射，把引用处替换为 AssetManager

 public static void monkeyPatchExistingResources(Context context,
                                                    String externalResourceFile, Collection activities) {
        if (externalResourceFile == null) {
            return;
        }
        try {
            //反射一个新的   AssetManager
            AssetManager newAssetManager = (AssetManager) AssetManager.class
                    .getConstructor(new Class[0]).newInstance(new Object[0]);
           //反射 addAssetPath 添加新的资源包
            Method mAddAssetPath = AssetManager.class.getDeclaredMethod("addAssetPath", new Class[]{String.class});
            mAddAssetPath.setAccessible(true);
            if (((Integer) mAddAssetPath.invoke(newAssetManager,
                    new Object[]{externalResourceFile})).intValue() == 0) {
                throw new IllegalStateException(
                        "Could not create new AssetManager");
            }
            Method mEnsureStringBlocks = AssetManager.class.getDeclaredMethod("ensureStringBlocks", new Class[0]);
            mEnsureStringBlocks.setAccessible(true);
            mEnsureStringBlocks.invoke(newAssetManager, new Object[0]);
            //反射得到 Activity 中 AssetManager 的引用处，全部换成刚新构建的 AssetManager 对象
            if (activities != null) {
                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);
                        }
                        Field mt = ContextThemeWrapper.class.getDeclaredField("mTheme");
                        mt.setAccessible(true);
                        mt.set(activity, null);
                        Method mtm = ContextThemeWrapper.class.getDeclaredMethod("initializeTheme", new Class[0]);
                        mtm.setAccessible(true);
                        mtm.invoke(activity, new Object[0]);
                        Method mCreateTheme = AssetManager.class.getDeclaredMethod("createTheme", new Class[0]);
                        mCreateTheme.setAccessible(true);
                        Object internalTheme = mCreateTheme.invoke(newAssetManager, new Object[0]);
                        Field mTheme = Resources.Theme.class.getDeclaredField("mTheme");
                        mTheme.setAccessible(true);
                        mTheme.set(theme, internalTheme);
                    } catch (Throwable e) {
                        Log.e("InstantRun",
                                "Failed to update existing theme for activity "
                                        + activity, e);
                    }
                    pruneResourceCaches(resources);
                }
            }
            Collection references;
            if (Build.VERSION.SDK_INT >= 19) {
                Class resourcesManagerClass = Class.forName("android.app.ResourcesManager");
                Method mGetInstance = resourcesManagerClass.getDeclaredMethod("getInstance", new Class[0]);
                mGetInstance.setAccessible(true);
                Object resourcesManager = mGetInstance.invoke(null, new Object[0]);
                try {
                    Field fMActiveResources = resourcesManagerClass.getDeclaredField("mActiveResources");
                    fMActiveResources.setAccessible(true);
                    ArrayMap  arrayMap = (ArrayMap) fMActiveResources.get(resourcesManager);
                    references = arrayMap.values();
                } catch (NoSuchFieldException ignore) {
                    Field mResourceReferences = resourcesManagerClass.getDeclaredField("mResourceReferences");
                    mResourceReferences.setAccessible(true);
                    references = (Collection) mResourceReferences.get(resourcesManager);
                }
            } else {
                Class activityThread = Class.forName("android.app.ActivityThread");
                Field fMActiveResources = activityThread.getDeclaredField("mActiveResources");
                fMActiveResources.setAccessible(true);
                Object thread = getActivityThread(context, activityThread);
                HashMap  map = (HashMap) fMActiveResources.get(thread);
                references = map.values();
            }
            for (WeakReference wr : references) {
                Resources resources = (Resources) wr.get();
                if (resources != null) {
                    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);
        }
    }

so 修复原理

接口调用替换

sdk 提供接口替换 System 默认加载 so 库的接口

SOPatchManger.loadLibrary(String libName)
替换
System.loadLibrary(String libName)

SOPatchManger.loadLibrary 接口加载 so 库的时候优先尝试去加载 sdk 指定目录下补丁的 so。若不存在，则再去加载安装 apk 目录下的 so 库

优点：不需要对不同 sdk 版本进行兼容，所以 sdk 版本都是 System.loadLibrary 这个接口

缺点：需要侵入业务代码，替换掉 System 默认加载 so 库的接口

反射注入

采取类似类修复反射注入方式，只要把补丁 so 库的路径插入到 nativeLibraryDirectories 数组的最前面，就能够达到加载 so 库的时候是补丁 so 库而不是原来 so 库的目录，从而达到修复。

public String findLibrary(String libraryName) {
        String fileName = System.mapLibraryName(libraryName);

        for (NativeLibraryElement element : nativeLibraryPathElements) {
            String path = element.findNativeLibrary(fileName);

            if (path != null) {
                return path;
            }
        }

        return null;
    }

优点：不需侵入用户接口调用

缺点：需要做版本兼容控制，兼容性较差

使用热修复技术有哪些需要注意的问题？

版本管理

使用热修复技术后由于发布流程的变化，肯定也需求采用相应的分支管理进行控制。

通常移动开发的分支管理采用特性分支，如下：

接入热修复后，推荐可参考如下分支策略：

注意热修复分支的测试及发布流程应用正常版本流程一致，保证质量。

分发监控

目前主流的热修复方案，像 Tinker 及 Sophix 都会提供补丁的分发及监控。这也是我们选择热修复技术方案需要考虑的关键因素之一。毕竟为了保证线上版本的质量，分发控制及实时监测必不可少。

总结

想要深入了解热修复，需要了解类加载机制，Instant Run，multidex 以及 java 底层实现细节，JNI，AAPT 和虚拟机的知识，需要庞大的知识贮备才能进行深入理解，当然 Android Framwork 的实现细节是非常重要的。熟悉热修复的原理有助于我们提供自己的编程水平，提升自己解决问题的能力。热修复不是简单的客户端 SDK，它还包含了安全机制和服务端的控制逻辑，整条链路也不是短时间可以快速完成的。开发者应结合项目实际情况，选择合适的热修复方案并建立完善的监控体系。