1. 错误分析

1.1. 功能介绍

（1）通过错误统计，运营人员可以知道APP的质量情况。

（2）通过错误列表，开发者可以查看发生错误时的堆栈信息，为定位问题修复BUG提供有力的保证。

（3）通过错误告警，APP若发生重大的质量问题，将告警给相关人员，让相关人员做出相应的应急处理。

1.2. Android错误统计

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

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

1.2.1. 配置升级

库文件

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

Java Crash：使用新的mta 3.x.x.jar替换老版。

Native Crash：libMtaNativeCrash_v2.so，删除老的ibMtaNativeCrash.so，需要注意不同ABI的文件存放，具体见下。

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后的工程示例见下图。

工程配置

主要的配置参考MTA的接入配置功能，下面列举AndroidMenifest.xml文件的配置部分。

<application
……工程application指标的的其它配置

<!-- MTA配置项 < -->
<!-- 请将value改为MTA分配的appkey，若已通过API调用可跳过本配置 < -->
<meta-data
android:name="TA_APPKEY"
android:value="A91LM44JGFLV" />

<!-- 请将value改为APP的发布渠道（市场），若已通过API调用可跳过本配置 < -->
<meta-data
android:name="InstallChannel"
android:value="应用宝" />

<!-- MID 3.x版的配置部分，需要将"您的APP包名"替换成工程实际的包名 < -->
<provider
android:name="com.tencent.mid.api.MidProvider"
android:authorities="您的APP包名.TENCENT.MID.V3"
android:exported="true" >
</provider>
</application>

<!-- MTA权限配置项 -->
<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" />

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自动捕获并且上报，无需调用额外接口。逻辑错误需要开发者手动调用相关接口上报。

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. 符号表上传指南

iOS Crash 错误分析上传工具

iOS Crash 符号表上传工具主要用来上传App的符号表文件，即dSYM文件，以便网页端显示App crash的堆栈信息还原出符号，让开发者更直接的看到程序Crash发生的位置和原因

您可以点击 下载 或是在错误管理窗口下载

用法如下图:

关于工具的参数说明：

QQ账号：MTA前端网页中App的管理员

App ID：MTA前端【应用管理】选项卡中APP ID

App Key：MTA前端【应用管理】选项卡中App KEY

dSYM：编译App时生成的符号表文件

注：一般在Xcode->Target->BuildSetting->Build Options选项卡中的DebugInformation可以看到编译app生成的符号表文件，一般符号表文件的位置与生成的App在同一个位置

常见问题

（1）什么是错误映射表？

错误映射表是内存地址与函数名、文件名、行号的映射表。符号表元素如下所示： <起始地址> <结束地址> <函数> [<文件名:行号>]

（2）在哪里配置错误映射表？

如图所示,可以在“质量监控-->错误异常监控-->错误列表-->错误映射表管理”配置错误映射表

（3）为什么要配置错误映射表？

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

举例：

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