iOS 啟動連續閃退保護方案

「如果某個實體表現出以下任何一種特性，它就具備自主性：自我修復、自我保護、自我維護、對目標的自我控制、自我改進。」 —— 凱文·凱利

本文**了連續閃退問題的產生原因、檢測、修復機制，以及如何在你的專案中引入、測試和使用gybootingprotection。

1. 捕獲異常

檢測連續閃退，可以通過捕獲異常來實現，異常有以下種類：

如何捕獲異常

通過以下方法捕獲異常：

crash 上報工具如 plcrashreporter 通過註冊 mach 異常 + unix訊號的 handler 達到檢測的目的，對使用者提供了處理異常的介面。

如何檢測

可以利用 plcrashreporter 這類工具來檢測連續閃退：

首先維護乙個計數變數，表示連續閃退次數

在 plcrashreporter 的 crash handler 中加入邏輯：如果啟動 5s 內 crash 使計數器加一

每次啟動時，如果連續閃退計數 > n，則檢測到了連續閃退

流程圖優缺點

2. 計時器方法

除了通過捕獲異常的方式檢測連續閃退，還可以通過計數器方法來檢測：

維護乙個計數變數，用於表示連續閃退的次數

流程圖優缺點

而計數器方法邏輯簡單，與原有的**耦合小。雖然有誤報可能（在啟動後立即被 kill 掉，誤認為 crash），但是可以通過設定閾值來減小誤報的誤報率。

綜上權衡，我們使用計時器方法檢測連續閃退。

資料庫損壞：在日常使用如異常退出、斷電，或者錯誤的操作（參考：sqlite corruption causes）。

檔案損壞：處理檔案時如果沒有@try...catch，損壞檔案會丟擲n***ception導致 crash

網路返回資料處理異常：比如預期返回陣列，但實際返回了字典，對字典物件執行-objectatindex方法會產生crash： unknow selector send to object；，或返回破損的 tar 包，在解壓失敗導致 crash。

** bug：當必 crash 的**出現在啟動關鍵路徑中，就會導致連續閃退。

針對 1，可以通過工具修復資料庫，或者刪除 db。針對2，可以刪除檔案來進行修復。對於 3 和 4，我們需要具體地分析 crash 案例，通過 jspatch 來進行修復。

進入 didfinishlaunch 時檢查是否有連續閃退，無則執行 5

彈 toast 提示使用者是否修復，輕觸『修復』執行2，否則執行 5

這裡是為了解決上述第4點 - ** bug 導致的閃退，使用 jspatch [github]可以進行熱修復。在 didfinishlaunching 時，會卡住介面發請求檢查是否有可用的 jspatch 指令碼，如果有則載入執行，解決** bug 導致的閃退。

嘗試刪除documents/library/caches目錄下的所有檔案

a. 不刪除檔案，只修復資料庫

b. 修復前把使用者資料備份到雲端

c. 收集 crash 樣本，查明原因，定製 jspatch 修復補丁並下發

進入原 didfinishlaunch

連續閃退檢測 + 保護流程如圖所示：

檢測的邏輯 gybootingprotection 已經處理好，修復的處理預留了介面，可以由使用者自定義，把自定義的修復流程傳入 repairblock 即可。

- (void)onbeforebootingprotection ];
[gybootingprotection setreportblock:^(nsinteger crashcounts) ];
}

在onbootingprotection方法中新增修復邏輯，比如刪除檔案：

- (void)onbootingprotection

如需執行非同步的修復邏輯，在onbootingprotectionwithcompletion:方法新增修復邏輯，並在完成修復後呼叫 completion ：

- (void)onbootingprotectionwithcompletion:(boolcompletionblock)completion ];
}

首先製造連續閃退場景：

當連續閃退超過 5 次時，會提示使用者修復：