![565d807c2f537300d066e2ab9a3acba6.png](https://img-blog.csdnimg.cn/img_convert/565d807c2f537300d066e2ab9a3acba6.png)
前言
看完本文可以达到什么程度
- 自顶向下分析
- 学会 hook task
- 学会自定义 task,自定义 gradle 插件
- 掌握改造 Robust
预备知识
- 理解 gradle 的基本开发
- 掌握 Task,Transform 概念
阅读前准备工作
- 对 Robust 还不了解的小伙伴 戳 Android热更新方案Robust
- 想使用其他方案的小伙伴 戳 SDK最全热修复方案
前文提到,当我美滋滋接入 Robust 时却报错提示,只有 Application Module 才能插桩和打补丁,而且还要做补丁管理、加解密、数据分析……
看来我们需要进行一番改造了。
从哪入手呢?
我们自顶向下分析整个需求实现步骤
在我们开始写代码之前,我们需要清楚如何解决问题。将问题分解成子问题,直到每个子问题都可以很轻松地解决。对问题进行建模,这样写出来的代码才具有可读性和可测性。
![39c2b936dc12598c02f54b48deca392d.png](https://img-blog.csdnimg.cn/img_convert/39c2b936dc12598c02f54b48deca392d.png)
针对每一个步骤,我们来挖掘下对应的问题:
![033046240be1ff04d6babb46effe5ad9.png](https://img-blog.csdnimg.cn/img_convert/033046240be1ff04d6babb46effe5ad9.png)
是不是清晰多了?
讲解之前先说明,本文着重于解决思路, 代码细节已经开源,不过多展开。只要掌握解决思路,剩下的都是面向 API 编程啦。
第一步:接入Robust
![c61d864302d217e937a31e13e49bbdb8.png](https://img-blog.csdnimg.cn/img_convert/c61d864302d217e937a31e13e49bbdb8.png)
问题1:Robust 只支持Application Module
一个 apk 和一个 arr 有什么差别?
![41b46b74fb984f169bbe89ba515289fa.png](https://img-blog.csdnimg.cn/img_convert/41b46b74fb984f169bbe89ba515289fa.png)
实际上没什么差别。我们只需要加个开关,先将 SDK 配置为 Application,再 Hook apk 打包的 Task,把 build 目录下的资源压缩为 aar 不就行了!
![a1261ebcd9e0a178094dd559bb99eb1c.png](https://img-blog.csdnimg.cn/img_convert/a1261ebcd9e0a178094dd559bb99eb1c.png)
![3bb1c1f1d3312052e968e8bd92f1b5eb.png](https://img-blog.csdnimg.cn/img_convert/3bb1c1f1d3312052e968e8bd92f1b5eb.png)
实现见:packPlugin.gradle
hookAssembleAndCopyRes
方法
问题2:怎么把插桩后的 aar 上传到 jcenter 呢?
![ca6caaf34445f03c949497c1e6b1e64b.gif](https://img-blog.csdnimg.cn/img_convert/ca6caaf34445f03c949497c1e6b1e64b.gif)
上传肯定是要借助 uploadArchives 这个 Task,但是我翻遍了 uploadArchives Task 配置和官方文档,发现并不支持自定义数据源入口的。(心拔凉拔凉)
怎么办?GG了?
别急,我们还有大杀招 —— Hook Gradle Task。(后面你将会陆陆续续看到,Hook 简直就是个万金油~)
还不了解 Gradle 工作流程、Plugin、Task 的关系?见 一文应用 AOP 三、应用篇的基础部分
我们知道, Task 有一个重要的概念:inputs 和 outputs,Task 通过 inputs 拿到需要的参数,处理完毕之后就输出 outputs,而下一个 Task 的 inputs 则是上一个 Task 的outputs,如下图:
![3dc8d0c7c32ca035fc81788adfb2c924.png](https://img-blog.csdnimg.cn/img_convert/3dc8d0c7c32ca035fc81788adfb2c924.png)
那我们打印一下 uploadArchives 的依赖 Task 和对应的输入输出,看下有什么线索(福尔摩斯.jpg)
![2622ba593fe437fb3aafad2a668de95f.png](https://img-blog.csdnimg.cn/img_convert/2622ba593fe437fb3aafad2a668de95f.png)
![78d7275b17e699e9b4c54a1ba3271dfe.png](https://img-blog.csdnimg.cn/img_convert/78d7275b17e699e9b4c54a1ba3271dfe.png)
bundleRelease Task 就是和打包相关的 Task 了,我们打印下这个 Task 的输出和输入:
![1fc4c8ca05c8bcf2434353b9d339df58.png](https://img-blog.csdnimg.cn/img_convert/1fc4c8ca05c8bcf2434353b9d339df58.png)
![7cf2f56da93845bcb344104f42f01d2b.png](https://img-blog.csdnimg.cn/img_convert/7cf2f56da93845bcb344104f42f01d2b.png)
诶,能不能这样,hook 这个Task,把我们插桩的 jar 复制粘贴覆盖这个输入源的 classes.jar?!好一招移花接木,就这么办!
实现见:packPlugin.gradle
hookBundle
方法
问题3:资源 ID 冲突
接入后,测试跑过来:诶?怎么 sdk 里的 layout 都不显示了。
哈?啥情况
![bd1ef5d7ee4c3183aa109a2ca391faa9.png](https://img-blog.csdnimg.cn/img_convert/bd1ef5d7ee4c3183aa109a2ca391faa9.png)
反编译一看:
![0ebd090763c896083998ffa061253b5d.png](https://img-blog.csdnimg.cn/img_convert/0ebd090763c896083998ffa061253b5d.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 需要用 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
方法
![2b5854f51cde2c83a4b10af047d93aad.png](https://img-blog.csdnimg.cn/img_convert/2b5854f51cde2c83a4b10af047d93aad.png)
是不是觉得解决方案超简单?有时候难的不是实现,而是你能不能找到切入点。
动态修改 resId 小扩展: - 动态修改android中的资源索引resId - Android中如何修改编译的资源ID值
第二步:补丁下发
补丁下载、加载和上传与一般的 app 热更无异,所以我们少些笔墨。
![49d837e8d9252b5465d4d70d8090b0fd.png](https://img-blog.csdnimg.cn/img_convert/49d837e8d9252b5465d4d70d8090b0fd.png)
补丁的存储我们采用阿里云 OSS 对象存储:一种安全、低成本、高可靠的云存储服务,客户端、服务端、阿里云三者关系如下:
![cc3b16b9636e27b618b38cc3e979eb8a.png](https://img-blog.csdnimg.cn/img_convert/cc3b16b9636e27b618b38cc3e979eb8a.png)
第三步:补丁加载策略
![d3b59060fd5ece97a721c207078bd860.png](https://img-blog.csdnimg.cn/img_convert/d3b59060fd5ece97a721c207078bd860.png)
![eef511550663f8623034a43357d5473f.png](https://img-blog.csdnimg.cn/img_convert/eef511550663f8623034a43357d5473f.png)
第四步:补丁上传
![2c73176ae781973e9480b0a60620938d.png](https://img-blog.csdnimg.cn/img_convert/2c73176ae781973e9480b0a60620938d.png)
这里有一点需要注意:自定义 Gradle Task 只支持引入纯 Java 库,不支持Android库。
第五步:补丁失效机制
1. 全局异常捕获不是最优解
![0755e9bd387f653ee6c9130a8b5fbb32.png](https://img-blog.csdnimg.cn/img_convert/0755e9bd387f653ee6c9130a8b5fbb32.png)
一说到捕获异常,下意识第一反应:使用全局异常捕获器呀!
诶诶诶,那你就掉进经验坑里了!
我们思考下,如上图一共三步,最重要的一步是:确认是补丁引起的异常,如果使用全局异常捕获器,意味着:
- 我们需要比对堆栈信息。但是补丁可以获取类,无法获取到修复的方法名,而且堆栈比较非常低效,误判率也高。
![580c7fd74d77f2514461e71d77abb442.png](https://img-blog.csdnimg.cn/img_convert/580c7fd74d77f2514461e71d77abb442.png)
- 补丁修复了 A + B,A 修复引起异常,整个补丁自动失效,B 修复也失效了。
能不能只让 A 失效呢?能不能高效确认是补丁引起的异常呢?
2. 在Robust源码中找找灵感
我们看看 robust.xml 的配置,一个是否自动捕获异常的配置映入眼帘。
![951e2f788501b1ba11b5d811296cabd9.png](https://img-blog.csdnimg.cn/img_convert/951e2f788501b1ba11b5d811296cabd9.png)
来,在 Robust 全局搜索下 catchReflectException
关键字,发现插桩工厂类处理简单粗暴,直接拼接了 try-catch。
![98dafcff269bba91b8c6ad2789d3158d.png](https://img-blog.csdnimg.cn/img_convert/98dafcff269bba91b8c6ad2789d3158d.png)
![2ac134aaccbd223b42d42bcbab3b69b7.png](https://img-blog.csdnimg.cn/img_convert/2ac134aaccbd223b42d42bcbab3b69b7.png)
生成的补丁代码如下:
![e3027cb62077f44e34943ed87051a6fc.png](https://img-blog.csdnimg.cn/img_convert/e3027cb62077f44e34943ed87051a6fc.png)
3. 确认改库的方式
那我们利用 try-catch,改造一下 Robust 的插桩吧。
- robust.xml 增加配置项,支持 rollbackWhenException 配置;
- 初始化时加载 XML 配置项;
- 新建回滚监听器类,供业务方监听;
- 插桩时,若开启此配置,则插入 try-catch,且 catch 里通知回滚监听器。
![146c7907f4e9301f81966ae449fc79ba.png](https://img-blog.csdnimg.cn/img_convert/146c7907f4e9301f81966ae449fc79ba.png)
每个补丁方法都有唯一 id 我们利用此 id 来记录回滚状态
对 Robust 的详细改造MR,感兴趣的可以看看
![87d5fc4766197ab5b33d60d06ecfcaae.png](https://img-blog.csdnimg.cn/img_convert/87d5fc4766197ab5b33d60d06ecfcaae.png)
![11c2addcf0dea183fbfc9ee130bf3fa8.png](https://img-blog.csdnimg.cn/img_convert/11c2addcf0dea183fbfc9ee130bf3fa8.png)
开发阶段终于结束了,歇会儿~
![70ae34bfab1e3987d1b4f813a2193852.png](https://img-blog.csdnimg.cn/img_convert/70ae34bfab1e3987d1b4f813a2193852.png)
第六步:数据分析
我们先看看我们最关心的指标是哪些,再倒推出详细的埋点项。
![468b71533ec1bd08d9e4b20050d481b0.png](https://img-blog.csdnimg.cn/img_convert/468b71533ec1bd08d9e4b20050d481b0.png)
其中的接口失败率和下载失败率,我们还应区别错误原因:
![1f5cf3d5c750c5ccebf722da4d8b0bb2.png](https://img-blog.csdnimg.cn/img_convert/1f5cf3d5c750c5ccebf722da4d8b0bb2.png)
![abf3344a7674bdf1ffdeffc910b9ea7a.png](https://img-blog.csdnimg.cn/img_convert/abf3344a7674bdf1ffdeffc910b9ea7a.png)
后记
- SDK 热修复方案少人做 ≠ 难做,考验的就是拆分问题、细化问题的能力
- 大胆假设,细心验证
以上的实现我已经封装成库 SDKHotFix,SDK 开发者只需 5 分钟即可让自己的 SDK 拥有热修复的能力,欢迎 star !
最后,附上整个思维导图:
![5becf7a361259ab07f3b652879e3acd3.png](https://img-blog.csdnimg.cn/img_convert/5becf7a361259ab07f3b652879e3acd3.png)
本篇完成耗时 15 个番茄钟(450 分钟)
我是 FeelsChaotic,一个写得了代码 p 得了图,剪得了视频画得了画的程序媛,致力于追求代码优雅、架构设计和 T 型成长。
欢迎关注 FeelsChaotic 的简书和掘金,如果我的文章对你哪怕有一点点帮助,欢迎 ??!你的鼓励是我写作的最大动力!
最最重要的,请给出你的建议或意见,有错误请多多指正!