关于应用启动连续崩溃的解决思考

1、前言

对于一个商业项目而言，质量应该是研发同学的生命线。

线上出现了大面积的崩溃或者各种不可用，那画面简直美的不敢想象。这也是任何商业项目做大之后都会花大力气在性能优化与高可用的原因，这个过程中也催生出了各种APM工具及HotFix方案，在一定程度上保障了性能同时提供了一道紧急修复的保障线。

此处提一个问题：假设经过层层流程把关控制的应用在线上还是出现了问题，而HotFix也无法生效，是不是就没得救了？

2、安全模式的起由

简单的一句话就是：避免应用在启动阶段崩溃而此时HotFix无法生效，导致的连续、严重的无法启动。

此处举一个例子：假设应用在启动阶段因为Application中某项出错而必现崩溃，而拉取热修复包的操作此时还未发生，那么这个应用就会陷入连续启动崩溃的严重情形；最终的命运一定是被用户卸载。

那么应用启动阶段的安全模式就应运而生。

3、安全模式的思考

需要明确的是任何技术都是服务于具体的业务场景，那启动阶段的安全模式就是为了解决启动阶段崩溃却无法HotFix这种严重情形。

我们来思考如下几个问题：

3.1 什么会导致启动阶段的崩溃？

现如今各个App在业务上已经发展多年，同时移动端的技术革新也开展多次，那么应用在启动阶段需要做的事情越来越多，启动崩溃的诱因可能有：

• 各种文件包括但不限于数据库、XML的拷贝或操作失败；
• 各种网络请求下发了脏数据；
• 各种资源包的下载、合并导致的脏数据，包括但不限于闪屏图、Zip包、修复包等；
• 用户由跨N多个版本的低版本App升级到最新版引发的脏数据；

由上可见应用在启动阶段并不安全，在其中任意一环出现问题都将导致严重的事故。

3.2 安全模式生效时机？

一般应用都会设置主线程的UncaughtExceptionHandler来捕获运行时的崩溃，很容易想到的就是把安全模式的判定和UncaughtExceptionHandler关联起来，但是这种做法有很大的缺陷：对Native的异常无能为力，显然不够精确；

那我们就采用逆向思维，换种思路：

• 进入应用的时候就记录一个崩溃次数，在满足一定条件之后则认为启动阶段没有异常，同时将崩溃次数重置回复初始状态；
• 异常次数到达一定程度则进入安全模式；

需要维护一个崩溃次数：

• 进入应用就把崩溃次数+1；

满足一定条件则重置崩溃次数：

• 用户正常退出应用；
• 用户打开应用满10秒；

3.3 安全模式能做什么？

• 执行预设任务，进行客户端本地的自主修复，例如：删除部分缓存、清除热修复包或者别的资源包；
• 清空整个App数据，重置至初始安装状态；
• 阻塞进程，优先执行预设任务，例如：请求以及运行热修复包，等待全部完成之后再执行正常流程；

4、如何设计一个安全模式的库？

4.1 安全模式应该提供哪些能力？

• 异常启动的检测及分级策略：检测APP启动异常，同时也细粒度区分知道异常的等级；
• 应用自修复的能力；
• 可以执行同步热修复的能力；
• 支持获取详细崩溃信息及崩溃的回调；

4.2 扩展性与易用性的设计

• 扩展性：
  • 对于各家App，安全模式的处理具有共性，但是总有场景是需要定制的，那么安全模式应该可以执行自定义的策略；
• 易用性：
  • App可快速接入，同时可快速验证策略；

4.3 整体流程图

安全模式整体流程图

5、其它

本文是从设计一个库的角度来思考应用启动连续崩溃的处理，现在我非常贴心的为大家推荐一个关于启动保护的库：StartUp-Protector：（https://github.com/liuzhao2007/StartUp-Protector），使用简单方便、侵入性低、功能完善、定制化强，欢迎使用：

1. 崩溃检测及分级策略：两次崩溃执行一级安全模式，三次崩溃执行二级安全模式；
2. 提供自修复能力，可自定义进入安全模式的处理策略；
3. 提供阻塞进程能力，可执行同步热修复；
4. 提供详细崩溃信息的获取及崩溃的回调能力；
5. 可定制崩溃后策略，例如重启的忽略策略；
6. 提供快速回归的能力；

欢迎关注微信公众号：定期分享Java、Android干货！

欢迎关注