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

Crash的處理

對于應用的Crash，一般的做法我們往往都是實現(xiàn)個自定義UncaughtExceptionHandler，而這個自定義的CustomUncaughtHandler我們一般都用于捕捉Crash信息進行上報和監(jiān)控是否發(fā)生Crash，還有一個作用就是可以屏蔽系統(tǒng)默認的Crash對話框，也就是攔截Crash后不把系統(tǒng)默認的UncaughtHandler設置進去，而是直接進行KillProcess，這個過程就是屏蔽了系統(tǒng)的默認Crash處理流程，原因是系統(tǒng)的處理其中在AMS的crashApplication()中會執(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ā)送一個顯示Dialog的消息，之后便創(chuàng)建一個AppErrorDialog進行顯示。

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

Recovery

Crash處理流程

對于Recovery，在應用發(fā)生Crash時，會進入一個Recovery界面，在該界面可以進行界面的恢復、應用的重啟，或進入debug模式進行Crash信息的查看與保存

接入

請戳這里

RecoveryActivity

在應用發(fā)生Crash后，將進入RecoveryActivity界面

ActivityStack的恢復

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

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

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

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

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

ActivityStack恢復的操作，都是先恢復棧中的Activity，無Activity時則重啟應用

主頁的回退

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

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

連續(xù)Crash的處理

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

靜默恢復

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

無圖言屌

下面是效果圖：

靜默恢復的效果圖：

項目地址

歡迎star或提建議

總結(jié)

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

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