<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ThinkChat2.0新版上線,更智能更精彩,支持會話、畫圖、視頻、閱讀、搜索等,送10W Token,即刻開啟你的AI之旅 廣告
                ### 13.1 使用CrashHandler來獲取應用的crash信息 Android應用不可避免地會發生crash,也稱之為崩潰,無論你的程序寫得多么完美,總是無法完全避免crash的發生,可能是由于Android系統底層的bug,也可能是由于不充分的機型適配或者是糟糕的網絡狀況。當crash發生時,系統會kill掉正在執行的程序,現象就是閃退或者提示用戶程序已停止運行,這對用戶來說是很不友好的,也是開發者所不愿意看到的。更糟糕的是,當用戶發生了crash,開發者卻無法得知程序為何crash,即便開發人員想去解決這個crash,但是由于無法知道用戶當時的crash信息,所以往往也無能為力。幸運的是,Android提供了處理這類問題的方法,請看下面Thread類中的一個方法setDefaultUncaughtExceptionHandler: /** * Sets the default uncaught exception handler. This handler is invoked in * case any Thread dies due to an unhandled exception. * * @param handler * The handler to set or null. */ public static void setDefaultUncaughtExceptionHandler(UncaughtException- Handler handler) { Thread.defaultUncaughtHandler = handler; } 從方法的字面意義來看,這個方法好像可以設置系統的默認異常處理器,其實這個方法就可以解決上面所提到的crash問題。當crash發生的時候,系統就會回調UncaughtExceptionHandler的uncaughtException方法,在uncaughtException方法中就可以獲取到異常信息,可以選擇把異常信息存儲到SD卡中,然后在合適的時機通過網絡將crash信息上傳到服務器上,這樣開發人員就可以分析用戶crash的場景從而在后面的版本中修復此類crash。我們還可以在crash發生時,彈出一個對話框告訴用戶程序crash了,然后再退出,這樣做比閃退要溫和一點。 有了上面的分析,現在讀者肯定知道獲取應用crash信息的方式了。首先需要實現一個UncaughtExceptionHandler對象,在它的uncaughtException方法中獲取異常信息并將其存儲在SD卡中或者上傳到服務器供開發人員分析,然后調用Thread的setDefaultUncaught-ExceptionHandler方法將它設置為線程默認的異常處理器,由于默認異常處理器是Thread類的靜態成員,因此它的作用對象是當前進程的所有線程。這么來看監聽應用的crash信息實際上是很簡單的一件事,下面是一個典型的異常處理器的實現: public class CrashHandler implements UncaughtExceptionHandler { private static final String TAG = "CrashHandler"; private static final boolean DEBUG = true; private static final String PATH = Environment.getExternal- StorageDirectory().getPath() + "/CrashTest/log/"; private static final String FILE_NAME = "crash"; private static final String FILE_NAME_SUFFIX = ".trace"; private static CrashHandler sInstance = new CrashHandler(); private UncaughtExceptionHandler mDefaultCrashHandler; private Context mContext; private CrashHandler() { } public static CrashHandler getInstance() { return sInstance; } public void init(Context context) { mDefaultCrashHandler = Thread.getDefaultUncaughtExceptionHandler(); Thread.setDefaultUncaughtExceptionHandler(this); mContext = context.getApplicationContext(); } /** * 這個是最關鍵的函數,當程序中有未被捕獲的異常,系統將會自動調用#uncaught- Exception方法 * thread為出現未捕獲異常的線程,ex為未捕獲的異常,有了這個ex,我們就可以得到異 常信息 */ @Override public void uncaughtException(Thread thread, Throwable ex) { try { //導出異常信息到SD卡中 dumpExceptionToSDCard(ex); //這里可以上傳異常信息到服務器,便于開發人員分析日志從而解決bug uploadExceptionToServer(); } catch (IOException e) { e.printStackTrace(); } ex.printStackTrace(); //如果系統提供了默認的異常處理器,則交給系統去結束程序,否則就由自己結束自己 if (mDefaultCrashHandler ! = null) { mDefaultCrashHandler.uncaughtException(thread, ex); } else { Process.killProcess(Process.myPid()); } } private void dumpExceptionToSDCard(Throwable ex) throws IOException { //如果SD卡不存在或無法使用,則無法把異常信息寫入SD卡 if (! Environment.getExternalStorageState().equals(Environment. MEDIA_MOUNTED)) { if (DEBUG) { Log.w(TAG, "sdcard unmounted, skip dump exception"); return; } } File dir = new File(PATH); if (! dir.exists()) { dir.mkdirs(); } long current = System.currentTimeMillis(); String time = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date(current)); File file = new File(PATH + FILE_NAME + time + FILE_NAME_SUFFIX); try { PrintWriter pw = new PrintWriter(new BufferedWriter(new FileWriter(file))); pw.println(time); dumpPhoneInfo(pw); pw.println(); ex.printStackTrace(pw); pw.close(); } catch (Exception e) { Log.e(TAG, "dump crash info failed"); } } private void dumpPhoneInfo(PrintWriter pw)throws NameNotFoundException{ PackageManager pm = mContext.getPackageManager(); PackageInfo pi = pm.getPackageInfo(mContext.getPackageName(), PackageManager.GET_ACTIVITIES); pw.print("App Version: "); pw.print(pi.versionName); pw.print('_'); pw.println(pi.versionCode); //Android版本號 pw.print("OS Version: "); pw.print(Build.VERSION.RELEASE); pw.print("_"); pw.println(Build.VERSION.SDK_INT); //手機制造商 pw.print("Vendor: "); pw.println(Build.MANUFACTURER); //手機型號 pw.print("Model: "); pw.println(Build.MODEL); //CPU架構 pw.print("CPU ABI: "); pw.println(Build.CPU_ABI); } private void uploadExceptionToServer() { //TODO Upload Exception Message To Your Web Server } } 從上面的代碼可以看出,當應用崩潰時,CrashHandler會將異常信息以及設備信息寫入SD卡,接著將異常交給系統處理,系統會幫我們中止程序,如果系統沒有默認的異常處理機制,那么就自行中止。當然也可以選擇將異常信息上傳到服務器,本節中的CrashHandler并沒有實現這個邏輯,但是在實際開發中一般都需要將異常信息上傳到服務器。 如何使用上面的CrashHandler呢?也很簡單,可以選擇在Application初始化的時候為線程設置CrashHandler,如下所示。 public class TestApp extends Application { private static TestApp sInstance; @Override public void onCreate() { super.onCreate(); sInstance = this; //在這里為應用設置異常處理,然后程序才能獲取未處理的異常 CrashHandler crashHandler = CrashHandler.getInstance(); crashHandler.init(this); } public static TestApp getInstance() { return sInstance; } } 經過上面兩個步驟,程序就可以處理未處理的異常了,就再也不怕程序crash了,同時還可以很方便地從服務器上查看用戶的crash信息。需要注意的是,代碼中被catch的異常不會交給CrashHandler處理,CrashHandler只能收到那些未被捕獲的異常。下面我們就模擬一下發生crash的情形,看程序是如何處理的,如下所示。 public class CrashActivity extends Activity implements OnClickListener { private Button mButton; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_crash); initView(); } private void initView() { mButton = (Button) findViewById(R.id.button1); mButton.setOnClickListener(this); } @Override public void onClick(View v) { if (v == mButton) { // 在這里模擬異常拋出情況,人為地拋出一個運行時異常 throw new RuntimeException("自定義異常:這是自己拋出的異常"); } } } 在上面的測試代碼中,給按鈕加一個單擊事件,在onClick中人為拋出一個運行時異常,這個時候程序就crash了,看看異常處理器為我們做了什么。從圖13-1中可以看出,異常處理器為我們創建了一個日志文件,打開日志文件,可以看到手機的信息以及異常發生時的調用棧,有了這些內容,開發人員就很容易定位問題了。從圖13-1中的函數調用棧可以看出,CrashActivity的28行發生了RuntimeException,再看一下CrashActivity的代碼,發現28行的確拋出了一個RuntimeException,這說明CrashHandler已經成功地獲取了未被捕獲的異常信息,從現在開始,為應用加上默認異常事件處理器吧。 :-: ![](https://img.kancloud.cn/b4/ea/b4ea01e6f63fc5974a7f5531ab448f00_690x606.png) 圖13-1 CrashHandler獲取的異常信息
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看