手把手带你打造一个 Android 热修复框架

本文来自网易云社区

作者：王晨彦

Application 处理

上面我们已经对所有 class 文件插入了 Hack 的引用，而插入 dex 是在 Application 中，Application 启动前肯定要先加载 Application.class，但这时 dex 还没被插入，因此肯定会引起 ClassNotFoundException ，因此我们不能使 Application 引用 Hack。

那么修改 class 文件时如何知道哪个是 Application 呢，有人可能会说直接特判不就行了，但是我觉得要作为一个插件的话就要做到兼容，并且尽量减少使用者的手动配置。

那么如何让插件找到 Application 的名字呢，这时就要用到上面的 processDebugManifest Task 了。

我们都知道，Application需要在 Manifest 中注册，因此只要找到 Manifest 文件就能得到 Application 的名字了。

没错，Manifest 文件就在 processDebugManifest 的 outputs.files 中，找到 Manifest 后解析 application 标签即可。

• 开启混淆会怎样？

我们正式上线的应用都是会混淆的，我们刚才测试的使用 debug 未混淆模式，如果我们开启混淆的话 Task 还会和上面的完全一样吗？

我们把 release 的混淆打开，然后执行 assembleRelease，观察 Gradle Console 输出

:app:preBuild UP-TO-DATE// 省略部分Task:app:processReleaseJavaRes NO-SOURCE
:app:transformResourcesWithMergeJavaResForRelease
:app:transformClassesAndResourcesWithProguardForRelease
:app:transformClassesWithDexForRelease
:app:mergeReleaseJniLibFolders
:app:transformNativeLibsWithMergeJniLibsForRelease
:app:validateSigningRelease
:app:packageRelease
:app:assembleRelease

可以看到相比较未开启混淆多了一个 transformClassesAndResourcesWithProguardForRelease， 那么这个Proguard Task有用吗？

有用！

为了保证打包 APK 和 patch 时 class 混淆后的名字不变，我们需要在 Proguard Task 前插入混淆逻辑

使用 Proguard 的 -applymapping 即可实现。

因此，我们还要对打包APK后生成的 mapping 文件进行保存。

插件中代码实现

static applymapping(TransformTask proguardTask, File mappingFile) {    if (proguardTask) {
        ProGuardTransform transform = (ProGuardTransform) proguardTask.getTransform()        if (mappingFile.exists()) {
            transform.applyTestedMapping(mappingFile)
        } else {
            CFixLogger.i("${mappingFile} does not exist")
        }
    }
}

• 补丁签名

为了安全，上线时我们最好对补丁加上签名验证，保证补丁签名和 APK 签名一致。

签名使用 JDK 中的 jarsigner

List<String> command = [JavaEnvUtils.getJdkExecutable('jarsigner'),                        '-verbose',                        '-sigalg', 'MD5withRSA',                        '-digestalg', 'SHA1',                        '-keystore', extension.storeFile.absolutePath,                        '-keypass', extension.keyPassword,                        '-storepass', extension.storePassword,
                        patchFile.absolutePath,
                        extension.keyAlias]Process proc = command.execute()

校验签名的代码我就不贴了，对应的是源码中的 SignChecker 类。

检验成果

上面我们已经把制作补丁，导入补丁的过程大致梳理了一遍，接下来就需要把上面的代码整理一下。

为了方便使用，我们将其制作为一个 Gradle 插件。如果还不了解如何制作 Gradle 插件的话快点去学习啦

我已将插件和依赖库上传至 JCenter，在 app 中引入插件。

// root build.gradlebuildscript {
    repositories {
        jcenter()
    }

    dependencies {
        classpath 'com.android.tools.build:gradle:2.3.3'
        classpath 'me.wcy:cfix-gradle:1.1'
    }
}// app build.gradleapply plugin: 'com.android.application'apply plugin: 'me.wcy.cfix'cfix {
    includePackage = ['me/wcy/cfix/sample'] // 需要插入补丁的包名，一般为应用的包名
    excludeClass = [] // 不需要插入补丁的类
    debugOn = true // debug 模式是否插入补丁

    sign = true // 是否添加签名
    storeFile = file("release.jks")
    storePassword = 'android'
    keyAlias = 'cfix'
    keyPassword = 'android'}// 省略部分代码dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:appcompat-v7:25.3.1'
    compile 'me.wcy:cfix:1.0'}

在 Application 中插入 Hack dex 和 patch

@Overrideprotected void attachBaseContext(Context base) {
    super.attachBaseContext(base);
    CFix.init(this);
    CFix.loadPatch(Environment.getExternalStorageDirectory().getPath().concat("/patch.jar"), !BuildConfig.DEBUG);
}

首先不对项目做任何修改，直接运行

熟悉的 Hello World

检查下 class 文件是否已经引入 Hack 类，编译后的 class 位于 app/build/intermediates/classes

 

可以看到，Application 没有引入 Hack 类，Activity 已经成功引入 Hack 类。

然后我们添加一个对话框类，并在Activity中调用该类显示对话框

public class FixDialog {    public void show(Context context) {        new AlertDialog.Builder(context)
                .setTitle("Congratulations")
                .setMessage("Patch Success!")
                .setPositiveButton("OK", null)
                .show();
    }
}// MainActivity@Overrideprotected void onCreate(Bundle savedInstanceState) {    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);

    FixDialog dialog = new FixDialog();
    dialog.show(this);
}

保存生成的 Hash 文件，制作补丁包

打开终端，执行以下命令

gradlew clean cfixXiaomiDebugPatch -P cfixDir=D:\Android\AndroidStudioProjects\CFix\app\cfix

Xiaomi 表示 productFlavor，Debug 表示 buildType

将生成的 patch.jar push 到手机 SD 根目录

adb push D:\Users\wcy\Desktop\patch.jar /sdcard/

重启应用

注意，因为我们只是测试，所以把补丁包放在了SD中，因此需要添加读取SD权限，还需要把 targetSdk 改为小于 23 或者手动给予权限。

 

源码

该框架可以说是对 Nuwa 的优化升级，几乎支持了目前所有的 Gradle 版本 1.5.0-3.0.1（1.5之前的版本由于太旧未适配）。

再次对 Nuwa 作者表示感谢，给我们提供了很好的例子。

该框架在网易七鱼 Android 客服工作台中已经验证通过。

框架使用方法请参考 README

声明：该框架未进行兼容性测试，因此不保证兼容所有机型。如果要在商业项目中使用，建议进行兼容性测试。

总结

今天我们主要对 QQ 空间的热修复方案进行了可实行性探讨，对整个流程进行梳理，并最终实现了整套方案，验证通过。

其实我在这期间也踩了不少坑，如 QQ 空间博客中提到的使用 javassist 对 class 进行修改，我使用 javassist 后，一开始在 demo 中可以正常修改 class，但是到了大量代码的线上项目中一直报找不到 v4 包中的类，导致无法修改 class 文件引入 Hack 类。打 log 又发现类已经正常被加载，而且有时能找到有时找不到，每次找不到的类还不一样，WTF。

最后参考了 Nuwa 的实现，替换为 ASM，问题解决。

近两年涌现了很多热修复框架，关于热修复的文章也有很多，相信大家也看了不少，但是看的再多，终究不如动手实践来的深刻。

网易云免费体验馆，0成本体验20+款云产品！ 

更多网易研发、产品、运营经验分享请访问网易云社区。

相关文章：
【推荐】 JAVA虚拟机的类加载机制