阻止 IntentService 创建

Question

我的应用程序从 IntentService 调用其 Web 服务。每个 Intent 实际上都是一个需要进行的 Web 服务调用。

如您所知，IntentService 将 Intent 排队；因此在任何给定时间只会发生 1 个 Web 服务调用。这实际上是期望的行为。

但是，这确实存在问题。假设我的应用在这个 IntentService 中排队了 5 个 Intent。假设用户最终停留在一个屏幕上，该屏幕可能会在从 Web 服务检索一些数据时支撑 UI。如果此 Web 服务的 Intent 放在队列的后面，则可能需要很长时间才能调用 Web 服务，从而使用户等待不可接受的时间。

由于我无法将 Intent 注入到 IntentService 队列的前面（据我所知），因此我决定为需要立即执行的调用创建第二个 IntentService。由于我只希望在任何给定时间有 1 个调用访问我的服务，因此我在实际的 Http 代码周围包裹了一个互斥锁。因此，在这种情况下，Intent 会立即执行（因为它位于不同的 IntentService 中），但会在互斥体上循环，直到其他 IntentService 中的任何调用完成。

这对我很有用；我对这一切都很好。

这是我的问题：

理论上，新的 IntentService 也可以排队。由于应用程序工作流程，这不太可能发生，但理论上是可能的。如果是这种情况，我希望新的 IntentService 在原始 IntentService 再次恢复之前完成。我这样做的想法是在新 IntentService 的创建和销毁方法中锁定/解锁新的互斥锁。相同的互斥体也将在旧 IntentService 的 onHandleIntent 方法的开头和结尾处被锁定/解锁。但是，我担心在创建 IntentService 时锁定互斥锁会产生什么后果，从而阻止它的创建（可能会在锁定之前调用 super.create）。 Intents 还能排队吗？这样做还有其他陷阱吗？

Answer 1

因为我无法将 Intent 注入到 IntentService 队列的前面（据我所知）

不适用于标准实现。但是，IntentService 并不是一个大类。您可以克隆它并将它现在使用的基于Handler 的系统替换为PriorityBlockingQueue。

这样做还有其他陷阱吗？

除了把我吓坏之外，就可能的死锁而言？

您可能会查看ReentrantReadWriteLock 或类似的东西，而不是Mutex 对。虽然从技术上讲，您的情况不是“读取”与“写入”方案，但您可以将“读取”和“写入”视为两个优先事项。有多种方法可以配置这样的锁以支持“写入”，因此您的第二个 IntentService 将是“写入”，而您的第一个 IntentService 将是“读取”。

但我真的希望将 IntentService 替换为具有您所寻求的特征的类似工作，而不是试图让两个 IntentServices 一起工作。