一个很好用的BUG收集工具------Bugly

在项目上线以后,用户开始使用时候,总是会遇到各种各样的bug,特别是crash,所以我们就需要收集这些bug,然后去逐步的修改,盘查问题所在,保障在以后的版本里不会出现相同的问题。大部分人的做法是抓取到APP的Crash信息,然后保存到本地,在一个特定的条件下,将统计到的信息发送给服务器。这也是解决办法的一种方式,但是这个分析的过程就需要我们自己做了,这个过程里就会发现会产出很多重复的错误代码,然后还要一遍遍去看,这样会浪费很多时间。所以这就需要借助一下第三方的工具,当然市面上有很多这种类型的工具,但是经过对比之后我觉得下面我要给大家讲的第三方的bug收集工具---Bugly 是里面最好用的(个人意见),它里面还内嵌了微信的热修复框架tinker,可以在你发现致命bug的时候能够无需重新发版让用户无感知就能把问题修复。(防止了被祭天的危险)。

下面我就给大家介绍一下bugly的使用,后面会介绍集成tinker。

第一步:添加依赖

在Module的build.gradle文件中添加依赖和属性配置:

dependencies {
    compile 'com.tencent.bugly:crashreport:latest.release' //其中latest.release指代最新Bugly SDK版本号,也可以指定明确的版本号,例如2.2.0
}

同时集成SDK和NDK

在Module的build.gradle文件中添加依赖和属性配置:

android {
    defaultConfig {
        ndk {
            // 设置支持的SO库架构
            abiFilters 'armeabi' //, 'x86', 'armeabi-v7a', 'x86_64', 'arm64-v8a'
        }
    }
}

dependencies {
    compile 'com.tencent.bugly:crashreport:latest.release' //其中latest.release指代最新Bugly SDK版本号,也可以指定明确的版本号,例如2.1.9
    compile 'com.tencent.bugly:nativecrashreport:latest.release' //其中latest.release指代最新Bugly NDK版本号,也可以指定明确的版本号,例如3.0
}

同时集成Bugly SDK和NDK的配置如下图所示,后续更新Bugly SDK和NDK时,只需变更配置脚本中的版本号即可。

一个很好用的BUG收集工具------Bugly_第1张图片


注意:自动集成时会自动包含Bugly SO库,建议在Module的build.gradle文件中使用NDK的“abiFilter”配置,设置支持的SO库架构。

如果在添加“abiFilter”之后Android Studio出现以下提示:

NDK integration is deprecated in the current plugin. Consider trying the new experimental plugin.

则在项目根目录的gradle.properties文件中添加:

android.useDeprecatedNdk=true

参数配置

  • 在AndroidManifest.xml中添加权限:
<uses-permission android:name="android.permission.READ_PHONE_STATE" />
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
<uses-permission android:name="android.permission.READ_LOGS" />
  • 请避免混淆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。

一个很好用的BUG收集工具------Bugly_第2张图片

此外,Bugly2.0及以上版本还支持通过“AndroidManifest.xml”来配置APP信息。如果同时又通过代码中配置了APP信息,则最终以代码配置的信息为准。

在“AndroidManifest.xml”的“Application”中增加“meta-data”配置项:

<application
    -- 配置APP ID -->
    <meta-data
            android:name="BUGLY_APPID"
            android:value="" />
    
    <meta-data
            android:name="BUGLY_APP_VERSION"
            android:value="" />
    
    <meta-data
            android:name="BUGLY_APP_CHANNEL"
            android:value="" />
    
    <meta-data
            android:name="BUGLY_ENABLE_DEBUG"
            android:value="" />
application>

不同于“android:versionName”,“BUGLY_APP_VERSION”配置的是Bugly平台的APP版本号。

通过“AndroidManifest.xml”配置后的初始化方法如下:

CrashReport.initCrashReport(getApplicationContext());

Bugly默认从“AndroidManifest.xml”文件中读取“VersionName”作为版本号,自定义设置请使用参考“高级设置”。

MultiDex注意事项

如果使用了MultiDex,建议通过Gradle的“multiDexKeepFile”配置等方式把Bugly的类放到主Dex,另外建议在Application类的"attachBaseContext"方法中主动加载非主dex:

public class MyApplication extends SomeOtherApplication {
  @Override
  protected void attachBaseContext(Context base) {
     super.attachBaseContext(context);
     Multidex.install(this);
  }
}

增加上报进程控制

如果App使用了多进程且各个进程都会初始化Bugly(例如在Application类onCreate()中初始化Bugly),那么每个进程下的Bugly都会进行数据上报,造成不必要的资源浪费。

因此,为了节省流量、内存等资源,建议初始化的时候对上报进程进行控制,只在主进程下上报数据:判断是否是主进程(通过进程名是否为包名来判断),并在初始化Bugly时增加一个上报进程的策略配置。

Context context = getApplicationContext();
// 获取当前包名
String packageName = context.getPackageName();
// 获取当前进程名
String processName = getProcessName(android.os.Process.myPid());
// 设置是否为上报进程
UserStrategy strategy = new UserStrategy(context);
strategy.setUploadProcess(processName == null || processName.equals(packageName));
// 初始化Bugly
CrashReport.initCrashReport(context, "注册时申请的APPID", isDebug, strategy);
// 如果通过“AndroidManifest.xml”来配置APP信息,初始化方法如下
// CrashReport.initCrashReport(context, strategy);

其中获取进程名的方法“getProcessName”有多种实现方法,推荐方法如下:

/**
 * 获取进程号对应的进程名
 * 
 * @param pid 进程号
 * @return 进程名
 */
private static String getProcessName(int pid) {
    BufferedReader reader = null;
    try {
        reader = new BufferedReader(new FileReader("/proc/" + pid + "/cmdline"));
        String processName = reader.readLine();
        if (!TextUtils.isEmpty(processName)) {
            processName = processName.trim();
        }
        return processName;
    } catch (Throwable throwable) {
        throwable.printStackTrace();
    } finally {
        try {
            if (reader != null) {
                reader.close();
            }
        } catch (IOException exception) {
            exception.printStackTrace();
        }
    }
    return null;
}

测试

现在您可以制造一个Crash(建议通过“按键”来触发),来体验Bugly的能力了。在初始化Bugly的之后,调用Bugly测Java Crash接口。

CrashReport.testJavaCrash();

执行到这段代码时会发生一个Crash,Logcat的TAG=CrashReportInfo中输出为:

一个很好用的BUG收集工具------Bugly_第3张图片

现在您已经可以在“崩溃”页面看到刚才触发的Crash issue了(延迟一般在10s以内)。

如果项目包含了Native工程或者使用了代码混淆,建议配置符号表文件,具体请参考“符号表配置”

经过上面的步骤的话 我们就完成了bugly收集bugly的功能,下面第二篇的话 我会给大家介绍一下tinker热修复的集成过程


你可能感兴趣的:(安卓开发,开发工具)