App可靠性设计

可靠性是软件一个重要的质量属性,它关注的是软件功能持续的可用性,以及出现故障之后是否能够容错,是否能快速的恢复使用。

可靠性六条基本准则

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、使用资源必须有明确的上界,如内存,磁盘,文件,线程。

四、优秀的编码能力

优秀的编码能力是应用可靠性设计的基础;

五、完备的测试故障用例

事先考虑到应用内部、外部可能发生的故障,将故障的集合定义出来,针对性的设计故障用例。

相关推荐