以跳过onStop()判定Android应用FooActivity1崩溃的逻辑存在哪些缺陷？

应用场景与检测逻辑 #

应用启动页为MainActivity，可从该页面启动FooActivity1和FooActivity2。为补充UncaughtExceptionHandler的漏捕情况，采用以下检测逻辑：

FooActivity1中的标记设置 #

@Override
protected void onStart() {
    super.onStart();
    // 在SharedPreferences中设置NormalFooActivity1Exit标记为false
    ...
}

@Override
protected void onStop() {
    super.onStop();
    // 在SharedPreferences中设置NormalFooActivity1Exit标记为true
    ...
}

MainActivity中的崩溃判定 #

@Override
public void onCreate(Bundle savedInstanceState) {
    // 检查标记
    // 若为true则不做处理
    // 若为false则记录崩溃并将标记设为true
}

核心逻辑：若下次启动应用时，FooActivity1的onStop()未执行（标记为false），则判定为FooActivity1发生崩溃。但上报数据显示该逻辑存在崩溃高估问题，以下是具体缺陷：

具体缺陷分析 #

• 系统资源回收误判：应用处于后台时，系统可能因内存不足直接杀掉进程，FooActivity1的onStop()不会执行，但这属于系统正常资源回收，并非应用崩溃，却会被误统计。
• Activity跳转的生命周期遗漏：从FooActivity1直接启动FooActivity2时，若FooActivity2是透明主题或对话框样式，FooActivity1只会执行onPause()而不会触发onStop()。用户正常返回MainActivity后，下次启动会被误判为崩溃。
• 用户主动关闭应用误判：用户通过系统任务管理器手动强制关闭应用，进程直接终止，FooActivity1的onStop()未执行，但这是用户主动操作，不属于崩溃场景，却会被统计为崩溃。
• 多进程同步问题：若应用存在多进程，SharedPreferences的跨进程读写可能出现同步异常，导致标记状态不一致，引发误判。
• 非崩溃异常退出的混入：除了崩溃外，其他导致进程直接终止的非崩溃场景（如上述几种情况）都会被纳入崩溃统计，直接拉高崩溃数据。

内容的提问来源于stack exchange，提问作者Hong