AndroidフィードバックCrashレポート

5069 ワード

この文章は他人を転載して、責任を負って変更して、全局で異常に変更しました
なぜCrashレポートをフィードバックする必要がありますか?
 
Androidアプリを作るには、プログラムCrashの発生をできるだけ避ける必要があります.ゼロCrashはプログラマーが追いかける最終目標だが、現実的にはプログラマーはCrashの発生をできるだけ減らすしかなく、Crashを完全に根絶することはほとんど不可能である.もしかすると、あなたのアプリケーションの頑丈性はすでに完璧に近いと思って、簡単にテスト部門の悪魔のような試練に耐えられたかもしれませんが、あなたのアプリケーションが市場に発表され、百万人から千万人のレベルのユーザーに直面したとき、そんなにラッキーではないかもしれません.
以上の理由から、一般的なアプリケーションには、Crashフィードバックのメカニズムが必要です.プログラマはフィードバックの結果に基づいて、現在のバージョンのコードを改善し、パブリケーションの次のバージョンをより安定させることができます.
 
どのようにフィードバックしますか?
 
まず、Crashの発生をキャプチャする方法を見てみましょう.
 
Javaには、説明を参照してください.static interface
Thread.UncaughtExceptionHandlerは、Threadが取得されていない例外によって突然終了した場合に、プロセッサのインタフェースを呼び出す.
 
Threadクラスの1つの方法を見てみましょう.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;  
       
//システムエラーを自分のThreadに変更する.setDefaultUncaughtExceptionHandler(this);
  
    }  
  
   
  
    @Override  
  
    public void uncaughtException(Thread thread, Throwable ex) {  
  
   
  
//異常情報収集、サーバへ送信
  
       sendCrashReport(ex);  
  
   
  
//30分待ち  
       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 savedInstanceState)メソッドに次のコードを追加します.
 
Thread.setDefaultUncaughtExceptionHandler(new DefaultExceptionHandler(  
  
       this.getApplicationContext()));  
に変化を与える
/**
*新しいクラスはAndroidManifestで呼び出されました
*/
public class MyApplication extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        MyCrashHandler.getInstance().init(this);
    }
}
//AndroidManifest
                    
android:name=".MyApplication"
                 android:icon="@drawable/ic_launcher">
 
サーバへの送信方法
 
この異なるプロジェクトグループには異なる方法がありますが、具体的にはここでは議論しません.注意しなければならないのは、異常の具体的な情報をサーバに送信する以外に、少なくともバージョン情報を送信する必要があります.これにより、プログラマはサーバ上の異常情報がどのバージョンで発生したかを判断することができます.バージョン情報以外にも、携帯電話のSDKバージョン、画面解像度、携帯電話の機種などの情報が必要かもしれませんが、これらの情報があれば、異常情報をより全面的に理解することができます.
 
詳細はこちら.
 
プライマリActivityに例外処理クラスを1回設定するだけで、すべてのActivityに設定する必要はありません.
 
個人的にはCrashが発生した後、現場を回復して運行を続ける意味はあまりないと感じています.Crash以降、プログラムの実行状況はすでに予知できないので、1つのエラーを使って、別のエラーを補うと、それ自体がより多くのエラーを招きます.Crashの発生をできるだけ避けることをお勧めします.
 
---------------------------------------------------------------------------
GL(arui319)
http://blog.csdn.net/arui319
<本文は転載可能ですが、上記の著者情報を残してください.ありがとうございます.>
---------------------------------------------------------------------------