android热更新之Bugly

有一段时间没有更新博客了，主要是快毕业了，出来实习找工作，现在在一家公司做安卓，今天是上班的第三天，前两天了解了一下项目，现在项目需要增加热更新方案，于是我研究了一下市场上的开源方案，今天注重讲一下腾讯的bugly。（本文只是对bugly的大致流程进行梳理，并对一些常见的错误进行解释，适合看过bugly官方文档但是没有集成成功的人）
首先说一下市场上常见的几种开源方案：Tinker、 Qzone、AndFix、Robust。bugly是基于Tinker实现的。
下面有一张他们的对比图片，是在Tinker的wiki上下载的，由于这几种框架一直在更新，所以现在的情况不一定是这样，大家可以去他们各自的主页查看，

进入正题，bugly的使用在官方文档中写的很清楚，我这里只写一下每一个步骤的注意事项和我踩过的坑，bugly的导入步骤如下：

1. 添加插件依赖，这个步骤没有什么好讲的，也没有什么坑，注释也写得很清楚。
2. 初始化SDK，这里讲一下，初始化SDK分为两张情况：使用原来的Application（enableProxyApplication = true）和改造Application（enableProxyApplication = false）。使用原来的Application没有什么好讲的，主要就是初始化的参数Bugly.init(this, “900029763”, false)，第二个参数是你在bugly平台申请的AppId，第三个参数是是否打印log，在我们调试的时候将他设置为true，他可以检查我们的应用是否集成成功；改造Application稍微麻烦一点，但这是官方推荐的方案，比较稳定，这里我们需要两个类，一个是继承TinkerApplication的类，还有一个是继承DefaultApplicationLike的类，并且注意继承TinkerApplication的类只能实现一个构造函数，其他的操作都要放在继承DefaultApplicationLike的类中，之前在Application里的代码都要放到这里。最后强调一点，不要把enableProxyApplication搞错了 ，否则什么都没用。
3. AndroidManifest.xml配置，这一步里主要是有一个配置FileProvider，如果您的应用想兼容Android7.0，那么这一步是必须的，如果不是可以省略。
4. 混淆配置，这一步没什么好讲的，根据需求来。

到这里bugly的配置就完成了，配置没有什么大的坑，一步步来就行了。
下面开始正式内容，bugly的使用，官方给的接入流程还是很详细的：

下面我们就讲一下每一个步骤的注意事项：

1. 编译基准包，也就是你正常发布的apk包，这里只需要修改一下tinkerId这个参数，一般的写法是“base-1.0.1”，注意base关键字和版本。我们前面配置了bugly，但是我们怎么知道有没有配置成功呢，这时候就可以验证了，我们将编译的基准包安装在设备上，此时查看log日志，如果有下面这句话代表成功了：
   

2. 对基线版本的bug修复，就是把原来的bug修改掉。

3. 根据基线版本生成补丁包，现在来到重点了，这一步的关键是修改appName、tinkerId这两个参数的值，appName就是你原来的有bug的apk所在的目录，tinkerId是将base修改为patch，版本号不变。生成的补丁包在build/outputs/patch目录下。
4. 上传补丁包到平台，这一步成功就代表你集成完成了，特别注意：上传补丁包之前首先有bug的apk要联网上报过数据，否则是匹配不到版本的。

到这里bugly的使用就结束了，这么高大上的功能使用起来还是挺简单的