1. Crash错误分析

1.1. 功能介绍


Crash错误分析实现了多平台的Crash数据完全采集,帮助开发者动态监测App在各移动设备的异常情况,且支持按错误类型和应用版本筛选/分析错误, 如果APP若发生重大的质量问题,系统将自动告警给相关人员,让相关人员做出相应的应急处理。

关于Crash错误分析的管理台操作说明,请点击

快速入口:

1.2. Android错误统计


本指南用于MTA Android Crash V2版本的接入,用于引导crash模块的配置升级、API调用。

V2版本的Crash模块已全新重构升级,支持Java和所有架构的Native so丰富的异常数据采集,支持完整的堆栈还原,支持实时堆栈展示报表,支持实时监控告警等一系列特性。

1.2.1. Native Crash支持及.so库文件

MTA支持Android的Java和Native异常捕获,其中Java Crash模块默认集成在MTA主体jar包中,Native Crash(即c/c++或so的异常捕获)需要额外添加so文件,并调用API启用,若您的工程涉及到Native编码,建议打开上Native Crash模块,否则,不需要额外添加这部分的文件。

MTA Native Crash支持当前Android系统所支持的所有架构:

armeabi
armeabi-v7a
arm64–v8a
x86
x86_64
mips 
mips64

在集成过程中,一定要注意不同架构.so库文件的存放,否则可能会引起问题,总的原则是:只保留工程所支持的架构.so,不支持的.so千万不要额外导入。下面举例说明。

集成前:假设libMyCustom.so为实际工程的.so文件,所支持架构列表只有armeabi、armeabi-v7a、arm64-v8a三种。

集成后:根据只保留工程所支持.so架构的原则,那么只需要把Mta Native Crash对应的架构下的.so文件复制到工程对应的目录中即可,即MTA armeabi的libMtaNativeCrash_v2.so复制到工程对应的armeabi目录下,注意一定要匹配,保持支持的架构目录的.so文件一致,而不支持的架构不需要添加,一个集成带native crash模块的MTA后的工程示例见下图。

1.2.2. API接口

为了方便使用,最新的Crash模块统一封装成类StatCrashReporter对外提供服务,同时兼容旧的接口。为了方便管理,建议以新的API调用替换旧的接口,具体的API升级见下面。

Java Crash异常捕获

void setJavaCrashHandlerStatus (boolean enable)

(1)说明

开启或禁用java异常捕获,初始化不会带来任何的流量和性能消耗。生效后,会注册DefaultUncaughtExceptionHandler,crash时捕获相关信息,存储在本地并上报。可通过添加StatCrashCallback监听Crash发生。

(2)参数 enable 是否开启java异常捕获,默认开启;

true:开启;

false:禁用

对应的get接口:getJavaCrashHandlerStatus()

调用位置:App初始化时调用,比如Application.onCreate或MainActivity.onCreate

(3)示例

StatCrashReporter.getStatCrashReporter(getApplicationContext()).setJavaCrashHandlerStatus(true);

Native Crash异常捕获

void setJniNativeCrashStatus (boolean enable)

(1)说明

开启或禁用Native异步捕获,初始化不会带来任何的流量和性能消耗。生效后,会注册signal到native层,crash时捕获相关信息,存储在本地并上报。可通过添加StatCrashCallback监听Crash发生。

(2)参数

enable 是否开启Native异常捕获,默认为false;

true:开启;

false:禁用

对应的get接口:getJniNativeCrashStatus ()

调用位置:App初始化时调用,比如Application.onCreate或MainActivity.onCreate

(3)示例

StatCrashReporter.getStatCrashReporter(getApplicationContext()).setJniNativeCrashStatus(true);

监听Crash发生

void addCrashCallback(StatCrashCallback cb)

(1)说明

添加StatCrashCallback监听Java或Native的Crash发生。

(2)参数

StatCrashCallback crash发生时的StatCrashCallback回调

public interface StatCrashCallback {
// thread:crash的线程信息
// throwable:crash的堆栈信息
public abstract void onJavaCrash(Thread thread, Throwable throwable);
// nativeCrashStacks:native crash的tombstone格式文件
public abstract void onJniNativeCrash(String nativeCrashStacks);
}

对应的remove接口:removeCrashCallback(StatCrashCallback cb)

调用位置:App初始化时调用,比如Application.onCreate或MainActivity.onCreate

(3)示例

StatCrashReporter.getStatCrashReporter(getApplicationContext()).addCrashCallback(
new StatCrashCallback() {
@Override
public void onJniNativeCrash(String nativeCrashStacks) { // native crash happened
// do something
}
@Override
public void onJavaCrash(Thread thread, Throwable ex) {// java crash happened
// do something
}
});

上报策略

Crash产生时,默认下次App启动时初始化MTA后的3秒开始上报,可通过setReportDelaySecOnStart(int reportDelaySecOnStart) ,reportDelaySecOnStart的单位为秒,范围[0, 10*60]。

也可以通过设置setEnableInstantReporting设置实时上报,即crash时有网络的条件下尽量立即上报,若上报失败,则下次启动时上报。

为方便开发者调试,在Debug模式,即StatConfig.setDebugEnable(true),采用实时上报策略。

多进程环境

在多进程环境中,若需要在多个进程捕获异常,需要在每个进程都初始化MTA或Native Crash接口,建议在Application.onCreate进行。

一个完整的示例

示例包括以上主要API调用,请根据需要自行决定调用哪些API。

// 设置appkey,应用的唯一标识,在MTA官网申请得到,也可通过Manifest配置
// 记得把以下appkey替换成自己的
StatConfig.setAppKey(app, "A91LM44JGFLV");
// 设置投放渠道,即应用市场,也可通过Manifest配置
StatConfig.setInstallChannel(app, "应用宝");
StatService.setContext(app);
// 这个是开启Mta的统计功能
StatService.registerActivityLifecycleCallbacks(app);

StatCrashReporter crashReporter = StatCrashReporter.getStatCrashReporter(app);
// 开启异常时的实时上报
crashReporter.setEnableInstantReporting(true);
// 开启java异常捕获
crashReporter.setJavaCrashHandlerStatus(true);
// 开启Native c/c++,即so的异常捕获
// 请根据需要添加,记得so文件
crashReporter.setJniNativeCrashStatus(true);

// crash时的回调,业务可根据需要自选决定是否添加
crashReporter.addCrashCallback(new StatCrashCallback() {

@Override
public void onJniNativeCrash(String tombstoneString) {
// native dump内容,包含异常信号、进程、线程、寄存器、堆栈等信息
// 具体请参考:Android原生的tombstone文件格式
log("MTA StatCrashCallback onJniNativeCrash:\n" + tombstoneString);
}

@Override
public void onJavaCrash(Thread thread, Throwable ex) {
//thread:crash线程信息
// ex:crash堆栈
log("MTA StatCrashCallback onJavaCrash:\n", ex);
}
});

1.2.3. Android Crash V2版本符号表上传说明

用于MTA Android Crash V2版本符号表上传说明,主要分为Java符号表和Native(C/C++)符号表两部分,用于系统还原混淆后的堆栈信息。

Java符号表

(1)Eclipse

通常符号表名为“mapping.txt”,位于 proguard 目录下,如果是使用ant脚本编译,则在脚本指定的目录下。

(2)Android Studio

在build.gradle文件中开启混淆代码,minifyEnabled 设置为 true 时生成 mapping 文件,路径一般为工程目录下的:build/outputs/mapping/release/mapping.txt

(3)Java符号表上传

在前台打开符号表上传页面,填写App版本号,选择“Java”文件类型,点击”选择文件“,选取mapping.txt文件后点击上传即可。

Native符号表

Native符号表,是为了找回so文件Crash堆栈还原使用的,由于编译器的问题,发布的so文件是已去符号化的,而编译过程中产生的中间文件才是带符号表信息的。因此,建议大家每次构建版本时,备份好debug so文件。

(1)Eclipse

使用eclipse构建的so文件,debug so位于项目的“/obj/local/xxxeabi/“目录下,其中xxxeabi为具体的架构信息,见下图

我们需要把local目录打包,建议打包前把架构下的Objs目录清除掉。

(2)Android Studio

使用Android Studio编译的so文件,分为Debug和Release两个不同的版本,对应的目录通常为:

//build/intermediates/cmake/debug/obj/xxxeabi/和//build/intermediates/cmake/release/obj/xxxeabi/,我们需要将obj 目录整体打包成zip格式。

不同的Android studio版本可能存在路径差异,可以使用以下方法来判断,以Linux/Mac OS系统为例:

a) 打开终端命令行,cd到当前工程目录,输入:find ./ -name your-lib-name.so,找到so编译生成目录

b)输入:file your-full-so-path,如果输出“not stripped”表示是带符号信息的so文件,输出“stripped”表示是删除符号表信息的so文件

(3)native符号表上传

在前台打开符号表上传页面,填写App版本号,选择“native”文件类型,点击”选择文件“,选取刚刚打包的zip文件后点击上传即可。

1.3. iOS错误统计


错误统计既可统计APP的crash,也可统计APP中的逻辑错误。crash由MTA自动捕获并且上报(需引用libcrashreporter.a),无需调用额外接口。逻辑错误需要开发者手动调用相关接口上报。

1.3.1. 逻辑错误统计接口

/**
统计程序逻辑错误
逻辑错误只有描述,没有堆栈信息

@param error 错误描述
*/
+ (void)trackError:(NSString *)error;

/**
统计程序逻辑错误
并且指定上报方式
逻辑错误只有描述,没有堆栈信息

@param error 错误描述
@param appkey 若此参数不为nil,则上报到此appkey。否则,上报到startWithAppkey中传入的appkey
@param isRealTime 是否实时上报,若传入YES,则忽略全局上报策略实时上报。否则按照全局策略上报。
*/
+ (void)trackError:(NSString *)error appkey:(NSString *)appkey isRealTime:(BOOL)isRealTime;

/**
统计异常
异常信息包括了异常的原因和堆栈

@param exception 异常信息
*/
+ (void)trackException:(NSException *)exception;

/**
统计异常
并且指定上报方式
异常信息包括了异常的原因和堆栈

@param exception 异常信息
@param appkey 若此参数不为nil,则上报到此appkey。否则,上报到startWithAppkey中传入的appkey
@param isRealTime 是否实时上报,若传入YES,则忽略全局上报策略实时上报。否则按照全局策略上报。
*/
+ (void)trackException:(NSException *)exception appkey:(NSString *)appkey isRealTime:(BOOL)isRealTime;

1.3.2. 崩溃上下文信息统计接口

在崩溃发生时候,MTA 会自动捕获崩溃的堆栈以及基本的上下文信息,并且在下次启动时候上报。除此之外,开发者还可以调用特定的 API 来储存额外的上下文信息,这些信息会在崩溃发生时,跟随崩溃报告一起上报,以便Debug。

/**
设置自定义的tag
崩溃发生时,会将已经设置的tag上报,以便定位问题

@param tagKey tag的Key,若key已经设置,则新的value会覆盖旧的value
@param tagValue tag的value
*/
+ (void)setCustomTag:(NSString *)tagKey value:(NSString *)tagValue;


/**
输出诊断信息
崩溃发生时,会将最后输出的50条诊断信息上报,以便定位问题

@param log 诊断信息
*/
+ (void)traceLog:(NSString *)log;

1.3.3. 符号表上传指南

异常上报使用说明

新版MTA增强了异常上报功能。在APP发生异常时,MTA会采集最近的NSLog、页面的信息以及崩溃堆栈进行上报。除此之外,用户还可以根据需要,自行上报业务相关的tag和诊断信息,以便debug。上报诊断信息的接口在MTACrashReporter.h头文件中。使用方法请看头文件注释。

除此之外,为了更准确的还原崩溃堆栈,需要用户提供app对应的dSYM文件。制作dSYM的步骤如下。

  1. 在Xcode工程配置中找到'Debug Information Format'项,将该项的值改为'DWARF with dSYM File'。如图。

  1. 按照正常步骤打包。打包完成后,在弹出的页面点击右键,在弹出的菜单中选择'Show in Finder'。如图。

  1. 在弹出的Finder页面中,可以看到上一步生成的xcarchive文件,右键点击文件,选择'Show Package Contents'。如图。

  1. 找到dSYMs目录内的dSYM文件,右键点击,选择'Show Package Contents'。如图。

  1. 找到包内Contents/Resources/DWARF目录下的文件,上传这个文件即可。

找到dSYM文件后,使用上传工具或者在网页控制台将dSYM文件上传即可。

常见问题

(1)什么是错误映射表?

错误映射表是内存地址与函数名、文件名、行号的映射表。符号表元素如下所示:

<起始地址> <结束地址> <函数> [<文件名:行号>]

(2)在哪里配置错误映射表?

如图所示,可以在“开发组件-->crash分析-->crash明细-->符号表管理”配置错误映射表

(3)为什么要配置错误映射表?

为了能快速并准确地定位用户APP发生Crash的代码位置,使用错误映射表对APP发生Crash的程序堆栈进行解析和还原。

举例:

iOS上报的错误如下图左边显示,是一堆内存地址和偏移量。开发者无法从中获取有效的信息。而使用错误映射表进行还原之后,则得到右图的效果,开发可以轻松看到上报的堆栈信息。

results matching ""

    No results matching ""