android sdk方法隐藏_如何5分钟让你的 SDK 拥有热修复能力（原理篇）

前言

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

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

预备知识

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

阅读前准备工作

• 对 Robust 还不了解的小伙伴 戳 Android热更新方案Robust
• 想使用其他方案的小伙伴 戳 SDK最全热修复方案

---

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

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

从哪入手呢？

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

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

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

是不是清晰多了？

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

第一步：接入Robust

问题1：Robust 只支持Application Module

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

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

实现见：packPlugin.gradle hookAssembleAndCopyRes 方法

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

上传肯定是要借助 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 都不显示了。

哈？啥情况

反编译一看：

好家伙，用 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 需要用 http:// 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 小扩展： - 动态修改android中的资源索引resId - Android中如何修改编译的资源ID值

第二步：补丁下发

补丁下载、加载和上传与一般的 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 的简书和掘金，如果我的文章对你哪怕有一点点帮助，欢迎 ??！你的鼓励是我写作的最大动力！

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