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

來自專欄 UI設計師成長營

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

可靠性六條基本準則

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

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

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

4、已發生故障，需在最短時間內得到恢復；

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

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

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

可靠性故障的現象及根因

應用不響應（ANR）

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

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

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

(4)獲取系統資源阻塞，比如訪問文件系統，資料庫，網路，CPU等；

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

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

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

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

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

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

應用閃退或者頻繁閃退

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

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

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

Android應用故障案例分享

一、應用資源異常

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

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

3、某著名社交軟體收到消息通知之前，需要獲取通話狀態。如果該應用短時間內收到通知消息特別多，直接會將system_server的binder線程全部佔滿，導致其他應用和服務無法與system_server通信，直接導致系統重啟。

二、應用的特殊行為

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

2、某著名社交軟體收到消息通知之前，需要獲取通話狀態。如果該應用短時間內收到通知消息特別多，直接會將system_server的binder線程全部佔滿，導致其他應用和服務無法與system_server通信，直接導致系統重啟。

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

三、兼容性問題

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

2、某應用推送最新版本異常。應用升級之後，用戶無法使用。

3、ROM升級之後，導致應用無法使用。ROM升級之後，該應用讀取電話薄失敗，應用頻繁Crash，導致手機電話過程中無法掛斷。

可靠性設計的一般準則

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

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

2、仔細設計任務同步&並發：採用同步還是非同步？多任務並發？

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

4、對象生命周期的閉合；

5、良好的用戶交互和提示：別讓用戶以為應用crash

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

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

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

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

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

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

1、分配的資源必須在確定的地方釋放；

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

四、優秀的編碼能力

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

五、完備的測試故障用例

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

來源：掘金

原文鏈接：https://juejin.im/post/5addaf55f265da0ba76f598b