关于Android 启动连续闪退保护方案的思考

应用启动时会执行一系列的初始化操作，例如读取热修复补丁包，读取 React Native 更新包，读取数据库，读取本地缓存文件，读取服务端数据等等，在其中某个环节如果出现文件损坏或者数据格式不正确，可能就会导致应用启动时发生连续闪退，如果闪退是发生在热修复操作之前，那么这个闪退在更新应用新版本之前将得不到修复，如果闪退发生在热修复操作之后，那么可以通过及时下发热修复补丁包解决，不过前提是需要有监控告警功能，而且有一定规模的用户遇到这种情况。快速有效的解决由于数据问题导致应用启动连续闪退的问题就是本方案提出来的目的。

保护策略

本方案的前提是应用具备监听发生闪退的能力，例如在 Android Java 层开发中，通常是实现Thread.UncaughtExceptionHandler 接口，并在回调方法 uncaughtException 中获取发生闪退的信息。

分级保护

考虑到以下几种情况，我们需要对应用实现分级保护：

• 应用发生闪退后，用户继续打开应用的概率会随着闪退次数的增加而急剧降低

• 应用本地不同的文件，重要程度不尽相同

因此，当应用连续两次发生闪退后用户继续启动应用时，开启二级保护机制（清理重要程度较低的数据）；当应用连续三次发生闪退后用户继续启动应用时，开启一级保护机制（清理白名单之外的所有数据）。

用户体验方面，在清除数据之前，是否需要弹出确认窗口让用户感知，这个可以根据具体业务进行确定，例如二级保护时不通知用户，在后台静默清理，毕竟清理的是重要程度较低的数据，当升级到一级保护后，弹出确认窗口告知用户。

依托闪退捕获机制，并使用计数器方式，判定方法如下：

• 维护一个计数器，用来表示应用连续闪退的次数

• 应用捕获到 uncaughtException 时，递增计数器的值，同时根据计数器的当前值判断是否应该启动分级保护机制

• 满足以下条件时，将计数器归零：

  • 启动一级保护机制

  • 正常启动 10 秒后

  • 用户正常退出

  • 用户主动从前台切换到后台

建议：计数器归零条件比较多，需要在代码中多处地方增加归零逻辑，代码侵入性大，因此可以考虑去掉 用户正常退出 和 用户主动从前台切换到后台 这两个判定条件，对判定结果影响甚微。

在执行数据清理时，某些目录是需要予以保留的，例如统计信息文件，应用闪退堆栈信息文件等，因此需要支持白名单功能。

数据清理的原则上只清理能在服务端重新拉取的本地数据，主要包括：

• 清除 Native 热修复补丁包

• 清除 RN 热更新 Bundle 包

• 清除 H5 离线缓存包

• 清除数据库数据

• 清除文件缓存数据

需要讨论确认数据重要性的排序。

拓展阅读

Android实现多次闪退清除数据

iOS 启动连续闪退保护方案

安全模式：天猫App启动保护实践

欢迎关注我的微信公众号 ASCE1885，专注与原创或者分享 Android，iOS，ReactNative，Web 前端移动开发领域高质量文章，主要包括业界最新动态，前沿技术趋势，开源函数库与工具等。