bugly框架记录

 

最开始的时候是为了使用腾讯的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调试模式开关，调试模式的行为特性如下：

• 输出详细的Bugly SDK的Log；
• 每一条Crash都会被立即上报；
• 自定义日志将会在Logcat中输出。

建议在测试阶段建议设置成true，发布时设置为false。

增加上报进程控制

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文件的更新了