### 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已經成功地獲取了未被捕獲的異常信息,從現在開始,為應用加上默認異常事件處理器吧。
:-: 
圖13-1 CrashHandler獲取的異常信息
- 前言
- 第1章 Activity的生命周期和啟動模式
- 1.1 Activity的生命周期全面分析
- 1.1.1 典型情況下的生命周期分析
- 1.1.2 異常情況下的生命周期分析
- 1.2 Activity的啟動模式
- 1.2.1 Activity的LaunchMode
- 1.2.2 Activity的Flags
- 1.3 IntentFilter的匹配規則
- 第2章 IPC機制
- 2.1 Android IPC簡介
- 2.2 Android中的多進程模式
- 2.2.1 開啟多進程模式
- 2.2.2 多進程模式的運行機制
- 2.3 IPC基礎概念介紹
- 2.3.1 Serializable接口
- 2.3.2 Parcelable接口
- 2.3.3 Binder
- 2.4 Android中的IPC方式
- 2.4.1 使用Bundle
- 2.4.2 使用文件共享
- 2.4.3 使用Messenger
- 2.4.4 使用AIDL
- 2.4.5 使用ContentProvider
- 2.4.6 使用Socket
- 2.5 Binder連接池
- 2.6 選用合適的IPC方式
- 第3章 View的事件體系
- 3.1 View基礎知識
- 3.1.1 什么是View
- 3.1.2 View的位置參數
- 3.1.3 MotionEvent和TouchSlop
- 3.1.4 VelocityTracker、GestureDetector和Scroller
- 3.2 View的滑動
- 3.2.1 使用scrollTo/scrollBy
- 3.2.2 使用動畫
- 3.2.3 改變布局參數
- 3.2.4 各種滑動方式的對比
- 3.3 彈性滑動
- 3.3.1 使用Scroller7
- 3.3.2 通過動畫
- 3.3.3 使用延時策略
- 3.4 View的事件分發機制
- 3.4.1 點擊事件的傳遞規則
- 3.4.2 事件分發的源碼解析
- 3.5 View的滑動沖突
- 3.5.1 常見的滑動沖突場景
- 3.5.2 滑動沖突的處理規則
- 3.5.3 滑動沖突的解決方式
- 第4章 View的工作原理
- 4.1 初識ViewRoot和DecorView
- 4.2 理解MeasureSpec
- 4.2.1 MeasureSpec
- 4.2.2 MeasureSpec和LayoutParams的對應關系
- 4.3 View的工作流程
- 4.3.1 measure過程
- 4.3.2 layout過程
- 4.3.3 draw過程
- 4.4 自定義View
- 4.4.1 自定義View的分類
- 4.4.2 自定義View須知
- 4.4.3 自定義View示例
- 4.4.4 自定義View的思想
- 第5章 理解RemoteViews
- 5.1 RemoteViews的應用
- 5.1.1 RemoteViews在通知欄上的應用
- 5.1.2 RemoteViews在桌面小部件上的應用
- 5.1.3 PendingIntent概述
- 5.2 RemoteViews的內部機制
- 5.3 RemoteViews的意義
- 第6章 Android的Drawable
- 6.1 Drawable簡介
- 6.2 Drawable的分類
- 6.2.1 BitmapDrawable2
- 6.2.2 ShapeDrawable
- 6.2.3 LayerDrawable
- 6.2.4 StateListDrawable
- 6.2.5 LevelListDrawable
- 6.2.6 TransitionDrawable
- 6.2.7 InsetDrawable
- 6.2.8 ScaleDrawable
- 6.2.9 ClipDrawable
- 6.3 自定義Drawable
- 第7章 Android動畫深入分析
- 7.1 View動畫
- 7.1.1 View動畫的種類
- 7.1.2 自定義View動畫
- 7.1.3 幀動畫
- 7.2 View動畫的特殊使用場景
- 7.2.1 LayoutAnimation
- 7.2.2 Activity的切換效果
- 7.3 屬性動畫
- 7.3.1 使用屬性動畫
- 7.3.2 理解插值器和估值器 /
- 7.3.3 屬性動畫的監聽器
- 7.3.4 對任意屬性做動畫
- 7.3.5 屬性動畫的工作原理
- 7.4 使用動畫的注意事項
- 第8章 理解Window和WindowManager
- 8.1 Window和WindowManager
- 8.2 Window的內部機制
- 8.2.1 Window的添加過程
- 8.2.2 Window的刪除過程
- 8.2.3 Window的更新過程
- 8.3 Window的創建過程
- 8.3.1 Activity的Window創建過程
- 8.3.2 Dialog的Window創建過程
- 8.3.3 Toast的Window創建過程
- 第9章 四大組件的工作過程
- 9.1 四大組件的運行狀態
- 9.2 Activity的工作過程
- 9.3 Service的工作過程
- 9.3.1 Service的啟動過程
- 9.3.2 Service的綁定過程
- 9.4 BroadcastReceiver的工作過程
- 9.4.1 廣播的注冊過程
- 9.4.2 廣播的發送和接收過程
- 9.5 ContentProvider的工作過程
- 第10章 Android的消息機制
- 10.1 Android的消息機制概述
- 10.2 Android的消息機制分析
- 10.2.1 ThreadLocal的工作原理
- 10.2.2 消息隊列的工作原理
- 10.2.3 Looper的工作原理
- 10.2.4 Handler的工作原理
- 10.3 主線程的消息循環
- 第11章 Android的線程和線程池
- 11.1 主線程和子線程
- 11.2 Android中的線程形態
- 11.2.1 AsyncTask
- 11.2.2 AsyncTask的工作原理
- 11.2.3 HandlerThread
- 11.2.4 IntentService
- 11.3 Android中的線程池
- 11.3.1 ThreadPoolExecutor
- 11.3.2 線程池的分類
- 第12章 Bitmap的加載和Cache
- 12.1 Bitmap的高效加載
- 12.2 Android中的緩存策略
- 12.2.1 LruCache
- 12.2.2 DiskLruCache
- 12.2.3 ImageLoader的實現446
- 12.3 ImageLoader的使用
- 12.3.1 照片墻效果
- 12.3.2 優化列表的卡頓現象
- 第13章 綜合技術
- 13.1 使用CrashHandler來獲取應用的crash信息
- 13.2 使用multidex來解決方法數越界
- 13.3 Android的動態加載技術
- 13.4 反編譯初步
- 13.4.1 使用dex2jar和jd-gui反編譯apk
- 13.4.2 使用apktool對apk進行二次打包
- 第14章 JNI和NDK編程
- 14.1 JNI的開發流程
- 14.2 NDK的開發流程
- 14.3 JNI的數據類型和類型簽名
- 14.4 JNI調用Java方法的流程
- 第15章 Android性能優化
- 15.1 Android的性能優化方法
- 15.1.1 布局優化
- 15.1.2 繪制優化
- 15.1.3 內存泄露優化
- 15.1.4 響應速度優化和ANR日志分析
- 15.1.5 ListView和Bitmap優化
- 15.1.6 線程優化
- 15.1.7 一些性能優化建議
- 15.2 內存泄露分析之MAT工具
- 15.3 提高程序的可維護性