做为程序员，最不愿意看到的就是自己写的程序崩溃，特别是遇到没有错误信息的崩溃的时候，往往程序员自己也就随之一起崩溃了。如何捕获Android程序产生异常时的崩溃信息，本文提供了随手可行的方法，希望能够带来一些启发，同时解决一些生产上的难题。
背景
在应用从开发慢慢过渡到线上部署的时候，开发者就逐渐切换到依靠程序日志/运行状态来进行问题的排查和解决。通常一些第三方厂商会提供这些服务，譬如腾讯的bugly，fabric（以前叫crashlytics），Umeng等。 前两者的异常收集和处理较好，然而有一个通用的问题就是需要将symbol文件上传到厂商服务器，显然对于注重应用安全和IP保护的开发者，这个行为是值得着重权衡的。而Umeng则注重于运营数据，对于异常捕获没有特别大的优势。所以本文的关注点就是如何在Android项目内部实现自己异常捕获和分析模块。
主要会包括以下知识点(划重点)
1. 如何捕获Java异常
2. 如何捕获Native异常及分析
3. 如何提示用户发送错误信息
1. 如何捕获Java 异常
这个问题乍一听感觉没有任何难度，这不是用以下的终极处理Crash大法就解决了吗?
且不说这样做的对错，只是并不能很好的解决我们的问题，问题就在于我们对于会发生异常的地方没有办法完全预知，对于CheckedException 编译器会提示我们处理，然而对于RuntimeException，总是难以预防。NPE(Null Pointer Exception)常年占据Java Eeception的Top 1 不是没有道理。
所以我们的期望是什么，就算我们没有指定Catch Exception，在程序发生异常的时候，也能通知到我们。幸运的是，正好就有这样的方法。
看一下这个方法的说明，一下就明白了
至此，一切都清楚了，我们要做的就是设置一个自定义的UncaughtExceptionHandler，并且设置为Thread的Default值，这样在异常发生时，就可以进入到我们的处理流程当中，简要代码如下:
2. 如何捕获Native异常
与Java层的异常不同，Native层的异常捕获要稍微复杂一些。难点主要在于当Native 层发生异常时，JVM在收到异常信号后会直接Shutdown，所以我们的Thread.UncaughtExceptionHandler 不会被执行。所以我们必须捕获Linux的异常信号，并执行我们自己的信号处理函数。例如如下展示：
在此基础上，我们还必须自己来实现Crash Dump生成和解析，着实不太友好。所以在这里我们引用了一个三方库，来帮我们处理。
Google-Breakpad项目地址
下面我们就来看一下如何集成Breakpad来完成我们需要的异常捕获。
从上面的Breakpad的结构图可以看出，我们需要的是两块东西，一是Client模块，这将被集成到App中，用作Crash的信号捕捉和dump文件生成；另外一个就是Process模块，当收集到用户dump文件时，结合symbol进行crash栈分析。
2.1 Client模块集成
通过depot_tools 下载好整个Breakpad源码之后，我们就可以进行client module的编译。通常来说有两种编译的方式，一是集成到项目中，利用NDK-Build 来进行整个源码的编译和集成；第二个就是使用NDK toolchain来进行单独编译，然后将编译出来的静态链接库导入到项目中。两者没有很大的区别，主要区别在于前者Breakpad的src代码会被集成到项目里，而后者则是单独管理。之前的项目采用的是第二种方法，导入静态链接库。这样的好处就是项目中jni文件夹里没有过多跟项目业务无关的代码，然而有一个问题没法避免，需要用到的头文件也需要加到项目中去，这样也需要一个手动的维护。再加上Android Studio 2.2 以后对NDK的支持，所以本文就采用集成源码到项目中来进行一个展示。
•首先是创建jni文件夹：右键项目 -> new -> folder -> jni folder
•接着是拷贝breakpad/src 到jni folder下，并删除一些Client不需要的folder，包括build，processor，testing，tools等，清理过后的目录结构应该跟以下类似：
•接着是配置Gradle：
这里的Android.mk 如果项目之前没有的话，那么可以直接拷贝Breakpad 下src\android\sample_app\jni下面的3个文件到项目中的jni目录下，然后根据之前拷贝的Breakpad目录结构做如下改动：
可以看到，在test_breakpad.cpp中，我们定义了一个jni 方法setHandler()，主要干了几件事，设置Dmp文件的生成位置，注册自己的DumpCallback，并且紧跟着模拟了一个Crash。
•最后我们选择MainActivity 或者Application 中去加载我们的Library并调用jni方法。
别忘记加上写SDCard的权限!
至此，我们的测试App 就已经完成，运行起来之后就可以在Logcat里面看到类似如下的输出：
Dump path: %s]
/storage/emulated/0/Android/data/com.example.capturecrash/
files/c1d1d3cb-7030-46a2-009b4598-26d2de2d.dmp
这里的dmp文件就包含了我们之后分析Crash的信息了。
2.2 Dmp文件分析
从Dmp文件中提取有效信息，我们就需要重新回到Breakpad目录，进行Processor的编译。
请确保Linux或者Mac 的依赖包都已安装。成功编译之后，我们需要用到两个文件，一是minidump_stackwalk(src/processor/minidump_stackwalk)，另一个是dump_sys(src/tools/linux/dump_sysm/dump_syms)。我们将这两个文件拷贝到工作目录备用。
同时，我们将$AndroidProject/build/intermediates/ndkBuild/debug/obj/local/armeabi/libtest_google_breakpad.so 和上一步生成的dmp 文件也拷贝到工作目录。
接下来我们就开始进行dmp文件的分析。
•生成Symbol文件
我们首先采用dump_syms生成了libtest_google_breakpad.so的symbol，然后读取了symbol文件的第一行，需要的信息是这一串十六进制的version code。接下来我们将Symbol文件按照固定路径进行放置：
至此，Symbol文件就准备完毕。
•分析Symbol
然后我们打开result.txt，就可以发现有如下类似结果：
这样，一个清晰的Crash Stack Trace就出现了。
３．如何提示用户发送错误信息
我们在前面已经成功的捕获了Java异常和Native异常，那么接下来要做的就是顺理成章的处理，只要提示用户将我们需要的Java栈和Native Dmp文件发送给我们，我们就可以进行问题排查和修复了。
由于篇幅原因，这里就给出一个思路，我们可以在Java Excpetion 和 Native DumpCallback的时候，新起一个进程，在这个进程里面进行日志上传，甚至可以弹出一个Activity告知用户，提升用户体验。如何在Native DumpCallback新开进程并弹出Activity，这又是一个较大的话题，我们以后有机会再一起探讨。:-D
总结
当应用上线之后，脱离了Logcat提供的便利，开发者应该如何获取错误信息进行异常修复，本文提供了一些随手可行的思路，包含了Java层和Native层不同的处理办法，通过实例代码步步深入，希望带给大家一起启发，同时解决生产上的一些实际问题。
本文作者：夏欣（点融黑帮），就职于点融大前端，Android程序员一枚。