Mihon项目中的Crashlytics异常上报失效问题分析与解决方案

问题背景

在Mihon项目0.16.5版本中，开发团队发现了一个关键的监控系统失效问题。Firebase Crashlytics作为应用崩溃监控的重要工具，在实际运行中未能正确捕获和上报异常事件。这个问题在Android 14系统的AVD模拟器上被明确复现，但很可能影响所有Android设备。

技术原理分析

Crashlytics的正常工作流程

Firebase Crashlytics通常通过以下流程工作：

1. 初始化SDK并注册默认异常处理器
2. 当未捕获异常发生时，系统会将异常传递给注册的处理器链
3. Crashlytics处理器记录异常信息并上传到服务器
4. 开发者可以在Firebase控制台查看崩溃报告

Mihon项目中的异常处理机制

项目实现了一个GlobalExceptionHandler，这是一个全局异常处理器，主要功能是：

• 拦截所有未捕获异常
• 显示崩溃界面(CrashScreen)
• 理论上应该将异常继续传递给原始处理器链

问题根源

经过代码分析，发现问题出在异常处理链的中断上。GlobalExceptionHandler在捕获异常后，虽然正确地显示了崩溃界面，但没有将异常继续传递给系统默认的处理器(defaultHandler)。这导致Crashlytics注册的处理器永远接收不到异常事件，因此无法记录和上报崩溃信息。

解决方案

正确的实现应该保持异常处理链的完整性。修改后的GlobalExceptionHandler应该：

1. 首先执行必要的应急处理（如显示用户友好的崩溃界面）
2. 将异常原样传递给原始处理器链
3. 确保Crashlytics处理器能够接收到异常

这种修改既保留了改善用户体验的崩溃界面功能，又不影响崩溃监控系统的正常工作。

实现建议

在技术实现上，建议采用以下模式：

try {
    // 原有业务逻辑
} catch (Exception e) {
    // 1. 显示崩溃界面
    showCrashScreen(e);
    
    // 2. 传递给原始处理器
    if (defaultHandler != null) {
        defaultHandler.uncaughtException(thread, e);
    }
}

影响评估

这个问题的修复将带来以下改进：

1. 恢复崩溃监控能力，帮助开发者及时发现和修复问题
2. 不影响现有的用户体验改进（崩溃界面仍然显示）
3. 提高应用的整体稳定性监控水平

最佳实践建议

对于类似的项目，建议：

1. 在自定义全局异常处理器时，始终保留原始处理链
2. 对崩溃监控系统进行端到端测试，确保其正常工作
3. 考虑在开发阶段增加崩溃上报的验证机制

这个问题提醒我们，在增强用户体验的同时，不能忽视基础监控功能的重要性。良好的异常处理机制应该在用户友好性和开发者可观测性之间取得平衡。