Tinker + Bugly + Jenkins 爬坑之路

Tinker + Bugly热修复实现

参考官方文档：Bugly Android热更新使用指南、Bugly Android热更新详解

主要接入流程：

• 打基准包安装并上报联网（注：填写唯一的tinkerId）
• 对基准包的 bug 修复（可以是 Java 代码变更，资源的变更）
• 修改基准包路径、修改补丁包tinkerId、mapping文件路径（如果开启了混淆需要配置）、resId文件路径
• 执行buildTinkerPatchRelease打 Release 版本补丁包
• 选择app/build/outputs/patch目录下的补丁包并上传（注：不要选择tinkerPatch目录下的补丁包，不然上传会有问题）
• 编辑下发补丁规则，点击立即下发
• 杀死进程并重启基准包，请求补丁策略（SDK 会自动下载补丁并合成）
• 再次重启基准包，检验补丁应用结果
• 查看页面，查看激活数据的变化

结合 Jenkins 所遇到的坑

基线包维护

由于公司Jenkins的打包策略是，在构建之前，先执行clean命令，这也就意味着，像本地打包一样在app/build/bakApk/app-xxxx-xx-xx-xx目录下找到基准包已是不可能。因此可以约定一个目录，打基准包时将基准包目录由脚本拷贝过去，打补丁包时从约定的目录读取即可，也可以上传Gitlab、OSS/S3等平台

构建基准包的同时生成的mapping文件（如果开启了混淆需要配置）、resId文件在构建补丁包时也需要用到

patch目录被清空

Jenkins构建期间是有在app/build/outputs/patch目录下生成patch_signed_7zip.apk文件的，但是构建完成之后被清空了，构建脚本如下：

sh gradlew clean buildTinkerPatchRelease  --stacktrace
sh gradlew checklist

执行buildTinkerPatchRelease后，还执行checklist任务，原因是执行checklist时把patch目录给清空了

注意：打补丁包后，再次执行gradle task，基本都会清空patch目录，这是个坑