谈谈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"//可以通过代码自动生成。通过获取版本号来生成。

注意这个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或者非常必要的修改,则发布补丁。切记不要一个版本发布太多补丁。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值