Android crash 收集

Android Crash

在開發中，會遇到crash問題，通常來講，crash發生在java層，可是，有時候會發生在其餘層面上。大體，Android Crash 大體有三類：

1. Java uncatch exception
2. ANR crash
3. Native crash

Java全局異常處理

經過Thread.setDefaultUncaughtExceptionHandler咱們能夠指定一個默認的全局異常處理器，該處理器由JVM發現UNCATCH EXCEPTION 的時候調用

public class Main {
	public static void main(String args[]){
		Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {
			@Override
			public void uncaughtException(Thread t, Throwable e) {
				System.out.println("FFF");
			}
		});
		new Thread(new Runnable() {
			@Override
			public void run() {
				throw new RuntimeException("CC");
			}
		}).start();
	}
}

堆棧圖：

堆棧的ROOT方法：

/**
* Dispatch an uncaught exception to the handler. This method is
* intended to be called only by the JVM.
*/
private void dispatchUncaughtException(Throwable e) {
	getUncaughtExceptionHandler().uncaughtException(this, e);
}

ANR crash

ANR 產生的緣由主要是UI線程被卡住太長時間了，其大部分是由於網絡訪問引發的，幸虧4.0之後，就不支持在UI線程訪問網絡了。

ANR 一旦發生，一般會在Logcat中刷出問題，可是，若是該APP已經發布了，就沒法經過logcat查看到崩潰日誌了。

幸虧，咱們能夠經過**/data/anr/traces.txt** 來讀取最後一次ANR日誌。 具體能夠參考ANR文章。

Native crash

由於性能的問題，Android中的遊戲開發等，一般使用native（C語言）開發，由於脫離了JVM環境，因此一旦發生crash，錯誤就比較難以定位，咱們須要藉助操做系統的力量進行crash日誌收集。

DEBUG

若是正在開發APP中，及時發現問題，那麼能夠經過 ndk-stack 來查看崩潰位置ndk-stack使用

RELEASE

麻煩的問題就是在於，若是APP發佈了，就不能經過logcat來獲取崩潰日誌了。此時，只能藉助於Android依賴的系統來完成日誌捕獲的功能。大部分Android系統是依賴Linux系統，因此，只用經過Linux對原生程序崩潰的處理方法，就能夠完成日誌的捕獲。

在Linux 中，一般採用信號來捕獲各類異常狀態的，因此只須要註冊一個咱們的信號量監聽器就能夠完成對崩潰事件的監聽。而後，利用參數info能夠獲取崩潰stack位置，最後經過回溯stack，就能夠打印出崩潰點的C棧了。

具體能夠參考善用backtrace解決大問題，也能夠直接採用 **google breakpad **開源項目解決這個問題。

總結

通過上述分析，能夠發現Android平臺的崩潰點仍是比較多的，對於ANR和Native crash 的日誌收集仍是比較困難的。 經過TX Bugly 能夠直接Hold住這些問題，看介紹是這樣子的。對於TX Bugly的原理，我的認爲應該和本文描述相似，但願有大牛能解密。

對於應用的crash狀況，相信各個平臺都有相對應的一套機制來幫助程序員定位異常點。