Bugly热更新SDK你需要知道的一些事

Bugly出热更新SDK了？

没错，Bugly也出热更新SDK啦，2016.11.25号，我们Bugly也上线了Android版的热更新SDK，大家都知道这一年来热更新被无数次提起，各大厂自主研发的热更新方案层出不穷，下面就列举一些大家比较熟悉的一些热更新方案：

微信开源：Tinker 大众点评：Nuwa 阿里巴巴：Dexposed 阿里巴巴：AndFix 美团：Robust

各个方案的优劣性笔者就不在这里做过多讨论了，总的一句话没有最好的，只有最适合自己的。

我们Bugly也是出于高可用性的考虑，Tinker支持动态下发代码、So库以及资源，所以我们最终选择了Tinker方案作为我们SDK的一项能力。

这里有一点需要说明的，Android版的热更新SDK是包含在升级SDK里面的，所以如果你想使用我们提供的热更新能力需要下载对应版本的升级SDK，目前我们在1.2.0版本才开始支持热更新：

注意：升级SDK自1.2.0起将不再支持以jar包形式集成，我们建议您使用Android studio并且以gradle方式集成。

为什么集成我们Bugly热更新SDK？

热更新能力是Bugly为解决开发者紧急修复线上Bug，而无需重新发版让用户无感知就能把问题修复的一项能力。Bugly目前采用微信Tinker的开源方案，开发者只需要集成我们提供的SDK就可以实现自动下载补丁包、合成、并且应用补丁的功能，我们也提供了热更新管理后台让开发者对每个版本的补丁进行管理。

集成我们SDK的好处是显而易见的：

• 无需关注Tinker是如何合成补丁的
• 无需自己搭建补丁管理后台
• 无需考虑后台下发补丁策略的任何事情
• 无需考虑补丁下载合成的时机，处理后台下发的策略
• 我们提供了更加方便集成Tinker的方式
• 我们提供应用升级一站式解决方案

如何集成Bugly热更新SDK？

看文档、看文档、看文档。重要的事情说三遍。 Android热更新接入指南

相信接入过Tinker的同学会发现使用Tinker还是有一定门槛的，小白用户第一次使用可能会懵圈，我们Bugly也希望能让第一次接入的同学能顺利使用上热更新，所以建议大家严格按照我们文档的流程来接入，如果遇到任何使用SDK的问题可以及时跟我们反馈（交流群号：130979883），但如果是Tinker插件的使用问题也是建议您认真查看Tinker Wiki。

简单概要说一下整个接入流程：

1. 配置插件依赖（这里包含tinker插件和tinker-support插件的依赖）
2. apply插件（这里可以只配置apply plugin: 'com.tencent.bugly.tinker-support'）
3. 集成SDK
   • 集成远程SDK仓库
   • 重新自定义Application、ApplicationLike
   • AndroidManifest配置
   • 混淆配置
4. 测试验证
   • 打基准包安装并上报联网（注：填写唯一的tinkerId）
   • 对基准包的bug修复（可以是Java代码变更，资源的变更）
   • 修改基准包路径、填写补丁包tinkerId、mapping文件路径、resId文件路径
   • 执行tinkerPatchRelease打Release版本补丁包
   • 选择app/build/outputs/patch目录下的补丁包并上传（注：不要选择tinkerPatch目录下的补丁包，不然上传会有问题）
   • 编辑下发补丁规则，点击立即下发
   • 重启基准包，请求补丁策略（SDK会自动下载补丁并合成）
   • 再次重启基准包，检验补丁应用结果

以上是应用补丁的流程，有同学可能会问，如果我想撤回怎么办？这里先解释下我们补丁的几种状态：

• 下发中
• 生效中、下发停止
• 撤回中

下发中：表示你上传一个补丁后，点击立即下发之后的状态，表示后台正在下发补丁策略，补丁包对应的基线版本是可以收到对应的策略的。

生效中、下发停止：表示你已经下发过这个补丁，但因为你上传了新补丁，这个补丁下发会被停止，要注意一个目标版本只运行下发一个补丁。

撤回中：表示你不再下发这个补丁，这个操作是不可逆的，点击撤回，基线版本将不会再收到这个补丁策略。

以上就是Bugly热更新SDK的集成方式一些说明啦，如果还有疑问直接找Bugly-kirito咨询。

一些大家比较关注的问题

Q：Bugly热更新会收费么？

A：大家可以放心，我们热更新服务目前是完全免费的。

Q：之前使用Tinker，怎么切换过来使用Bugly？

A： 你只需在dependencies中配置一句代码：

    compile "com.tencent.bugly:crashreport_upgrade:1.2.0"

注释掉以前的配置：

    // 可选，用于生成application类 
    //provided('com.tencent.tinker:tinker-android-anno:1.7.5')
    // tinker的核心库
    // compile('com.tencent.tinker:tinker-android-lib:1.7.5')

插件配置不需要更改，只需要加上我们Bugly额外的tinker-support插件即可：

     // tinker gradle插件
     classpath ('com.tencent.tinker:tinker-patch-gradle-plugin:1.7.5')

     // tinkersupport插件
     classpath "com.tencent.bugly:tinker-support:1.0.1"

这里建议您不要随便更改插件版本，避免因为插件的更新导致您无法正常生成我们需要的补丁包。

Q：如果我配置了升级策略，又配置了补丁策略，会是怎样的效果？

A：升级策略优先级会高于补丁策略，后台会优先下发升级策略。毕竟你都要升级了，热更新只是帮助你修复bug而已。

Q：我只想使用热更新，不想使用升级？

A：热更新是包含在升级SDK里面的，你可以不配置任何升级策略，只需按照热更新文档集成即可。

Q：是否支持加固模式？

A：tinker是支持加固模式的，但需要你回退到Qzone方案 ，将usePreGeneratedPatchDex设置为true。

但要注意Tinker官方的提示：

是否提前生成dex，而非合成的方式。这套方案即回退成Qzone的方案，对于需要使用加固或者多flavor打包(建议使用其他方式生成渠道包)的用户可使用。但是这套方案需要插桩，会造成Dalvik下性能损耗以及Art补丁包可能过大的问题，务必谨慎使用。另外一方面，这种方案在Android N之后可能会产生问题，建议过滤N之后的用户。

Q：是否支持打多Flavor的patch包 A：支持的。你需要配置productFlavor（示例）：

  productFlavors {
        xiaomi {
            applicationId 'com.tencent.bugly.hotfix.xiaomi'
        }

        yyb {
            applicationId 'com.tencent.bugly.hotfix.yyb'
        }
    }

打flavor包，只需要配置构建flavor的目录，其他字段不需要填写（执行tinkerPatchAllFalvorRelease就可以得到所有flavor的包）：

总结&展望

关于Bugly热更新SDK你需要知道的一些事情，笔者已经讲完啦，如果你在使用过程中遇到任何问题可以及时跟我们反馈，我们会持续跟进优化SDK和完善接入流程，后续我们会分享更多我们Bugly关于热更新的一些技术和原理上的理解，希望本篇文章能够让使用Bugly热更新SDK的同学和想了解我们热更新的同学的有一些解惑。