Java和Android崩潰捕獲機(jī)制
引言
作為開發(fā)同學(xué),每天都在面臨各種各種的崩潰問題。
我們都如果在Android應(yīng)用中發(fā)生了未捕獲的崩潰問題,不管是在主線程還是在子線程,應(yīng)用都會直接退出。
但是Java程序,子線程拋出的異常,不會引起程序的退出。
那你們知道JVM是如何處理應(yīng)用未捕獲崩潰的嗎?Android又是怎樣在發(fā)生崩潰時讓程序退出的呢?
崩潰處理機(jī)制
當(dāng)一個線程拋出異常時,JVM會調(diào)用線程的dispatchUncaughtException方法,所有未被捕獲的異常,最后都會交給UncaughtExceptionHandler處理。
對于一個線程來說,UncaughtExceptionHandler有多個,首先有針對單個線程的unCaughtExceptionHandler,然后還有靜態(tài)的首先有一個靜態(tài)的defaultUncaughtExceptionHandler和defaultUncaughtPreExceptionHandler,這個是對每個線程都生效的。
處理順序:未捕獲的異常,先由線程處理,然后由線程的ThreadGroup處理,最后再由默認(rèn)異常處理程序處理。
Android發(fā)生崩潰后
為什么Android發(fā)生異常后,不管是在主線程還是在子線程,都會引起程序crash退出呢?
其實是因為Android給所有線程都設(shè)置了一個defaultExceptionHandler,這個ExceptionHandler的處理邏輯就是讓程序退出。
下面我們來看源碼。
在應(yīng)用程序被創(chuàng)建的時候,RuntimeInit會設(shè)置一個默認(rèn)的異常處理Handler,這個異常處理Handler就是KillApplicationHandler。從名字就可以看出,這個Handler主要負(fù)責(zé)殺掉App進(jìn)程。
// RuntimInit
protected static final void commonInit() {
LoggingHandler loggingHandler = new LoggingHandler();
// 設(shè)置preExceptionHandler
Thread.setUncaughtExceptionPreHandler(loggingHandler);
// KillApplicationHandler 作為全局 Handler
Thread.setDefaultUncaughtExceptionHandler(new KillApplicationHandler(loggingHandler));
//...
}KillApplicationHandler會先調(diào)用loggingHandler打印日志,然后殺掉當(dāng)前進(jìn)程。
private static class KillApplicationHandler implements Thread.UncaughtExceptionHandler {
private final LoggingHandler mLoggingHandler;
public KillApplicationHandler(LoggingHandler loggingHandler) {
// 傳入loggingHandler用于打日志
this.mLoggingHandler = Objects.requireNonNull(loggingHandler);
}
@Override
public void uncaughtException(Thread t, Throwable e) {
try {
// 打日志
ensureLogging(t, e);
// 已經(jīng)在crash中了,不處理了
if (mCrashing) return;
mCrashing = true;
// ...
} catch (Throwable t2) {
// ...
} finally {
// 通知內(nèi)核殺掉進(jìn)程
Process.killProcess(Process.myPid());
// 停止VM
System.exit(10);
}
}所以,當(dāng)出現(xiàn)未捕獲的異常時,會交給KillApplicationHandler中的uncaughtException,從而直接讓程序退出。與此同時,我們也可以從adb日志中看到崩潰的具體堆棧。
下一篇,我們講講如何借用 uncaughtExceptionHandler的原理來實現(xiàn)Android應(yīng)用永不崩潰。
以上就是Java和Android崩潰捕獲機(jī)制的詳細(xì)內(nèi)容,更多關(guān)于Java Android崩潰捕獲的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
SpringBoot使用AOP實現(xiàn)統(tǒng)計全局接口訪問次數(shù)詳解
這篇文章主要介紹了SpringBoot通過AOP實現(xiàn)對全局接口訪問次數(shù)的統(tǒng)計,文章從相關(guān)問題展開全文內(nèi)容詳情,具有一定的參考價值,需要的小伙伴可以參考一下2022-06-06
spring boot整合mybatis利用Mysql實現(xiàn)主鍵UUID的方法
這篇文章主要給大家介紹了關(guān)于spring boot整合mybatis利用Mysql實現(xiàn)主鍵UUID的相關(guān)資料,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧。2018-03-03
使用Spring Data Jpa的CriteriaQuery一個陷阱
使用Spring Data Jpa的CriteriaQuery進(jìn)行動態(tài)條件查詢時,可能會遇到一個陷阱,當(dāng)條件為空時,查詢不到任何結(jié)果,并不是期望的返回所有結(jié)果。這是為什么呢?2020-11-11
完美解決springboot項目出現(xiàn)”java: 錯誤: 無效的源發(fā)行版:17“問題(圖文詳解)
這篇文章主要介紹了完美解決springboot項目出現(xiàn)”java: 錯誤: 無效的源發(fā)行版:17“問題,本文通過圖文并茂的形式給大家介紹的非常詳細(xì),需要的朋友可以參考下2023-04-04
mapstruct的用法之qualifiedByName示例詳解
qualifiedByName的意思就是使用這個Mapper接口中的指定的默認(rèn)方法去處理這個屬性的轉(zhuǎn)換,而不是簡單的get?set,今天通過本文給大家介紹下mapstruct的用法之qualifiedByName示例詳解,感興趣的朋友一起看看吧2022-04-04
Java多線程中ReentrantLock與Condition詳解
這篇文章主要介紹了Java多線程中ReentrantLock與Condition詳解,需要的朋友可以參考下2017-11-11
java8 對象轉(zhuǎn)Map時重復(fù) key Duplicate key xxxx的解決
這篇文章主要介紹了java8 對象轉(zhuǎn)Map時重復(fù) key Duplicate key xxxx的解決方案,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2021-09-09

