Bugly使用——热修复

项目中之前已经接入bugly的异常收集和全量更新SDK，为了应对bug及时修复以及一些改动不太大的需求，准备接入Tinker。而Bugly已经对Tinker做了很好的支持，不用从头到尾接一遍。
Bugly 集成就包含了上报，升级，热修复三合一。

思考

遇到的问题
1、基准包打出来后必须要进行联网上报，意思就是说要在有网络的手机上启动一次，Bugly才能上报TinkerId，基于这个版本生成的补丁包就可以匹配到它
2、两次传入的tinkerId是否一样？
不一样的，编译补丁包时，tinker会自动读取基准包AndroidManifest的tinkerId作为package_meta.txt中的TINKER_ID。将本次编译传入的tinkerId，作为package_meta.txt的NEW_TINKER_ID。

你必须要上传build/outputs/patch目录下的补丁包，

每次发版都要保留基准包、混淆配置文件、资源Id文件？
当然啦，你不保存基准包，我们打补丁怎么知道要基于哪个版本打补丁？所以建议大家每次发版注意保存基准apk包，还有对应编译生成的mapping文件和R.txt文件。

Q：完整的测试流程是怎样的？

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

为什么我的补丁包上传匹配到的不是我的基准包版本？

原因：你之前测试时使用过和当前基准包版本一样的tinkerid，bugly补丁下发是按照tinkerid下发。多个基准包使用了同一个tinkerid那说明这几个基准包都能收到你当前上传的补丁。

对Tinker的理解

、首先，你需要了解 TinkerId ，相信很多人看他官方的文档后都知道这个东西，
1、他需要在生成基准包（你要正式往线上发布的版本）的时候设置tinkerID
2、在打补丁的时候还需要再次设置tinkerID，而且这次的tinker和第一步的id不能相同
很多人对此是很不理解的？原来，你在第一步生成基准包的时候，tinker插件会自动将tinkerID和App当前的版本Version对应起来。例如，你当前的app版本是2.3.1.30，tinkerID设置为2.3.1.30-base，那么这个2.3.1.30和2.3.1.30-base就会对应起来，tinker插件会自动在打包的时候插入到Mainfest.xml文件中。
好了，下面你的2.3.1.30版本app发现问题，你需要打一个补丁包进行修复，这时候你需要再次设置tinkerID为2.3.1.30-patch-03。tinker插件会自动把基准包的的tinkerID和本次补丁包的tinkerID保存在插件中。此时，当你将这个补丁上传至bugly平台，
你的补丁id为2.3.1.30-patch-03 —> 基准包id 2.3.1.30-base ---> 你出现问题的App版本2.3.1.30

image.png

一、添加插件依赖，在根目录的build.gradle中：

classpath "com.tencent.bugly:tinker-support:1.1.1"

二、集成SDK：

   app module的build.gradle中添加多dex配置、 添加bugly  dependencies

   //Tinker
    compile "com.android.support:multidex:1.0.3" // 多dex配置
    //注释掉原有bugly的仓库
    //compile 'com.tencent.bugly:crashreport:latest.release'//其中latest.release指代最新版本号，也可以指定明确的版本号，例如1.3.4
    compile 'com.tencent.bugly:crashreport_upgrade:1.3.6'
    // 指定tinker依赖版本（注：应用升级1.3.5版本起，不再内置tinker）
    compile 'com.tencent.tinker:tinker-android-lib:1.9.9'
    compile 'com.tencent.bugly:nativecrashreport:3.6.0'
    //其中latest.release指代最新版本号，也可以指定明确的版本号，例如2.2.0

app module的build.gradle中添加依赖插件脚本：

// 依赖插件脚本
apply from: 'tinker-support.gradle'

三、初始化SDK：

Tinker 初始化分为两种情况本文采用不用改造Application的情况，
据官方描述，改造Application的初始化方式兼容性会比不改改Application 要好
官方初始化参考
取 enableProxyApplication = true的情况
在自己的Application里面添加如下代码，别忘记在配置文件配置Application

 public void onCreate() {
        super.onCreate();
        if (sInstance == null) {
            sInstance = this;
        }
        // 这里实现SDK初始化，appId替换成你的在Bugly平台申请的appId
        // 调试时，将第三个参数改为true
        Bugly.init(this, "c45d2fc4ba", true);

    }
    @Override
    protected void attachBaseContext(Context base) {
        super.attachBaseContext(base);
        // you must install multiDex whatever tinker is installed!
        MultiDex.install(base);
        // 安装tinker
        Beta.installTinker();
    }

到此为止 Tinker的接入已经全部完成，接下来看他是如何使用的，

1、编译基准包

配置基准包的tinkerId

tinkerId最好是一个唯一标识，例如git版本号、versionName等等。如果你要测试热更新，你需要对基线版本进行联网上报。

这里强调一下，基线版本配置一个唯一的tinkerId，而这个基线版本能够应用补丁的前提是集成过热更新SDK，并启动上报过联网，这样我们后台会将这个tinkerId对应到一个目标版本，例如tinkerId = "bugly_1.0.0" 对应了一个目标版本是1.0.0，基于这个版本打的补丁包就能匹配到目标版本。

执行assembleRelease编译生成基准包：