热更新实践：Bugly热更新打包及修复

上一篇【热更新：使用Bugly集成的Tinker】主要是说的配置，配置Tinker确实很麻烦，当然好处也是很大的。不仅支持各种类，so，资源的替换，体积也较小，是一款很强大的热修复工具。妈妈再也不用担心我们被h5替代了！

都配置好了，肯定要实践一下来能体会它到底有多强大！

第一步：打基准包

在tinker-support.gradle中配置基准包的tinkerid

tinkerId最好是一个唯一标识，例如git版本号、versionName等等。 如果你要测试热更新，你需要对基线版本进行联网上报。
这里强调一下，基线版本配置一个唯一的tinkerId，而这个基线版本能够应用补丁的前提是集成过热更新SDK，并启动上报过联网，这样我们后台会将这个tinkerId对应到一个目标版本，例如tinkerId = "bugly_1.0.0" 对应了一个目标版本是1.0.0，基于这个版本打的补丁包就能匹配到目标版本。

执行assembleRelease编译生成基准包,官方文档是这么说的，可我真不会打这个assembleRelease，平时要么直接运行，要么直接就打包！

这里遇到一个坑，就是直接运行是运行不起的，报错！到处找寻答案，最后是一个大神说是因为和instant run不兼容，需要关闭！

取消Instant Run

最后在群里面问道了执行的方法，原来在最右边的Gradle里面

assembleRelease.png

用了快一年的AS,还不知道如何打基准包，惭愧啊！
查了很多资料才知道没有什么基准包，只是这种打包的方式和手动打包有所区别。其实也就是打一个安装包而已！

在这里我不得不说我又遇到了一个问题，就是打出来的包和官方的不一样。我不仅仅说的是名字不一样，而是我打出来的包根本没有签名！是下面这样的：

我打的基准包

于是我又开始查我的包为什么不一样，发现根本找不到答案。其实从名字就可以看出，其实是我打的包没有签名！于是就去查如何用assembleRelease签名打包！又查了一天才知道了原来有手动打包和自动打包的区别！

手动打包：就是通过AndroidStudio工具栏的Build->Generate signed APK...来打包

手动打包

自动打包：通过在Gradle中配置signingConfigs来，然后点击右边当前项目下的assembleRelease命令来打包

自动打包

自动签名参考 :AndroidStudio配置gradle，让App自动签名
最开始我还把没有签名的unsign.apk用360工具来签名打包，累死个人，现在想想当初自己是有多蠢啊！

注意：这个打好的基准包需要安装到手机上面，联网的情况下打开以下为后面的补丁包做准备，也就是官方说的联网上报。后台logcat可以看日志输出，官方图如下：

联网上报

第二步：打补丁包

打补丁包之前要修改你项目的东西，这样才能有所区分，这个我就不说了！关键是要修改tinker-support.gradle里面的配置，appName的名字一定要是你打的基准包的目录的名字，不然会报找不到oldapk的错误，同时还要修改tinkerId字段！

tinker-support.gradle文件修改

项目和这个文件修改只有，点击buildTinkerPatchRelease就可以了，之前我没有配置自动签名，打这个补丁包都打不了！

打补丁包

生成的补丁包在build/outputs/patch/release目录下（官方在build/outputs/patch下，不知道我自己为什么多个了release）：

补丁包位置

第三步：上传下发补丁

就是进入Bugly官方，进入你当前项目，在应用升级里面可以找到热更新，上传patch_signed_7zip.apk这个文件，然后立即下发！

QQ截图20170224154323.png

第四步：测试

测试的时候，一定要把这个应用彻底关闭后再启动，修改才会生效！

总结：
写这个整整用了我一周的时间，因为在其中遇到了太多别人和官方没有问题（官方不会教你自动签名的配置，因为那不是它的事），也因为很多配置都看不明白，只会依葫芦画瓢，所以进度很慢，同时也学到了很多。特别是经历重重困难后终于测试成功，代码展现后的喜悦只能用以泪洗面，哭着笑了来形容！在此记录下来，献给奋斗在代码前线的同僚们，坚强不息，代码不止！