标签:
为什么需要反馈Crash报告?
做Android应用程序,要尽量避免程序Crash的发生。虽然说零Crash是程序员追逐的最终目标,但是现实的情况是,程序员只能尽量的减少Crash的发生,而几乎不可能完全杜绝Crash。也许,你认为你的应用的健壮性已经近乎完美,轻松的经受住了测试部门魔鬼般的考验,但是当你的应用发布到市场,面对百万甚至千万级别的用户的时候,可能就没有那么幸运了。
基于以上原因,一般的应用程序,都要有一个Crash反馈的机制。程序员可以根据反馈的结果,对当前的版本的代码进行改进,使发布的下一个版本更加稳定。
如何反馈?
先来看如何捕获Crash的发生。
Java中有一个接口,UncaughtExceptionHandler,先看描述。
|
Thread.UncaughtExceptionHandler |
再来看Thread类中的一个方法。
|
setDefaultUncaughtExceptionHandler |
看了这些API,就知道我们需要实现这样一个接口,然后在程序的主线程中设置处理程序。
看下面的接口实现。
在主Activity的onCreate(Bundle savedInstanceState)方法中增加如下代码。
如何发送到服务器?
这个不同的项目组会有不同的方式,具体不在这里讨论了。需要提醒的是,除了把异常的具体信息发送给服务器外,至少还需要发送版本信息,这样程序员才可以判断服务器上的异常信息是哪个版本出现的。除了版本信息,可能还需要手机的SDK版本,屏幕分辨率,手机型号等等信息,有了这些信息,可以更全面的了解异常信息。
更多说明。
只需要在主Activity中设置一次异常处理类即可,不需要在所有的Acitivity都进行设置。
个人感觉Crash发生后,恢复现场继续运行的意义不大。Crash以后,程序的运行情况已经是不可预知的了,用一个错误,去弥补另外一个错误,本身就会导致更多的错误。建议还是尽量避免Crash的发生更合理。
---------------------------------------------------------------------------
GL(arui319)
http://blog.csdn.net/arui319
<本文可以转载,但是请保留以上作者信息。谢谢。>
---------------------------------------------------------------------------
标签:
原文地址:http://www.cnblogs.com/cmblogs/p/4275419.html