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
热更新SDK
注意:升级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中配置一句代码:

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

注释掉以前的配置:

1
2
3
4
// 可选,用于生成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插件即可:

1
2
3
4
5
// 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。

Alt
Alt

但要注意Tinker官方的提示:

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

Q:是否支持打多Flavor的patch包
A:支持的。你需要配置productFlavor(示例):

1
2
3
4
5
6
7
8
9
productFlavors {
xiaomi {
applicationId 'com.tencent.bugly.hotfix.xiaomi'
}
yyb {
applicationId 'com.tencent.bugly.hotfix.yyb'
}
}

打flavor包,只需要配置构建flavor的目录,其他字段不需要填写(执行tinkerPatchAllFalvorRelease就可以得到所有flavor的包):

flavor路径配置
flavor路径配置
打flavor的Task
打flavor的Task

总结&展望

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