1

我们有一个网络客户端应用程序，我们正在尝试验证我们处理来自服务器的响应以及设备轮换的方法。本质上，我们这样做，

  1. 活动为网络响应注册一个接收器
  2. 活动通过启动意图服务来启动网络操作
  3. 服务通过广播它完成的意图来响应

我们（感知到的）问题是，当设备旋转时，活动被销毁/重新创建。在 Activity 的接收器未注册onPause()和重新注册之间的这段时间内onResume()，我们可能错过了服务广播的意图。

这是一个真正的问题吗？

如果是这样，我们假设了以下解决方案，

  1. 首先，不要使用意图在活动和服务之间进行通信
  2. 创建两个阻塞队列：应用程序类中的网络请求和响应
  3. 服务启动take()来自请求队列的线程
  4. 活动启动一个take()来自响应队列的线程
  5. offer()当它想要开始网络操作时，活动的请求队列
  6. 发布网络操作的结果时服务offer()到响应队列
4

1 回答 1

0

是的，这可能在极少数情况下发生，但如果用户接到电话，它肯定会发生。同样，您的活动将暂停然后恢复，如果用户长时间交谈，您的活动将从服务中丢失一堆广播。

我的建议是，在需要立即注意来自服务等组件的响应的情况下，您不能使用广播在应用程序之间进行双向通信。您将使用什么机制取决于具体情况。在我最新的项目中，我使用服务来更新应用程序小部件，在这种情况下，我在服务中使用静态代码来执行一些查询或请求一些操作。

你的想法听起来不错，但它可能隐藏了一个复杂的实现，如果我处于你的位置，我会考虑使用名为Bound Services的内置服务机制。到目前为止我还没有使用它，但它似乎可以满足您的需求。

编辑

因此，基于绑定服务的概念，我提出了以下流程：

  1. 活动启动，即所谓的粘性服务。
  2. 服务为网络响应注册接收器。
  3. 服务根据网络响应维护一个带有所需信息的 Ibinder 对象。
  4. Activity 会在需要时绑定到服务，并使用信息检索 Ibinder 对象并执行所需的操作。
  5. 当该结束应用程序时，Activity 会停止服务并自行完成。

希望这可以帮助...

于 2012-05-10T01:42:55.193 回答