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的发生更合理。