如何通过运行时异常处理孤立的待处理意图答案

【问题标题】：how to handle orphaned pending intent by runtime exception如何通过运行时异常处理孤立的待处理意图
【发布时间】：2015-07-24 20:25:20
【问题描述】：

您好，我想就我遇到的问题提出一个问题。

涉及到：

活动生命周期，由待处理意图触发的接收器（由警报生成）和运行时异常。

假设我得到了：

注册了启动 IntentService 的 BroadcastReceiver
通过警报设置待定意图以调用 BroadcastReceiver

例如抛出运行时异常的部分Activity类代码（这里仅展示中断的活动生命周期流程和运行时异常的想法）：

@Override 
 protected void onCreate(Bundle savedInstanceState) {     
     super.onCreate(savedInstanceState); 
     if(true) { throw new RuntimeException("EXC"); 
 }

@Override 
protected void onStop() {

     // here we stop alarm or unregister receiver 
}

我的观察：

在引发异常后，活动生命周期的正常流程被破坏并且 ART 正在重新创建“堆栈”
在这种情况下无法取消警报！在设备重新启动之前仍然存在，因此会生成挂起的意图，但它没有像正常的不间断流程中那样满足“开始条件”
BroadcastReceiver 一直处于活动状态（已注册）而不管运行时异常，因此它正在触发 IntentService，该异常会生成非预期的空指针异常

问题：

保证在抛出异常后取消注册接收器/停用孤立的待处理意图（由警报产生？）以避免调用意图服务并产生进一步异常的最佳方法，因为正如我提到的那样，android 活动生命周期被中断，所以它是不通过 onPause/onStop 方法，通常我用它来注销接收器/停止警报/待定意图

我想到了什么想法（解决方案）：

实现 Thread.UncaughtExceptionHandler 取消注册接收器/停止警报???

编辑：

经过一番挖掘：

UncaughtExceptionHandler 有两种设置方式：
- 第一个适用于单个线程的“setUncaughtExceptionHandler”
- VM 中所有线程的第二个“setDefaultUncaughtExceptionHandler”。
应用程序框架已经提供了一个全局未捕获异常处理程序。此处生成带有“AndroidRuntime”标签的异常跟踪，然后杀死VM：
- 参见 frameworks/base/core/java/com/android/internal/os/RuntimeInit.java。
未捕获的异常优先
- 由每个线程处理程序处理，
- 然后是每个线程组的处理程序，
- 然后由全局处理程序。

当我在内存中有一些半死不活的东西时，我有两个选择：

关闭虚拟机，
或在碰撞后倾斜并停止，大概是通过使用“finally”块来确保一切都得到妥善处理。

如果我指定全局似乎很难管理，我将为所有线程覆盖应用程序框架的行为。

【问题讨论】：

标签： android alarm android-pendingintent runtimeexception

【解决方案1】：

您应该尽可能健壮地编写代码。这意味着您不应该在存在运行时异常的情况下尝试清理，因为您永远不会填补所有空白。您需要做的是添加健全性检查：

您的IntentService - 它应该在启动时检查所有条件是否正确。
您的BroadcastReceiver - 在调用onReceive() 时应检查所有条件是否正确。

如果您像这样编写代码，则无需担心确保在所有错误情况下都正确清理。

【讨论】：