Android crash 收集

Android Crash

在开发中，会遇到crash问题，通常来讲，crash发生在java层，可是，有时候会发生在其余层面上。大体，Android Crash 大体有三类：

1. Java uncatch exception
2. ANR crash
3. Native crash

Java全局异常处理

经过Thread.setDefaultUncaughtExceptionHandler咱们能够指定一个默认的全局异常处理器，该处理器由JVM发现UNCATCH EXCEPTION 的时候调用

public class Main {
	public static void main(String args[]){
		Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {
			@Override
			public void uncaughtException(Thread t, Throwable e) {
				System.out.println("FFF");
			}
		});
		new Thread(new Runnable() {
			@Override
			public void run() {
				throw new RuntimeException("CC");
			}
		}).start();
	}
}

堆栈图：

堆栈的ROOT方法：

/**
* Dispatch an uncaught exception to the handler. This method is
* intended to be called only by the JVM.
*/
private void dispatchUncaughtException(Throwable e) {
	getUncaughtExceptionHandler().uncaughtException(this, e);
}

ANR crash

ANR 产生的缘由主要是UI线程被卡住太长时间了，其大部分是由于网络访问引发的，幸亏4.0之后，就不支持在UI线程访问网络了。

ANR 一旦发生，一般会在Logcat中刷出问题，可是，若是该APP已经发布了，就没法经过logcat查看到崩溃日志了。

幸亏，咱们能够经过**/data/anr/traces.txt** 来读取最后一次ANR日志。 具体能够参考ANR文章。

Native crash

由于性能的问题，Android中的游戏开发等，一般使用native（C语言）开发，由于脱离了JVM环境，因此一旦发生crash，错误就比较难以定位，咱们须要借助操做系统的力量进行crash日志收集。

DEBUG

若是正在开发APP中，及时发现问题，那么能够经过 ndk-stack 来查看崩溃位置ndk-stack使用

RELEASE

麻烦的问题就是在于，若是APP发布了，就不能经过logcat来获取崩溃日志了。此时，只能借助于Android依赖的系统来完成日志捕获的功能。大部分Android系统是依赖Linux系统，因此，只用经过Linux对原生程序崩溃的处理方法，就能够完成日志的捕获。

在Linux 中，一般采用信号来捕获各类异常状态的，因此只须要注册一个咱们的信号量监听器就能够完成对崩溃事件的监听。而后，利用参数info能够获取崩溃stack位置，最后经过回溯stack，就能够打印出崩溃点的C栈了。

具体能够参考善用backtrace解决大问题，也能够直接采用 **google breakpad **开源项目解决这个问题。

总结

通过上述分析，能够发现Android平台的崩溃点仍是比较多的，对于ANR和Native crash 的日志收集仍是比较困难的。 经过TX Bugly 能够直接Hold住这些问题，看介绍是这样子的。对于TX Bugly的原理，我的认为应该和本文描述相似，但愿有大牛能解密。

对于应用的crash状况，相信各个平台都有相对应的一套机制来帮助程序员定位异常点。