对于一个商业项目而言,质量应该是研发同学的生命线。
线上出现了大面积的崩溃或者各种不可用,那画面简直美的不敢想象。这也是任何商业项目做大之后都会花大力气在性能优化与高可用的原因,这个过程中也催生出了各种APM工具及HotFix方案,在一定程度上保障了性能同时提供了一道紧急修复的保障线。
此处提一个问题:假设经过层层流程把关控制的应用在线上还是出现了问题,而HotFix也无法生效,是不是就没得救了?
简单的一句话就是:避免应用在启动阶段崩溃而此时HotFix无法生效,导致的连续、严重的无法启动。
此处举一个例子:假设应用在启动阶段因为Application中某项出错而必现崩溃,而拉取热修复包的操作此时还未发生,那么这个应用就会陷入连续启动崩溃的严重情形;最终的命运一定是被用户卸载。
那么应用启动阶段的安全模式就应运而生。
需要明确的是任何技术都是服务于具体的业务场景,那启动阶段的安全模式就是为了解决启动阶段崩溃却无法HotFix这种严重情形。
我们来思考如下几个问题:
现如今各个App在业务上已经发展多年,同时移动端的技术革新也开展多次,那么应用在启动阶段需要做的事情越来越多,启动崩溃的诱因可能有:
由上可见应用在启动阶段并不安全,在其中任意一环出现问题都将导致严重的事故。
一般应用都会设置主线程的UncaughtExceptionHandler来捕获运行时的崩溃,很容易想到的就是把安全模式的判定和UncaughtExceptionHandler关联起来,但是这种做法有很大的缺陷:对Native的异常无能为力,显然不够精确;
那我们就采用逆向思维,换种思路:
需要维护一个崩溃次数:
满足一定条件则重置崩溃次数:
本文是从设计一个库的角度来思考应用启动连续崩溃的处理,现在我非常贴心的为大家推荐一个关于启动保护的库:StartUp-Protector:(https://github.com/liuzhao2007/StartUp-Protector),使用简单方便、侵入性低、功能完善、定制化强,欢迎使用: