Android – Crash 프로세스 적용

Crash 보고서를 피드백해야 하는 이유는 무엇입니까?
 
안드로이드 프로그램을 만들려면 프로그램 Crash의 발생을 최대한 피해야 한다.제로 크래시가 프로그래머가 추구하는 최종 목표라고 하지만 현실은 프로그래머가 크래쉬의 발생을 최대한 줄일 수 있을 뿐 크래쉬를 완전히 근절할 수는 거의 없다는 것이다.아마도 당신의 응용 프로그램의 건장성은 완벽에 가깝고 테스트 부서의 마귀 같은 시련을 가볍게 이겨냈다고 생각할 것입니다. 그러나 당신의 응용 프로그램이 시장에 발표되고 백만, 심지어 천만 명의 사용자를 상대할 때 그렇게 행운은 없을 것입니다.
이러한 이유로 일반적인 응용 프로그램에는 Crash 피드백 메커니즘이 있어야 한다.프로그래머는 피드백 결과에 따라 현재 버전의 코드를 개선하여 발표된 다음 버전을 더욱 안정적으로 할 수 있다.
 
어떻게 피드백을 합니까?
 
일단 크래쉬의 발생을 어떻게 포착하는지 살펴보자.
 
자바에는 UncaughtExceptionHandler라는 인터페이스가 있습니다. 먼저 설명을 보십시오.static interface
Thread.UncaughtExceptionHandler는 Thread가 포획되지 않은 이상으로 갑자기 종료될 때 프로세서의 인터페이스를 호출합니다.
 
Thread 클래스 중 하나를 살펴보겠습니다.static void
setDefaultUncaughtExceptionHandler ( Thread.UncaughtExceptionHandler eh)는 스레드가 이상을 포착하지 않아 갑자기 종료되고 이 스레드에 다른 프로세서를 정의하지 않았을 때 호출되는 기본 프로세서를 설정합니다.
 
이러한 API를 보면 우리가 이러한 인터페이스를 실현해야 한다는 것을 알 수 있고, 프로그램의 메인 라인에 처리 프로그램을 설정해야 한다.
 
아래의 인터페이스를 보면 실현된다.
 
package com.arui.framework.android.exception;  
  
   
  
import java.lang.Thread.UncaughtExceptionHandler;  
  
import android.content.Context;  
  
   
  
/** 
 
 * Default exception handler for all activities. 
 
 *  
 
 * @author http://blog.csdn.net/arui319 
 
 * @version 2011/12/01 
 
 *  
 
 */  
  
public class DefaultExceptionHandler implements UncaughtExceptionHandler {  
  
   
  
    private Context act = null;  
  
   
  
    public DefaultExceptionHandler(Context act) {  
  
       this.act = act;  
  
    }  
  
   
  
    @Override  
  
    public void uncaughtException(Thread thread, Throwable ex) {  
  
   
  
//이상 정보를 수집하여 서버로 전송  
       sendCrashReport(ex);  
  
   
  
//반초 대기  
       try {  
  
           Thread.sleep(500);  
  
       } catch (InterruptedException e) {  
  
           //  
  
       }  
  
         
  
//처리 이상  
       handleException();  
  
   
  
    }  
  
   
  
    private void sendCrashReport(Throwable ex) {  
  
   
  
       StringBuffer exceptionStr = new StringBuffer();  
  
       exceptionStr.append(ex.getMessage());  
  
   
  
       StackTraceElement[] elements = ex.getStackTrace();  
  
       for (int i = 0; i < elements.length; i++) {  
  
           exceptionStr.append(elements[i].toString());  
  
       }  
  
   
  
       //TODO   
  
//수집된 Crash 정보를 서버로 전송  
    }  
  
   
  
    private void handleException() {  
  
       //TODO   
  
//여기서 이상을 처리할 수 있다.  
  
//예를 들어 사용자 프로그램이 붕괴되었다는 것을 알린다.  
  
//예를 들어 중요한 정보를 기록하고 현장 복구를 시도한다.  
  
//또는 아예 중요한 정보를 기록한 뒤 프로그램을 죽인다.  
  
    }  
  
   
  
}  
 
 
기본 Activity의 onCreate(Bundle saved InstanceState) 방법에 다음 코드를 추가합니다.
 
Thread.setDefaultUncaughtExceptionHandler(new DefaultExceptionHandler(  
  
       this.getApplicationContext()));  
 
 
서버에 어떻게 보냅니까?
 
이 서로 다른 프로젝트 그룹은 서로 다른 방식이 있을 것이니 구체적으로 여기서 토론하지 않겠다.이상에 대한 구체적인 정보를 서버에 보내는 것 외에 최소한 버전 정보를 보내야만 프로그래머가 서버에 있는 이상 정보가 어느 버전으로 나타났는지 판단할 수 있다는 것을 일깨워 주어야 한다.버전 정보 외에 핸드폰의 SDK 버전, 화면 해상도, 핸드폰 모델 등 정보도 필요할 수 있습니다. 이런 정보가 있으면 이상 정보를 더욱 전면적으로 이해할 수 있습니다.
 
추가 설명.
 
주 Activity에서 예외 처리 클래스를 한 번만 설정하면 되며, 모든 Acitivity에서 설정할 필요는 없습니다.
 
개인적으로 크라쉬가 발생한 후에도 현장을 복구해 계속 운행하는 것은 의미가 크지 않다고 느낀다.Crash 이후 프로그램의 운행 상황은 이미 예측할 수 없게 되었다. 하나의 오류로 다른 오류를 보완하면 그 자체가 더 많은 오류를 초래할 것이다.크래쉬의 발생을 최대한 피하는 것이 합리적이라고 조언했다.