如何5分钟让你的 SDK 拥有热修复能力(原理篇)

5,641 阅读7分钟

前言

看完本文可以达到什么程度

  • 自顶向下分析
  • 学会 hook task
  • 学会自定义 task,自定义 gradle 插件
  • 掌握改造 Robust

预备知识

  • 理解 gradle 的基本开发
  • 掌握 Task,Transform 概念

阅读前准备工作


前文提到,当我美滋滋接入 Robust 时却报错提示,只有 Application Module 才能插桩和打补丁,而且还要做补丁管理、加解密、数据分析……

看来我们需要进行一番改造了。

从哪入手呢?

我们自顶向下分析整个需求实现步骤

在我们开始写代码之前,我们需要清楚如何解决问题。将问题分解成子问题,直到每个子问题都可以很轻松地解决。对问题进行建模,这样写出来的代码才具有可读性和可测性。

针对每一个步骤,我们来挖掘下对应的问题:

是不是清晰多了?

讲解之前先说明,本文着重于解决思路, 代码细节已经开源,不过多展开。只要掌握解决思路,剩下的都是面向 API 编程啦。

第一步:接入Robust

问题1:Robust 只支持Application Module

一个 apk 和一个 arr 有什么差别?

aar和apk共同点

实际上没什么差别。我们只需要加个开关,先将 SDK 配置为 Application,再 Hook apk 打包的 Task,把 build 目录下的资源压缩为 aar 不就行了!

实现见:packPlugin.gradle hookAssembleAndCopyRes 方法

问题2:怎么把插桩后的 aar 上传到 jcenter 呢?

uploadArchives Task 配置

上传肯定是要借助 uploadArchives 这个 Task,但是我翻遍了 uploadArchives Task 配置和官方文档,发现并不支持自定义数据源入口的。(心拔凉拔凉)

怎么办?GG了?

别急,我们还有大杀招 —— Hook Gradle Task。(后面你将会陆陆续续看到,Hook 简直就是个万金油~)

还不了解 Gradle 工作流程、Plugin、Task 的关系?见 一文应用 AOP 三、应用篇的基础部分

我们知道, Task 有一个重要的概念:inputs 和 outputs,Task 通过 inputs 拿到需要的参数,处理完毕之后就输出 outputs,而下一个 Task 的 inputs 则是上一个 Task 的outputs,如下图:

那我们打印一下 uploadArchives 的依赖 Task 和对应的输入输出,看下有什么线索(福尔摩斯.jpg)

bundleRelease Task 就是和打包相关的 Task 了,我们打印下这个 Task 的输出和输入:

诶,能不能这样,hook 这个Task,把我们插桩的 jar 复制粘贴覆盖这个输入源的 classes.jar?!好一招移花接木,就这么办!

实现见:packPlugin.gradle hookBundle方法

问题3:资源 ID 冲突

接入后,测试跑过来:诶?怎么 sdk 里的 layout 都不显示了。

哈?啥情况

反编译一看:

不同打包方式资源比对.png

好家伙,用 application 方式打包的 aar 资源 id 变成常量了。

这会有什么问题呢?

在 ADT 14之前,无论是主项目还是库项目,资源 ID 统一被定义为 final 类型的静态变量。如果代码中使用了 ID,就相当于使用一个常量,编译器的语法优化会将引用替换成具体的十六进制数。这样造成的结果:主项目编译时一旦发现资源 ID 冲突,就会为库项目的资源分配新 ID,这样库项目里引用资源文件的代码都需要重新编译。

如果 lib R 类中的资源 ID 仅被 static 修饰,就保留了变量。当资源ID发送冲突时,主项目 R 类不变,修改库项目 R 类中的变量,库项目已经编译过的代码仍有效。

所以 Android 设计 application 的 R 类都是静态常量,lib 的 R 类都是静态变量。

用过 BufferKnife 的同学都知道,在 libary 中使用 switch 需要用 R2.XXX,那不就会出现常量 R2 和业务方 R 资源冲突的问题吗?J 神是怎么解决的?请看:AST 抽象语法树 —— 最轻量级的AOP方法

能咋整?

难道我们要根据 0x7f… 反查 R.XX.XX 然后再一一把代码替换掉?要不我们强制改下插桩 aar 的资源 id 值从而避免冲突?默认值是0x7F...改成0x02~0x7E?

这么多个方案在我脑海中绕了一圈,一拍大腿,不用这么复杂呀!

既然 R 文件的变量修饰符变了,那我们改回来呗!

先找到 R 文件生成的Task,来,我们打印一下:

...

:sdk:generateReleaseBuildConfig //会生成 releasse下的 资源和源码 包括BuildConfig  在build/generate/source/buildConfig/release  依赖checkReleaseManifest
:sdk:generateReleaseResValues //准备resource的 values文件  
:sdk:generateReleaseResources //准备 资源文件 
:sdk:mergeReleaseResources  //release下的 生成Resource文件 在build/incremental/res/release下 和 merge.xml 在build/intermediates/incremental/mergeResources/release下
:sdk:processReleaseManifest //依赖prepareReleaseDependencies  生成 AndroidManifest文件 在build/incremental/manifest/full/release
:sdk:processReleaseResources //生成resources-release.ap_
:sdk:generateReleaseSources //生成R文件  在build/generate/source/r/debug下 
:sdk:processReleaseJavaRes            
:sdk:compileReleaseJavaWithJavac //使用Javac编译Java代码
:sdk:proguardRelease  //生成 混淆文件 运行混淆规则
:sdk:androidJavadocsPicked
:sdk:copyMappingTask  //复制 mapping文件  
:sdk:androidJavadocsJar //生成 Javadocs的Jar文件
:sdk:androidSourcesJar //生成 Java源码的 Jar文件
...

我们看到 generateReleaseSources Task 负责生成R文件,那我们写个 Gradle 脚本,hook 住前一个的 processReleaseResources Task,修改修饰符,so easy,hook 大法好!

实现见:packPlugin.gradle hookBuild方法

是不是觉得解决方案超简单?有时候难的不是实现,而是你能不能找到切入点。

动态修改 resId 小扩展:

第二步:补丁下发

补丁下载、加载和上传与一般的 app 热更无异,所以我们少些笔墨。

补丁的存储我们采用阿里云 OSS 对象存储:一种安全、低成本、高可靠的云存储服务,客户端、服务端、阿里云三者关系如下:

直接上时序图

第三步:补丁加载策略

第四步:补丁上传

这里有一点需要注意:自定义 Gradle Task 只支持引入纯 Java 库,不支持Android库。

第五步:补丁失效机制

1. 全局异常捕获不是最优解

一说到捕获异常,下意识第一反应:使用全局异常捕获器呀!

诶诶诶,那你就掉进经验坑里了!

我们思考下,如上图一共三步,最重要的一步是:确认是补丁引起的异常,如果使用全局异常捕获器,意味着:

  1. 我们需要比对堆栈信息。但是补丁可以获取类,无法获取到修复的方法名,而且堆栈比较非常低效,误判率也高。

  1. 补丁修复了 A + B,A 修复引起异常,整个补丁自动失效,B 修复也失效了。

能不能只让 A 失效呢?能不能高效确认是补丁引起的异常呢?

2. 在Robust源码中找找灵感

我们看看 robust.xml 的配置,一个是否自动捕获异常的配置映入眼帘。

来,在 Robust 全局搜索下 catchReflectException 关键字,发现插桩工厂类处理简单粗暴,直接拼接了 try-catch。

生成的补丁代码如下:

3. 确认改库的方式

那我们利用 try-catch,改造一下 Robust 的插桩吧。

  1. robust.xml 增加配置项,支持 rollbackWhenException 配置;
  2. 初始化时加载 XML 配置项;
  3. 新建回滚监听器类,供业务方监听;
  4. 插桩时,若开启此配置,则插入 try-catch,且 catch 里通知回滚监听器。

每个补丁方法都有唯一 id 我们利用此 id 来记录回滚状态

对 Robust 的详细改造MR,感兴趣的可以看看

开发阶段终于结束了,歇会儿~

第六步:数据分析

我们先看看我们最关心的指标是哪些,再倒推出详细的埋点项。

其中的接口失败率和下载失败率,我们还应区别错误原因:

后记

  1. SDK 热修复方案少人做 ≠ 难做,考验的就是拆分问题、细化问题的能力
  2. 大胆假设,细心验证

以上的实现我已经封装成库 SDKHotFix,SDK 开发者只需 5 分钟即可让自己的 SDK 拥有热修复的能力,欢迎 star !

最后,附上整个思维导图:

本篇完成耗时 15 个番茄钟(450 分钟)


我是 FeelsChaotic,一个写得了代码 p 得了图,剪得了视频画得了画的程序媛,致力于追求代码优雅、架构设计和 T 型成长。

欢迎关注 FeelsChaotic 的简书掘金,如果我的文章对你哪怕有一点点帮助,欢迎 ❤️!你的鼓励是我写作的最大动力!

最最重要的,请给出你的建议或意见,有错误请多多指正!