前天晚上使用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包的混淆就没事了
接下来我们手工打道回府，哈哈、、如有错误请多多包涵，并教一下小弟，也可交流一下技术。
