轉(zhuǎn)自：http://zhengxiaoyong.me/2016/09/05/Android%E8%BF%90%E8%A1%8C%E6%97%B6Crash%E8%87%AA%E5%8A%A8%E6%81%A2%E5%A4%8D%E6%A1%86%E6%9E%B6-Recovery/

簡介

App Crash的恢復(fù)，這個(gè)想法很早之前就有，目前有些時(shí)間就實(shí)現(xiàn)了一把，主要是對App運(yùn)行時(shí)發(fā)生Crash后，對Activity的堆棧和數(shù)據(jù)進(jìn)行恢復(fù)，或者重啟應(yīng)用，或者重啟并清空緩存，避免因本地的數(shù)據(jù)類型或格式錯(cuò)誤而導(dǎo)致App在讀取時(shí)一直Crash，Debug模式還包括Crash信息的顯示和保存，便于在開發(fā)、測試時(shí)查看相應(yīng)CrashInfo

Crash的處理

對于應(yīng)用的Crash，一般的做法我們往往都是實(shí)現(xiàn)個(gè)自定義UncaughtExceptionHandler，而這個(gè)自定義的CustomUncaughtHandler我們一般都用于捕捉Crash信息進(jìn)行上報(bào)和監(jiān)控是否發(fā)生Crash，還有一個(gè)作用就是可以屏蔽系統(tǒng)默認(rèn)的Crash對話框，也就是攔截Crash后不把系統(tǒng)默認(rèn)的UncaughtHandler設(shè)置進(jìn)去，而是直接進(jìn)行KillProcess，這個(gè)過程就是屏蔽了系統(tǒng)的默認(rèn)Crash處理流程，原因是系統(tǒng)的處理其中在AMS的crashApplication()中會(huì)執(zhí)行這么一段代碼：

1
2
3
4
5
6
7

Message msg = Message.obtain();
msg.what = SHOW_ERROR_MSG;
HashMap data = new HashMap();
data.put("result", result);
data.put("app", r);
msg.obj = data;
mUiHandler.sendMessage(msg);

發(fā)送一個(gè)顯示Dialog的消息，之后便創(chuàng)建一個(gè)AppErrorDialog進(jìn)行顯示。

當(dāng)然還有另外一種屏蔽系統(tǒng)默認(rèn)ErrorDialog的方法，就是對AMP進(jìn)行Hook，攔截handleApplicationCrash()方法后進(jìn)行KillProcess，這樣的話永遠(yuǎn)都將不會(huì)出現(xiàn)系統(tǒng)默認(rèn)對話框，即使把系統(tǒng)默認(rèn)的設(shè)置進(jìn)去了，這個(gè)方法建議App內(nèi)對AMP進(jìn)行了Hook的做，其它App反而只為實(shí)現(xiàn)這個(gè)小功能而進(jìn)行Hook成本太高，還是用自定義的做法進(jìn)行屏蔽。

Recovery

Crash處理流程

對于Recovery，在應(yīng)用發(fā)生Crash時(shí)，會(huì)進(jìn)入一個(gè)Recovery界面，在該界面可以進(jìn)行界面的恢復(fù)、應(yīng)用的重啟，或進(jìn)入debug模式進(jìn)行Crash信息的查看與保存

接入

請戳這里

RecoveryActivity

在應(yīng)用發(fā)生Crash后，將進(jìn)入RecoveryActivity界面

ActivityStack的恢復(fù)

對于恢復(fù)界面，默認(rèn)是恢復(fù)整個(gè)Activity的堆棧，以便保護(hù)用戶之前的數(shù)據(jù)

當(dāng)應(yīng)用在前臺時(shí)崩潰無非就三種：
1、界面一創(chuàng)建就崩潰，可能在onCreate等方法中讀取數(shù)據(jù)造成的Crash
2、界面創(chuàng)建且繪制完成正常顯示，在用戶執(zhí)行某個(gè)操作，如點(diǎn)擊按鈕執(zhí)行某個(gè)操作等造成的Crash
3、其它異步線程、服務(wù)等在后臺執(zhí)行任務(wù)時(shí)導(dǎo)致的Crash

上面的情況都應(yīng)恢復(fù)繪制完成后的界面，也就是棧頂Activity是在Crash之前用戶所看到的界面，而之前創(chuàng)建且未銷毀的Activity也應(yīng)該進(jìn)行恢復(fù)。

當(dāng)應(yīng)用在后臺時(shí)：
1、進(jìn)程未掛，無非就是異步線程、server等后臺任務(wù)發(fā)生異常時(shí)導(dǎo)致的Crash
2、進(jìn)程已掛，進(jìn)程被360等工具殺死了，常見的是push過來了然后喚起App進(jìn)程，在解析push信息時(shí)候?qū)е翪rash

上面的情況App在后臺時(shí)導(dǎo)致的Crash，Recovery提供了一個(gè)參數(shù)（recoverInBackgroud），用來設(shè)置是否在后臺Crash時(shí)進(jìn)行恢復(fù)。

ActivityStack恢復(fù)的操作，都是先恢復(fù)棧中的Activity，無Activity時(shí)則重啟應(yīng)用

主頁的回退

在進(jìn)行恢復(fù)Activity時(shí)，如果只是恢復(fù)棧頂Activity，當(dāng)用戶在這個(gè)界面不進(jìn)行跳轉(zhuǎn)操作而是直接按返回鍵，這將導(dǎo)致直接退出程序，所以對于這個(gè)情況應(yīng)該是回退到應(yīng)用的主頁，Recovery中有個(gè)參數(shù)mainPage，如果設(shè)置了就表示需要回退到主頁，沒有設(shè)置則不進(jìn)行回退

這個(gè)過程中涉及到獲取App內(nèi)Activity棧內(nèi)的數(shù)量和棧底Activity，是開發(fā)人員應(yīng)該都知道獲取這兩個(gè)信息是通過getRunningTasks來獲取，不過可惜，在5.0以后Google對權(quán)限進(jìn)行了收斂，目地是保護(hù)App的信息安全，這個(gè)方法在5.0以后將失效，所以需要另外一種方法進(jìn)行兼容，于是乎看6.0源碼又發(fā)現(xiàn)Google在5.0收斂了整個(gè)權(quán)限，導(dǎo)致本App的都獲取不到，但是在6.0又放出來了，不過只能獲取本應(yīng)用的數(shù)據(jù)，所以兼容的策略是5.0~6.0自己維護(hù)一個(gè)ActivityStack

連續(xù)Crash的處理

如果一分鐘內(nèi)進(jìn)行了兩次恢復(fù)后還導(dǎo)致Crash，則不進(jìn)行恢復(fù)而是重啟應(yīng)用，或者重啟并清空緩存，以便恢復(fù)App剛安裝時(shí)的狀態(tài)

靜默恢復(fù)

對于應(yīng)用運(yùn)行時(shí)發(fā)生Crash后的恢復(fù)，默認(rèn)是顯示RecoveryActivity，也就是上圖的界面來讓用戶選擇是否需要進(jìn)行恢復(fù)，同時(shí)也支持靜默恢復(fù)，也就是不顯示界面，在發(fā)生Crash后根據(jù)所配置參數(shù)自動(dòng)的恢復(fù)（重啟、恢復(fù)ActivityStack、恢復(fù)棧頂Activity、重啟并清空緩存）

無圖言屌

下面是效果圖：

靜默恢復(fù)的效果圖：

項(xiàng)目地址

歡迎star或提建議

總結(jié)

以上是生活随笔為你收集整理的Android运行时Crash自动恢复框架-Recovery的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。