關於應用啓動連續崩潰的解決思考

一、前言

對於一個商業項目而言，質量應該是研發同窗的生命線。

線上出現了大面積的崩潰或者各類不可用，那畫面簡直美的不敢想象。這也是任何商業項目作大以後都會花大力氣在性能優化與高可用的緣由，這個過程當中也催生出了各類APM工具及HotFix方案，在必定程度上保障了性能同時提供了一道緊急修復的保障線。

此處提一個問題：假設通過層層流程把關控制的應用在線上仍是出現了問題，而HotFix也沒法生效，是否是就沒得救了？

二、安全模式的起由

簡單的一句話就是：避免應用在啓動階段崩潰而此時HotFix沒法生效，致使的連續、嚴重的沒法啓動。

此處舉一個例子：假設應用在啓動階段由於Application中某項出錯而必現崩潰，而拉取熱修復包的操做此時還未發生，那麼這個應用就會陷入連續啓動崩潰的嚴重情形；最終的命運必定是被用戶卸載。

那麼應用啓動階段的安全模式就應運而生。

三、安全模式的思考

須要明確的是任何技術都是服務於具體的業務場景，那啓動階段的安全模式就是爲了解決啓動階段崩潰卻沒法HotFix這種嚴重情形。

咱們來思考以下幾個問題：

3.1 什麼會致使啓動階段的崩潰？

現現在各個App在業務上已經發展多年，同時移動端的技術革新也開展屢次，那麼應用在啓動階段須要作的事情愈來愈多，啓動崩潰的誘因可能有：

• 各類文件包括但不限於數據庫、XML的拷貝或操做失敗；
• 各類網絡請求下發了髒數據；
• 各類資源包的下載、合併致使的髒數據，包括但不限於閃屏圖、Zip包、修復包等；
• 用戶由跨N多個版本的低版本App升級到最新版引起的髒數據；

由上可見應用在啓動階段並不安全，在其中任意一環出現問題都將致使嚴重的事故。

3.2 安全模式生效時機？

通常應用都會設置主線程的UncaughtExceptionHandler來捕獲運行時的崩潰，很容易想到的就是把安全模式的斷定和UncaughtExceptionHandler關聯起來，可是這種作法有很大的缺陷：對Native的異常無能爲力，顯然不夠精確；

那咱們就採用逆向思惟，換種思路：

• 進入應用的時候就記錄一個崩潰次數，在知足必定條件以後則認爲啓動階段沒有異常，同時將崩潰次數重置回覆初始狀態；
• 異常次數到達必定程度則進入安全模式；

須要維護一個崩潰次數：

• 進入應用就把崩潰次數+1；

知足必定條件則重置崩潰次數：

• 用戶正常退出應用；
• 用戶打開應用滿10秒；

3.3 安全模式能作什麼？

• 執行預設任務，進行客戶端本地的自主修復，例如：刪除部分緩存、清除熱修復包或者別的資源包；
• 清空整個App數據，重置至初始安裝狀態；
• 阻塞進程，優先執行預設任務，例如：請求以及運行熱修復包，等待所有完成以後再執行正常流程；

四、如何設計一個安全模式的庫？

4.1 安全模式應該提供哪些能力？

• 異常啓動的檢測及分級策略：檢測APP啓動異常，同時也細粒度區分知道異常的等級；
• 應用自修復的能力；
• 能夠執行同步熱修復的能力；
• 支持獲取詳細崩潰信息及崩潰的回調；

4.2 擴展性與易用性的設計

• 擴展性：
  • 對於各家App，安全模式的處理具備共性，可是總有場景是須要定製的，那麼安全模式應該能夠執行自定義的策略；
• 易用性：
  • App可快速接入，同時可快速驗證策略；

4.3 總體流程圖

五、其它

本文是從設計一個庫的角度來思考應用啓動連續崩潰的處理，如今我很是貼心的爲你們推薦一個關於啓動保護的庫：StartUp-Protector：（github.com/liuzhao2007…），使用簡單方便、侵入性低、功能完善、定製化強，歡迎使用：

1. 崩潰檢測及分級策略：兩次崩潰執行一級安全模式，三次崩潰執行二級安全模式；
2. 提供自修復能力，可自定義進入安全模式的處理策略；
3. 提供阻塞進程能力，可執行同步熱修復；
4. 提供詳細崩潰信息的獲取及崩潰的回調能力；
5. 可定製崩潰後策略，例如重啓的忽略策略；
6. 提供快速回歸的能力；

歡迎關注微信公衆號：按期分享Java、Android乾貨！