Android应用如何反馈Crash报告

为什么需要反馈Crash报告?

 

做Android应用程序,要尽量避免程序Crash的发生。虽然说零Crash是程序员追逐的最终目标,但是现实的情况是,程序员只能尽量的减少Crash的发生,而几乎不可能完全杜绝Crash。也许,你认为你的应用的健壮性已经近乎完美,轻松的经受住了测试部门魔鬼般的考验,但是当你的应用发布到市场,面对百万甚至千万级别的用户的时候,可能就没有那么幸运了。

基于以上原因,一般的应用程序,都要有一个Crash反馈的机制。程序员可以根据反馈的结果,对当前的版本的代码进行改进,使发布的下一个版本更加稳定。

 

如何反馈?

 

先来看如何捕获Crash的发生。

 

Java中有一个接口,UncaughtExceptionHandler,先看描述。

static interface

Thread.UncaughtExceptionHandler 
          当 Thread 因未捕获的异常而突然终止时,调用处理程序的接口。

 

再来看Thread类中的一个方法。

static void

setDefaultUncaughtExceptionHandler(Thread.UncaughtExceptionHandler eh) 
          设置当线程由于未捕获到异常而突然终止,并且没有为该线程定义其他处理程序时所调用的默认处理程序。

 

看了这些API,就知道我们需要实现这样一个接口,然后在程序的主线程中设置处理程序。

 

看下面的接口实现。

 

  1. package com.arui.framework.android.exception;  
  2.   
  3.    
  4.   
  5. import java.lang.Thread.UncaughtExceptionHandler;  
  6.   
  7. import android.content.Context;  
  8.   
  9.    
  10.   
  11. /** 
  12.  
  13.  * Default exception handler for all activities. 
  14.  
  15.  *  
  16.  
  17.  * @author http://blog.csdn.net/arui319 
  18.  
  19.  * @version 2011/12/01 
  20.  
  21.  *  
  22.  
  23.  */  
  24.   
  25. public class DefaultExceptionHandler implements UncaughtExceptionHandler {  
  26.   
  27.    
  28.   
  29.     private Context act = null;  
  30.   
  31.    
  32.   
  33.     public DefaultExceptionHandler(Context act) {  
  34.   
  35.        this.act = act;  
  36.   
  37.     }  
  38.   
  39.    
  40.   
  41.     @Override  
  42.   
  43.     public void uncaughtException(Thread thread, Throwable ex) {  
  44.   
  45.    
  46.   
  47.        // 收集异常信息 并且发送到服务器  
  48.   
  49.        sendCrashReport(ex);  
  50.   
  51.    
  52.   
  53.        // 等待半秒  
  54.   
  55.        try {  
  56.   
  57.            Thread.sleep(500);  
  58.   
  59.        } catch (InterruptedException e) {  
  60.   
  61.            //  
  62.   
  63.        }  
  64.   
  65.          
  66.   
  67.        // 处理异常  
  68.   
  69.        handleException();  
  70.   
  71.    
  72.   
  73.     }  
  74.   
  75.    
  76.   
  77.     private void sendCrashReport(Throwable ex) {  
  78.   
  79.    
  80.   
  81.        StringBuffer exceptionStr = new StringBuffer();  
  82.   
  83.        exceptionStr.append(ex.getMessage());  
  84.   
  85.    
  86.   
  87.        StackTraceElement[] elements = ex.getStackTrace();  
  88.   
  89.        for (int i = 0; i < elements.length; i++) {  
  90.   
  91.            exceptionStr.append(elements[i].toString());  
  92.   
  93.        }  
  94.   
  95.    
  96.   
  97.        //TODO   
  98.   
  99.        //发送收集到的Crash信息到服务器  
  100.   
  101.     }  
  102.   
  103.    
  104.   
  105.     private void handleException() {  
  106.   
  107.        //TODO   
  108.   
  109.        //这里可以对异常进行处理。  
  110.   
  111.        //比如提示用户程序崩溃了。  
  112.   
  113.        //比如记录重要的信息,尝试恢复现场。  
  114.   
  115.        //或者干脆记录重要的信息后,直接杀死程序。  
  116.   
  117.     }  
  118.   
  119.    
  120.   
  121. }  


 

 

在主Activity的onCreate(Bundle savedInstanceState)方法中增加如下代码。

 

  1. Thread.setDefaultUncaughtExceptionHandler(new DefaultExceptionHandler(  
  2.   
  3.        this.getApplicationContext()));  


 

 

如何发送到服务器?

 

这个不同的项目组会有不同的方式,具体不在这里讨论了。需要提醒的是,除了把异常的具体信息发送给服务器外,至少还需要发送版本信息,这样程序员才可以判断服务器上的异常信息是哪个版本出现的。除了版本信息,可能还需要手机的SDK版本,屏幕分辨率,手机型号等等信息,有了这些信息,可以更全面的了解异常信息。

 

更多说明。

 

只需要在主Activity中设置一次异常处理类即可,不需要在所有的Acitivity都进行设置。

 

个人感觉Crash发生后,恢复现场继续运行的意义不大。Crash以后,程序的运行情况已经是不可预知的了,用一个错误,去弥补另外一个错误,本身就会导致更多的错误。建议还是尽量避免Crash的发生更合理。

 

---------------------------------------------------------------------------

GL(arui319)

http://blog.csdn.net/arui319

<本文可以转载,但是请保留以上作者信息。谢谢。>

---------------------------------------------------------------------------

 

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。