阻碍IntentService的创建

Question

我的应用程序从IntentService调用它的web服务。每个意图实际上都是一个需要发生的web服务调用。

正如您所知道的，IntentService会对意图进行排队；因此，在任何给定的时间，只会发生一次web服务调用。这实际上是所需的行为。

然而，这确实带来了一个问题。假设我的应用程序在这个IntentService中排队了5个意图。假设用户最终出现在一个屏幕上，当从web服务检索某些数据时，该屏幕可能会占用UI。如果此web服务的意图被放在队列的后面，则可能需要很长一段时间才能调用web服务，从而使用户等待一段不可接受的时间。

由于我不能将意图注入到IntentService队列的前面(据我所知)，我决定为需要立即执行的调用创建第二个IntentService。因为我希望在任何给定的时间只有一个调用命中我的服务，所以我在实际的Http代码周围包装了一个互斥锁。因此，在这种情况下，意图将立即执行(因为它在不同的IntentService中)，但在互斥锁上循环，直到另一个IntentService中的任何调用完成。

这对我来说很好；我对所有这些都很满意。

这是我的问题：

从理论上讲，新的IntentService也可以排队。由于应用程序工作流的原因，这不太可能发生，但在理论上是可能的。如果是这样的话，我希望新的IntentService在原来的IntentService再次恢复之前完成。我的想法是在新IntentService的create和destroy方法中锁定/解锁一个新的互斥锁。在旧IntentService的onHandleIntent方法的开头和结尾，相同的互斥锁也会被锁定/解锁。然而，我关心的是在创建IntentService时锁定互斥锁会有什么后果，从而阻碍它的创建(假设在锁之前调用super.create )。Intents还能排队吗？这样做还有其他的陷阱吗？

Answer 1

，因为我不能将意图注入到IntentService队列的前面(据我所知)

而不是使用标准实现。然而，IntentService不是一个很大的类。您可以克隆它，并用PriorityBlockingQueue替换它现在使用的Handler-based系统。

这样做还有其他的陷阱吗？

除了在可能的死锁方面吓到我之外？

您可能会关注ReentrantReadWriteLock或类似的东西，而不是Mutex对。虽然从技术上讲，您的方案不是“读”与“写”的场景，但您可以将“读”和“写”看作是两个优先级。有一些方法可以配置这样的锁来支持“写”，所以你的第二个IntentService将是“写”，而你的第一个IntentService将是“读”。

但我真的希望用一个具有你所寻求的特性的相似的工具来取代IntentService，而不是试图让两个IntentServices一起工作。