Android BroadcastReceiver 还是简单的回调方法？

Question

在我的项目中，我使用 BroadcastReceiver s 作为来自长时间运行的线程的回调(例如，通知 Activity 下载已完成并从 Worker Thread 发送一些响应数据，以便 Activity 可以向用户显示适当的消息......)。
使用 BroadcastReceiver每次使用广播接收器时，我都必须小心注册和取消注册广播接收器，并且当我使用此方法执行更多不同的操作(例如下载、进行 WebService 调用等)时，还必须注意要发送的特殊消息。 )。并且还要通过广播的 Intent 发送自定义对象，我还需要制作对象 Parcelable .

与这种方法不同，我还看到了回调方法方法，它似乎比我使用的方法更简单。回调方法是简单的接口(interface)方法实现，可用于实现与应用程序消息传递中的 BroadcastRecaiver 相同的效果。
这种方法不需要 Parcelable 实现来返回复杂的对象，也不需要像 BroadcastReceiver 这样的键。 ..我认为不好的部分是在我想调用回调方法之前我需要检查回调对象的空值..还要确保我在UI线程上运行代码以便我可以更新UI 没有错误。

好的，我希望你明白我的意思:)。

现在的问题是您是否认为回调方法比 BroadcastReceiver 更好(更轻、更干净、更快......)方法何时仅在单个应用程序内部使用？ (请注意，我没有使用 Android Service 进行后台工作......只是 AsyncTask 和 Thread s)

谢谢!

Answer 1

这是一个非常有趣的问题，我遇到了同样的问题。在我看来，这两种机制都可以一起使用，正确的使用方法取决于您的用例。以下是在决定之前需要考虑的一些要点。

使用回调机制有一些好处，但也有局限性:

专业版

实现起来简单直接。

您可以在相互交互的组件之间获得类型安全。

您可以返回任意对象。

它简化了测试，因为您只需要在单元测试中注入(inject)一个模拟回调(例如通过 mockito 或类似的东西生成)。

违禁品

您必须切换到主线程才能进行 UI 操作。

您只能拥有一对一的关系。没有进一步的工作，就无法实现 1 对 n 的关系(观察者模式)。在这种情况下，我更喜欢 Android 的 Observer/Observable机制。

正如您已经说过的，您必须始终检查 null如果回调可能是可选的，则在调用回调函数之前。

如果你的组件应该提供一种具有不同服务功能的服务 API，而你又不想有一个只有少数通用回调函数的回调接口(interface)，你必须决定是为每个服务功能提供一个特殊的回调接口(interface)，还是提供一个带有大量回调函数的回调接口(interface)。在后一种情况下，用于 API 服务调用的所有回调客户端都必须实现完整的回调接口(interface)，尽管大多数方法主体将为空。您可以通过实现具有空主体的 stub 来解决此问题，并使您的回调客户端从该 stub 继承，但如果已经从另一个基类继承，则这是不可能的。也许您可以使用某种动态代理回调(请参阅 http://developer.android.com/reference/java/lang/reflect/Proxy.html )，但随后它变得非常复杂，我会考虑使用另一种机制。

如果服务调用者不能直接访问回调调用的客户端，则必须通过各种方法/组件进行传播。

关于 BroadcastReceiver 的一些要点-方法:

专业版

您实现了组件之间的松散耦合。

您可以拥有 1 对 n 的关系(包括 1 对 0)。

onReceive()方法总是在主线程上执行。

您可以通知整个应用程序中的组件，因此通信组件不必“看到”彼此。

违禁品

这是一种非常通用的方法，因此对 Intent 传输的数据进行编码和解码。是一个额外的错误源。

你必须让你的Intent如果您想消除与其他应用程序的关联，那么 的操作是唯一的(例如，通过在包名称前面加上)，因为它们的原始目的是在应用程序之间进行广播。

您必须管理BroadcastReceiver -注册和注销。如果您想以更舒适的方式执行此操作，您可以实现自定义注释，以使用应注册的操作来注释您的 Activity 并实现基础 Activity使用 IntentFilter 进行注册和注销的类s 在其 onResume()分别onPause()方法。

正如您已经说过的，与 Intent 一起发送的数据必须实现 Parcelable接口(interface)，但此外还有严格的大小限制，如果您使用 Intent 传输大量数据会导致性能问题。 .见 http://code.google.com/p/android/issues/detail?id=5878对此进行讨论。因此，例如，如果您想发送图像，您必须将它们临时存储在存储库中，并发送相应的 ID 或 URL 以从您的 Intent 的接收者访问图像。使用后将其从存储库中删除。如果有多个接收器，这会导致进一步的问题(何时应该从存储库中删除图像，谁应该这样做？)。

如果您过度使用这种通知机制，您的应用程序的控制流可能会被隐藏，并且在调试时您最终会绘制带有 Intent 序列的图形。 s 了解是什么触发了特定错误或为什么此通知链在某个时候被破坏。

在我看来，即使是移动应用程序也应该具有基于至少 2 层的架构:UI 层和核心层(包含业务逻辑等)。通常，长时间运行的任务在核心层内的一个自己的线程中执行(可能通过 AsyncTask 或 HandlerThread，如果使用 MessageQueue s)，一旦该任务完成，UI 应该更新。通常，通过回调，您可以实现组件之间的紧密耦合，因此我更喜欢仅在层内使用这种方法，而不是跨层边界进行通信。对于 UI 层和核心层之间的消息广播，我将使用 BroadcastReceiver - 使您可以将 UI 层与逻辑层分离的方法。