Tinker + Bugly + Jenkins 爬坑之路

Tinker + Bugly热修复实现

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

主要接入流程:

  • 打基准包安装并上报联网(注:填写唯一的tinkerId
  • 对基准包的 bug 修复(可以是 Java 代码变更,资源的变更)
  • 修改基准包路径、修改补丁包tinkerIdmapping文件路径(如果开启了混淆需要配置)、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文件的,但是构建完成之后被清空了,构建脚本如下:

1
2
sh gradlew clean buildTinkerPatchRelease  --stacktrace
sh gradlew checklist

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

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

Powered by AppBlog.CN     浙ICP备14037229号

Copyright © 2012 - 2021 APP开发技术博客 All Rights Reserved.

访客数 : | 访问量 :