前天晚上使用bugly实现版本更新的时候,我突然发现bugly更新版本了,并且增加了一个重大的更新,我立马就充满鸡血,立马想尝试一下。毕竟我前几个月研究了一下热更新能力了,个人感觉微信的tinker比较强大一点,一下是对比图,不过我去看微信tinker的git跟着实现起来我却显的很无奈了,今天看到bugly已经集成进去了,让我感到非常happy,接下来我和大家一步一步实现bugly的热更新吧!!fixbug!!!!
在开始讲解之前,可能有的人觉得很奇怪为什么要用bugly来集成,我拷贝官网的话给大家看看。
为什么使用Bugly热更新?
1、无需关注Tinker是如何合成补丁的
2、无需自己搭建补丁管理后台
3、无需考虑后台下发补丁策略的任何事情
4、无需考虑补丁下载合成的时机,处理后台下发的策略
5、我们提供了更加方便集成Tinker的方式
6、我们通过HTTPS及签名校验等机制保障补丁下发的安全性
7、丰富的下发维度控制,有效控制补丁影响范围
8、我们提供了应用升级一站式解决方案
我就特别喜欢这种简单快捷的实现方式。
废话不再多说,大家跟着我一起来敲键盘吧!!!
1、我们在项目中的build.gradle文件中加入:
// tinker gradle插件
classpath ('com.tencent.tinker:tinker-patch-gradle-plugin:1.7.5')
// tinkersupport插件
classpath"com.tencent.bugly:tinker-support:latest.release"
注意:指定tinker插件版本为1.7.5,避免因为插件版本的变更导致补丁包的生成的问题。
2、在app module的“build.gradle”文件中添加如下配置(内容比较多粘贴内容你们看的也累也看不出什么东东,我截图标注几点重要的地方给大家注意下,文末给出链接大家加载参考)
添加依赖:
// 多dex配置
compile'com.android.support:multidex:1.0.1'
// 集成Bugly热更新aar(灰度时使用方式)
// compile(name: 'bugly_crashreport_upgrade-1.2.0', ext: 'aar')
compile'com.tencent.bugly:crashreport_upgrade:latest.release'
以上就是app的gradle要特别注意的几点,接下来我们继续撸码
3、自定义Application
-SampleApplication 不做任何操作,所有Application的代码都会放到ApplicationLike继承类当中
-SampleApplicationLike 这个类是Application的代理类,以前所有在Application的实现必须要全部拷贝到这里,在onCreate方法调用SDK的初始化方法
4、本章的重点出来了,就是修复代码工作:
看一下错误代码,我讲算术除于0,结果大家都知道,肯定挂了,不信,截图
注意:这个有bug的app就是官网所说的基准包了,即要修复的版本应用。
-修正代码 Fixbug,然后执行以下动作制作补丁
bugly控制台,大家可以看到我上面有2.0以后的补丁,其实我也现在又个很纳闷的问题,就是如果我下发的补丁规则是开发设备就不会下载补丁,有知道的大神可以教教我么?或许我们可以互相探讨一下。(感谢@__Berial___ 指出开发设备要在代码中加入一句:Bugly.setIsDevelopmentDevice(this, true);)
一大早我就过来尝试一下tinker强大的功能:新增方法,新增类和资源文件,接下来的修改代码我就不更新到githut,大家可以下载我的源码随便去搞搞研究一下
测试添加方法和新增一个类:
我们结束一下应用再进来,看到界面成功输出
在资源中新增一个图片,在布局中加入Imageview控件
在代码中找出该控件,并设置点击事件修改图片显示
为了给真实的数据给你们,我也想亲手实践才好壮大我的胆去吹牛逼啊,所以我在官网拼命上传补丁,真心不容易,不过看到最终出来的效果,爽爽的
注意坑:如果生成补丁的时候,提示的错误,不慌不忙,去检查一下混淆规则,我就是爱装逼,顺手把教程的混淆规则全拷上去了,我项目中没用到v4包,但是按道理应该没事吧,但是删除v4包的混淆就没事了
接下来我们手工打道回府,哈哈、、如有错误请多多包涵,并教一下小弟,也可交流一下技术。