做为程序员，不愿意看到的就是自己写的程序崩溃，特别是遇到没有错误信息的崩溃的时候，往往程序员自己也就随之一起崩溃了。如何捕获Android程序产生异常时的崩溃信息，粤嵌Android培训中心为你解析一下，希望能够带给你一些启发，同时解决一些生产上的难题。

　　在应用从开发慢慢过渡到线上部署的时候，开发者就逐渐切换到依靠程序日志/运行状态来进行问题的排查和解决。通常一些第三方厂商会提供这些服务，譬如腾讯的bugly，fabric，Umeng等。前两者的异常收集和处理较好，然而有一个通用的问题就是需要将symbol文件上传到厂商服务器，显然对于注重应用安全和IP保护的开发者，这个行为是值得着重权衡的。而Umeng则注重于运营数据，对于异常捕获没有特别大的优势。所以本文的关注点就是如何在Android项目内部实现自己异常捕获和分析模块。

　　如何捕获Java异常？这个问题乍一听感觉没有任何难度，这不是用以下的处理Crash大法就解决了吗?且不说这样做的对错，只是并不能很好的解决我们的问题，问题就在于我们对于会发生异常的地方没有办法完全预知，对于Checked Exception编译器会提示我们处理，然而对于Runtime Exception，总是难以预防。NPE常年占据Java Eeception的Top 1不是没有道理。所以我们的期望是什么，就算我们没有指定Catch Exception，在程序发生异常的时候，也能通知到我们。

　　如何捕获Native异常？与Java层的异常不同，Native层的异常捕获要稍微复杂一些。难点主要在于当Native层发生异常时，JVM在收到异常信号后会直接Shutdown，所以我们的Thread.UncaughtExceptionHandler不会被执行。所以我们必须捕获Linux的异常信号，并执行我们自己的信号处理函数。在此基础上，我们还必须自己来实现Crash Dump生成和解析。

　　如何提示用户发送错误信息？我们在前面已经成功的捕获了Java异常和Native异常，那么接下来要做的就是顺理成章的处理，只要提示用户将我们需要的Java栈和Native Dmp文件发送给我们，我们就可以进行问题排查和修复了。由于篇幅原因，这里就给出一个思路，我们可以在Java Excpetion和 Native DumpCallback的时候，新起一个进程，在这个进程里面进行日志上传，甚至可以弹出一个Activity告知用户，提升用户体验。

　　当应用上线之后，脱离了Logcat提供的便利，开发者应该如何获取错误信息进行异常修复，本文提供了一些随手可行的思路，包含了Java层和Native层不同的处理办法，通过实例代码步步深入，希望带给大家一起启发，同时解决生产上的一些实际问题。以上是粤嵌Android培训中心解析的Android应用的异常捕获。