android - 使用自定义 UncaughtExceptionHandler 处理 Firebase 崩溃报告和自定义应用程序类

Question

我的 Android 应用目前使用自定义 UncaughtExceptionHandler，旨在捕获任何崩溃，并在手动调用 之前使用 AlarmManager 安排应用在未来几秒钟重启>Process.killProcess(Process.myPid()) 以避免在我的应用程序用例中出现 Android 的强制关闭弹出窗口，用户将无法与设备交互以点击 FC 对话框上的“确定”并重新启动应用程序。

现在，我想与 Firebase 崩溃报告集成，但我担心错误的行为，所以这是我的问题:

1. 我应该如何编写代码，以便我的自定义 UncaughtExceptionHandler 在终止进程之前将异常传递给 Firebase 崩溃报告？调用 Thread.getDefaultUncaughtExceptionHandler() 会给我 Firebase 崩溃报告 UncaughtExceptionHandler 以便我可以调用 uncaughtException(...) 吗？
2. 可以 Process.killProcess(Process.myPid()) 阻止 Firebase 崩溃报告库进行报告工作吗？ Firebase 会在 uncaughtException(...) 返回之前在一个单独的进程中启动它的崩溃报告吗？ Firebase 是否拥有 UncaughtExceptionHandler 回调 Android 默认的 UncaughtExceptionHandler，显示 FC 对话框？
3. 除了默认进程之外，Process.killProcess(Process.myPid()) 是否可以终止 Firebase 崩溃报告进程？
4. 我的自定义 Application 类如何检测它是否在 Firebase 崩溃报告过程中被实例化？以相同方式处理这两个进程可能会导致不一致的状态。

感谢任何试图帮助我的人!

Answer 1

如果您在异常处理程序中终止进程，您将无法接收到崩溃。它将干扰为即时或延迟传输持续崩溃的能力。它可能会干扰任何已注册表现良好的未捕获异常处理程序的库。

事实上，Process.killProcess(Process.myPid()) 是一个 anti-pattern用于安卓开发。如果托管应用程序的进程，Android 应用程序根本不应该关心整个生命周期。 Android 为您管理流程这一事实是为了用户的利益而设计的优化。

对于应用中未捕获的异常，我强烈建议让应用像往常一样死掉。掩盖崩溃的适当影响就像扫地毯下的污垢一样。您可能正在解决一个短期问题，但真正需要发生的是正常记录和处理错误，以便您可以修复它。

不要依赖于 Firebase 崩溃报告在另一个进程中传输异常这一事实。其他进程将在完整的非测试版中删除。

您的 Application 子类的最佳情况是完全不依赖于它正在运行的进程。事实上，Google 的 Android 团队根本不推荐使用 Application 子类，因为它只会给多进程应用带来麻烦。如果您必须使用 Application 子类，它应该期望在多个进程中运行。