Android|谈谈bugly的补丁升级热修复|第三方集成

bugly的补丁升级时通过tinker实现的，bugly对tinker进行了一层封装，所以我们不需要关心tinker的实现原理，如何集成bugly的补丁升级，代码如下

dependencies { // tinkersupport插件, 其中lastest.release指拉取最新版本，也可以指定明确版本号，例如1.0.4 classpath "com.tencent.bugly:tinker-support:latest.release" }

目前主流的热修复方案如下图

文章图片

从这里可以看到tinker的热修复是不能即时生效，用专业术语来说就是需要冷启动，即需要退出/杀掉app进程，再启动方能完成补丁功能修复。bugly的热修复的实现机制见下图

文章图片

补丁包是通过对比基线版本和修复版本（修改bug得到的版本）差分(diff)出来的。
更详细的集成文档可以参考bugly,下面着重说下需要注意几点的。
1.可用Bugly的方案替换tinker的默认实现

overrideTinkerPatchConfiguration = true//是否启用覆盖tinkerPatch配置功能，默认值false //如果是false的话需要添加下面代码 tinkerPatch {//这是tinker的实现方式 //oldApk ="${bakPath}/${appName}/app-release.apk" ignoreWarning = false useSign = true ''' }

2.配置Tinker的接入方式

enableProxyApplication = false//默认值是false, //true的情况不需要关注 //false的情况需要如下编码，代码有简化 public class SampleApplication extends TinkerApplication { public SampleApplication() { super(ShareConstants.TINKER_ENABLE_ALL, "xxx.xxx.SampleApplicationLike", "com.tencent.tinker.loader.TinkerLoader", false); } } public class SampleApplicationLike extends DefaultApplicationLike { @Override public void onCreate() { super.onCreate(); // 这里实现SDK初始化，appId替换成你的在Bugly平台申请的appId // 调试时，将第三个参数改为true Bugly.init(getApplication(), "900029763", false); } }

3.生成基准包
首先，在tinker-support.gradle文件里，你需要修改

tinkerId = "1.0.1-base"//可以通过代码自动生成。通过获取版本号来生成。

【Android|谈谈bugly的补丁升级】注意这个tinkerId只要是唯一的就行，习惯的命名规则是versionName.versionCode-base。然后调用assembleRelease,会生成下面目录

文章图片

注意app-0515-16-50-33, 是bugly自动生成的目录，是根据模块名+时间戳的规则。
4.生成补丁包
在tinker-support.gradle文件里，我们需要关注两个地方

/** * 这个就是我们上面生成的目录名称 */ def baseApkDir = "app-0515-16-50-33"//这个跟build/bakApk下面对应的基准包目录一致tinkerId = "1.0.1-patch"//也是唯一的，习惯规则跟上面一样; 它和基线包的tinkerId没有什么关系，因为这是在打补丁包，所以习惯的规则是加-patch

配置玩这些后，调用buildTinkerPatchRelease命令，会生成目录如下

文章图片

5.上传补丁包
上传补丁包需要注意的几点

在上传补丁包之前，你先需要确认补丁包对应的版本已经联网使用过了
上传patch目录下面的patch_signed_7zip.apk

6.相关的策略
a.下发范围，如下图

文章图片

开发设备，通过如下代码定义

// 设置开发设备，默认为false，上传补丁如果下发范围指定为“开发设备”，需要调用此接口来标识开发设备 Bugly.setIsDevelopmentDevice(getApplication(), true);

全量设备，所有安装过对应版本的设备
自定义，见下图

文章图片

可以修改下发数量和系统版本。没有足够的手机可以测试，可以通过腾讯优测来辅助测试。

b.停止下发和撤回

文章图片

停止下发，顾名思义就是这个补丁不会被APP检测到
撤回，需要注意两点。一旦撤回，应用过该补丁的版本都会被恢复到原状态，比如应用补丁之前有bug, 该补丁是用来修复bug，被撤回之后bug会继续存在；而且补丁一旦测绘，就不能在编辑了，如下图只能查看历史

文章图片

7.支持多渠道，但是支持的很简单，详细可以参考bugly
8.可以加固方案，支持情况如下图

文章图片

需要注意的一点，我们安装的版本是加固后的版本，但是我们在生成补丁包的流程和上面完全一样【不是想象中的加固后的版本作为基线版本】。
汇总一下，补丁升级很好用，但是一定要慎重使用。一旦滥用就会导致正常升级和补丁升级混乱不堪。推荐场景：发布一个上线版本，在半天/一天的时间内，如果有问题，赶紧汇总，如果有bug或者非常必要的修改，则发布补丁。切记不要一个版本发布太多补丁。