手把手带你打造一个 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+款云产品！
更多网易研发、产品、运营经验分享请访问网易云社区。
相关文章：
【推荐】 机器学习、深度学习、和AI算法可以在网络安全中做什么？
【推荐】 关于网易云验证码V1.0版本的服务介绍
