帶你認識那些App可靠性設計

可靠性是軟件一個重要的質量屬性，它關注的是軟件功能持續的可用性，以及出現故障以後是否可以容錯，是否能快速的恢復使用。

可靠性六條基本準則

一、故障應在第一時間被檢測和感知；

二、能避免的故障都不該該發生；

三、不可避免或沒法預測的故障，需進行容錯；

四、已發生故障，需在最短期內獲得恢復；

五、對象狀態和生命期都應該是完備的，閉合的；

六、資源必須合理和均衡地使用；

應用做爲直接提供用戶服務，與用戶交互最多的環節，其可靠性對用戶體驗的影響巨大，甚至會高於系統對用戶形成的影響。

可靠性故障的現象及根因

應用不響應（ANR）

(1)應用將耗時操做或者同步調用放在UI線程，廣播接收器裏處理；

(2)應用資源異常，如內存，文件，線程等的濫用、泄露；

(3)消息、通知過載，忙不過來；

(4)獲取系統資源阻塞，好比訪問文件系統，數據庫，網絡，CPU等；

應用啓動不起來，界面卡住凍屏，黑屏，白屏

(1)應用啓動階段必現閃退；

(2)應用在啓動階段作了特殊的耗時、阻塞動做；

(3)應用事件處理bug，例如：應用接收事件但不作任何響應；

(4)應用資源異常，獲取系統資源阻塞；

(5)應用窗口狀態異常，或者使用定製的顯示繪製接口致使；

應用閃退或者頻繁閃退

(1)低級編碼錯誤，多線程併發錯誤，app質量不合格；

(2)異常處理不閉合，不完備；

(3)版本兼容性問題，硬件兼容性問題；

Android應用故障案例分享

1、應用資源異常

一、某輸入法軟件爲了保證應用能常駐內存不被系統清理，在應用進程退出時，高頻率註冊1秒的定時器，定時器到時候，當即拉起該應用及關聯應用。若是系統反覆清理該應用，該應用會反覆自啓動，致使系統卡頓很嚴重。

二、某應用反覆註冊了800+個應用權限管理的AppOps Listener，在執行callback的時候直接致使system_server進程的global reference table overflow，系統重啓。

三、某著名社交軟件收到消息通知以前，須要獲取通話狀態。若是該應用短期內收到通知消息特別多，直接會將system_server的binder線程所有佔滿，致使其餘應用和服務沒法與system_server通訊，直接致使系統重啓。

2、應用的特殊行爲

一、某社交軟件在自身升級後的首次啓動過程當中，長時間進入dex2oat優化過程，應用界面顯示黑屏。按back鍵無效，只能手殺，大量用戶反饋手機黑屏死機。

二、某著名社交軟件收到消息通知以前，須要獲取通話狀態。若是該應用短期內收到通知消息特別多，直接會將system_server的binder線程所有佔滿，致使其餘應用和服務沒法與system_server通訊，直接致使系統重啓。

三、某應用註冊加速度傳感器以及近距離傳感器監聽的邏輯：若兩個傳感器的註冊有任何一個失敗或者被拒，則會進行無限重試，直到二者全成功，該邏輯會致使距離傳感器被反覆執行註冊，導致system_server的fd數量急速增長，超過1024，致使system_server進程崩潰，系統重啓。

3、兼容性問題

一、Google 版本升級致使。應用升級N版本以後，應用頻繁閃退，功能缺失，應用沒法使用，清除數據和緩存也無效，系統負載高，用戶退機。

二、某應用推送最新版本異常。應用升級以後，用戶沒法使用。

三、ROM升級以後，致使應用沒法使用。ROM升級以後，該應用讀取電話薄失敗，應用頻繁Crash，致使手機電話過程當中沒法掛斷。

可靠性設計的通常準則

1、業務功能的可靠性設計

一、合理分配執行任務：哪些放在前臺？哪些放在後臺？

二、仔細設計任務同步&併發：採用同步仍是異步？多任務併發？

三、任務負載的均衡：多個業務執行流有序執行；

四、對象生命週期的閉合；

五、良好的用戶交互和提示：別讓用戶覺得應用crash

2、應用數據源可靠性設計

一、應用核心的數據/文件應有備份和容錯設計

二、來自外部輸入設備的數據，應用應能判別數據的合法性，例如被破壞的數據源，非法的外部數據/命令

三、向外發起的服務請求，要有超時和有限重試設計，外部擾動不致使應用卡死

四、外部發起的攻擊性請求，例如通知，廣播，要有防禦設計

3、應用的資源可靠性設計

一、分配的資源必須在肯定的地方釋放；

二、使用資源必須有明確的上界，如內存，磁盤，文件，線程。

4、優秀的編碼能力

優秀的編碼能力是應用可靠性設計的基礎；

5、完備的測試故障用例

事先考慮到應用內部、外部可能發生的故障，將故障的集合定義出來，針對性的設計故障用例。

編輯：千鋒UI設計

來源：掘金