集成bugly热更新心得
前言
因项目需求，研究热更新。调查各种开源框架，最终选择腾讯平台bugly热更新，踏上了踩坑之旅。
遇到的问题
1.兼容性问题
2.配制gradle
3.打基线包与补丁包
4.依赖库版本问题
测试流程
1.配置基准包的grald,修改两个地方（1.基准包生成路径 baseApkDir，2.tinkerId 保证为一性）
2.运行gradle打出基准包安装并上报联网
3.修复基准包的bug（可以是Java代码，可以是资源文件，可以是so库文件）
4.修改基准包路径、修改补丁包tinkerId、mapping文件路径（如果开启了混淆需要配置）、resId文件路径
5.执行buildTinkerPatchRelease打Release版本补丁包
6.选择app/build/outputs/patch目录下的补丁包并上传（坑1：一定要基准包上报联网，不然上传补丁包会报错）
7.编辑下发补丁规则，点击立即下发
8.重启APP，看打印log，是否成功下发补丁（坑2:如果版本不一样，下发成功之后，补丁包也不会激活）
9.查看问题是否被修复
第一步：添加插件依赖
在工程根目录project:xxx下“build.gradle”文件中添加：
第一步.png
classpath "com.tencent.bugly:tinker-support:latest.release"
上面latest.release代表匹配插件最新版本
第二步：集成SDK，配制gradle
1.在app module的“build.gradle”文件中添加（示例配置）：
image.png
multidex:1.0.1:支持多dex配置
crashreport_upgrade:bugly依赖仓库
nativecrashreport:指的是支持ndk配置，如果不需要可以去掉
a.compile "com.android.support:multidex:1.0.1"
b.compile "com.tencent.bugly:crashreport_upgrade:1.3.4"
c.compile 'com.tencent.bugly:nativecrashreport:latest.release'
2.依赖插件的脚本
image.png
b.在build.gradle当中引用
image.png
c.配置tinker-support.gradle，这些配置官方文档都有直接copy过来
image.png
这里有几个重要的参数：1.baseApkDir，在这里它指的是我们要打出的补丁包的所对应的基准包路径名，不能随便写。
2.tinkerId：在这里他代表基准包的唯一性（注意：基准包不能和补丁包tinkerId一样）.
3.enableProxyApplication:这里指的是：如果是true代表自己写appllicion，如果是false需要继承tinker自带的，默认是为 false。（官方给得解释是：如果是true,需要通过反射获取我们的appliction,兼容性不太好，false继承tinker自带的，但扩展性不高，需根据项目来做判断）。
第三步：初始化sdk
1.初始化appliction
image.png
注意：appId，一定要修改为平台申请appId,不然补丁会修复失败，如果是测试那么isDebug改为true,正式版本的时候改为false。
第二种情况enableProxyApplication = false, 继承TinkerApplication
image.png
注意：delegateClassName:一定修改为自己项目当中的SampleApplicationLike包名，这里容易忽略掉。
2.自定义的SampleApplicationLike
image.png
注意：appId同上修改为平台申请的appId,调试时改为true,上线时改为false.
第四步：AndroidManifest.xml配置
1.配置权限
image.png
2.活动配置，如果您想兼容Android N或者以上的设备，必须在AndroidManifest.xml文件中配置FileProvider来访问共享路径的文件。
image.png
第五步：混淆配置
1.为了避免混淆SDK，在Proguard的混淆文件中增加以下配置：
-dontwarn com.tencent.bugly.**
-keep public class com.tencent.bugly.*{;}
2.如果你使用了支持-V4包，你还需要配置以下混淆规则：
-keep class android.support.*{;}
image.png
到这里基本工作完成，细心点，不会出什么问题。接下来准备打基准包和补丁包了。
第六步：基准包
1.编译基准包
image.png
修改tinkerId,保证它的唯一性，这里最好和 自己app版本保持一致，方便维护
2.执行assembleRelease编译生成基准包：
image.png
会在app/build/bakApk生成一个这样的文件
image.png
这里面有的app-release.apk就是我们需要上线的基线版本，请注意保存线上发布版本的基准apk包、mapping文件、R.txt文件，如果线上版本有bug，就可以借助我们tinker-support插件进行补丁包的生成。
image.png
查看tinkerId，是否和设置的一样。（注意，sdk 自动在tinkerId加一个前缀）这就是基准包啦，是不是很简单？
第六步：生成补丁包
1.修改baseApkDir路径为基准包路径
image.png
2.修改tinkerId,(注意这里的tinkerId,不能和基准包的tinkerId一样)
image.png
3.第三步，修复bug
这里会报空
image.png
修改后
image.png
4.执行构建补丁包的task
image.png
如果你要生成不同编译环境的补丁包，只需要执行TinkerSupport插件生成的task，比如buildTinkerPatchRelease就能生成release编译环境的补丁包。
生成的补丁包在build/outputs/patch目录下，其中7zip.apk就是我们需要使用的补丁包：
image.png
这个就是补丁包了，查看是否成功
image.png
这里的from代表基准包tinkerId,to为补丁包的
第七步上传补丁包到平台
image.png
发布patch版本，选择补丁文件之后会自动从补丁包的YAPATCH.MF去寻找base版本以及app版本，注意这里的base版本必须联网上报（必须在联网的情况下启动app），才可以上传补丁成功。如果没有上报联网会提示你无法找到相应的版本
上传了补丁包可以选择下发的范围：
开发设备：仅仅针对设置了开发设备。
利用代码：Bugly.setIsDevelopmentDevice(this, true);设置为开发者设备。
全量设备：针对所有的用户。
自定义：可以设置下发范围:随机下发设置的版本数量，还可以设置android版本范围，仅仅在这个范围内才会下发并且生效。
下发补丁之后：
image.png
第八步测试是否成功
这里就不再进行演示了
需要注意两个地方
1.APP需要重新启动，等一小会就成功 了
2.查看控制台打印的log日志，如果成功会打印上传补丁包的备注信息
3如果以上操作都正确，还是没有成功，请查看设置是否激活，如果没有激活，看下依赖库版本是否一致，如果不一致，会在控制台打印
tinker patch exception com.tencent.tinker.loader.TinkerRuntimeException: Tinker Exception:can't recognize dex mode:xxxxx,jar
把版本改成一到处就OK了。
