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