最开始的时候是为了使用腾讯的bugly框架来抓取app中的crash，后来又看到了腾讯的bugly框架之后续，比如自动更新，热修复等等，这篇文章记录的主要是bugly介入的流程和遇见的坑（本篇文章不包括集成crash时的符号表插入和热更的so更新，这些功能会在下篇文章中去更新）
首先来说一下集成bugly中crash的流程
https://bugly.qq.com/docs/user-guide/instruction-manual-android/?v=20180709165613
腾讯官方地址，这个是比较简单的，按照这个流程一步一步走下去就可以完全搞定。
如果自动集成NDK之后出现以下的错误信息
NDK integration is deprecated in the current plugin. Consider trying the new experimental plugin.
则在项目根目录的gradle.properties文件中添加：
android.useDeprecatedNdk=true
注意 ：集成Bugly NDK时，需要同时集成Bugly SDK。但是集成SDK的时候不一定要集成NDK
注：如果您的App需要上传到，您需要将google play store
权限屏蔽掉或者移除，否则可能会被下架。READ_PHONE_STATE
- 请避免混淆Bugly，在Proguard混淆文件中增加以下配置：
-dontwarn com.tencent.bugly.**
-keep public class com.tencent.bugly.**{*;}
最简单的初始化
获取APP ID并将以下代码复制到项目Application类onCreate()中，Bugly会为自动检测环境并完成配置：
CrashReport.initCrashReport(getApplicationContext(), "注册时申请的APPID", false);
为了保证运营数据的准确性，建议不要在异步线程初始化Bugly。
第三个参数为SDK调试模式开关，调试模式的行为特性如下：建议在测试阶段建议设置成true，发布时设置为false。
- 输出详细的Bugly SDK的Log；
- 每一条Crash都会被立即上报；
- 自定义日志将会在Logcat中输出。
增加上报进程控制
UserStrategy strategy = new UserStrategy(context);
//strategy.xxx()设置需要控制的属性 具体属性如下
https://bugly.qq.com/docs/user-guide/advance-features-android/?v=20180709165613
CrashReport.initCrashReport(context, "注册时申请的APPID", isDebug, strategy);
以上就是crash的功能的简单使用，
如果你嫌弃这个过程太麻烦了，恭喜你，你可以不用看这个了 ，因为下面的自动更新和热修复已经及把Crash功能合并在其中了，当然要增加上报进程控制一样可以如此
UserStrategy strategy = new UserStrategy(context);
//strategy.xxx()设置需要控制的属性 具体属性如下
https://bugly.qq.com/docs/user-guide/advance-features-android/?v=20180709165613
Bugly.init(getApplication(),"注册时申请的APPID",true，strategy );
=============================================分割线=============================================
基于bugly的自动更新
https://bugly.qq.com/docs/user-guide/instruction-manual-android-upgrade/?v=20180709165613
腾讯官方文档
按照官方文档来走也是肯定会成功的，
在此仅记录遇见无法更新的问题，
//设置本机为测试开发设备
// Bugly.setIsDevelopmentDevice(getApplication(),true);
很是奇怪，我设置本机为开发测试设备之后竟然收不到更新提示，所以我果断把此方法注释掉了
在后来我发现了自动更新的全量更新，也就是所有设备的，所以无法更新的原因不在于此，最后发现，当确认当期版本无误之后，官方给的时间是在3s，但是我自己在能提示更新的时间大概在2分钟之后，（可能因为网速问题，更新提示有延迟）
自动更新在初始化之后就已经调用了，如果后续还需要，那个调用Beta.checkUpgrade(false,false)方法，
参数1：isManual 用户手动点击检查，非用户点击操作请传false
参数2：isSilence 是否显示弹窗等交互，[true:没有弹窗和toast] [false:有弹窗或toast]
默认的Beta.checkUpgrade() == Beta.checkUpgrade(true,false)
还有比较蒙的一点就是，所有的版本的竟然可以在同一时间段同时启动，这时候我就比较好奇了，我到底更新的是哪一个版本，难道是随机的吗？这个问题现在还没有去测试，等有时间测试完成之后会贴上的！！！
之前一直不知道这个策略名称到底是干啥用的，后来发现这只是一个标题的作用
更新和热修复都有一个beta属性，具体属性如下
https://bugly.qq.com/docs/user-guide/advance-features-android-beta/
=============================================分割线==============================================
crash的抓取和自动更新这一块按照文档走，只要你的配置没有问题，注册的appid没有问题，权限没有问题，网络没有问题，那就没有其他问题了，热更感觉坑就多了很多了，
首先
官方文档为了让我们能更好的学习热更技术，给我们提供了很多便利，比如bugly的热更是基于微信tinker开发的，我们只用去配置少量的代码就能集成热更功能，再比如，在页面的最上面给出了视频教程，等等
孰能想到这和竟然是空的，如果想看视频的同学需要去自己找
课时1：Bugly热更新介绍
https://v.qq.com/x/page/w0384j4xrnd.html
课时2：tinker-support插件的使用
https://v.qq.com/x/page/o03855ejzf4.html
课时3：集成Sdk
https://v.qq.com/x/page/e03855m02j8.html
课时4：生成补丁包之痛 我懂你
https://v.qq.com/x/page/i0385n7ncro.html
课时5：补丁包为何传不上去
https://v.qq.com/x/page/e0385shcfzm.html
课时6：普通打包的热更新
https://v.qq.com/x/page/k0385qx3tk2.html
课时7：渠道包的热更新
https://v.qq.com/x/page/z0393rt2cmq.html
课时8：加固包的热更新
https://v.qq.com/x/page/p0398b38vwl.html
相信有不少小伙伴在打包的时候发现build\bakApk\app-0910-13-51-24\，缺失了app-release-mapping.txt
而确实的这个文件其实是因为混淆没有打开，
mapping文件
mapping.txt
列出了原始的类，方法和字段名与混淆后代码间的映射。这个文件很重要，当你从release版本中收到一个bug报告时，可以用它来翻译被混淆的代码。
mapping目录在
\app\build\outputs\mapping\release 把它复制到
build\bakApk\app-0910-13-51-24\就好
如果这时候还是找不到这个文件 就需要在混淆文件中添加
混淆前后的映射
-printmapping mapping.txt
然后到最后我发现其实没有这个文件的时候 我的更新和热更都是可以用的，抓到的crash日志也是可以正常查看，但是为避免意外出现，建议还是把app-release-mapping.txt文件和符号表插件配置好。
另外一定要注意enableProxyApplication 这个属性
enableProxyApplication = false 的情况
这是Tinker推荐的接入方式，一定程度上会增加接入成本，但具有更好的兼容性。
你需要自己去写ApplicationLike extends DefaultApplicationLike
还要去写SampleApplication
public SampleApplication() {
super(ShareConstants.TINKER_ENABLE_ALL, "xxx.xxx.SampleApplicationLike",
"com.tencent.tinker.loader.TinkerLoader", false);
}
参数一：表示Tinker支持的类型
参数二：Application代理类 这里填写你自定义的ApplicationLike 包名+类名
参数三：Tinker的加载器，使用默认即可
参数四：加载dex或者lib是否验证md5，默认为false
enableProxyApplication = true 的情况
即正常使用
在编译的时候如果找不到gradle 请看as最右边
如果在编译的时候出现app-release-unsigned.apk情况，这是因为你的apk在打包的时候没有找到keystore
在build.gradle中添加
// 签名配置
signingConfigs {
release {
try {
//这个keystore文件夹和app下的build文件夹同级
storeFile file("./keystore/xxx.keystore")
storePassword ""//密码
keyAlias ""//keystore的别名
keyPassword ""//密码
} catch (ex) {
throw new InvalidUserDataException(ex.toString())
}
}
debug {
storeFile file("./keystore/debug.keystore")
}
}
// 构建类型
buildTypes {
release {
minifyEnabled false
signingConfig signingConfigs.release
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
debug {
debuggable true
minifyEnabled false
signingConfig signingConfigs.debug
}
基准包和补丁包注意事项：
基准包在没有升级到下个版本之前，务必不要删除，因为补丁包要和基准包对应，不然无法匹配，导致上传更新失败
生成基准包的时候 baseApkDir 是以一个日期格式生成文件夹，
在打补丁包的时候这个字符串一定要换成基准包的文件夹名。
tinkerId 基本包和补丁包一定要确保唯一性，但是也可以这样写
经过的测试发现只要补丁包的baseApkDir能和基准包的对应上，以上也是可以接到补丁的，同一个基准包同时只能下发一个补丁
后下发的补丁会冲突掉之前的补丁包
现在我要去看符号表的插入和so文件的更新了