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

一、前言

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

线上出现了大面积的崩溃或者各类不可用，那画面简直美的不敢想象。这也是任何商业项目作大以后都会花大力气在性能优化与高可用的缘由，这个过程当中也催生出了各类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干货！