我的应用程序从IntentService进行Web服务调用。每个Intent实际上都是需要进行的Web服务调用。
如您所知，IntentService将Intents排队;因此，在任何给定时间只会进行一次Web服务呼叫。这实际上是期望的行为。
然而，这确实存在问题。假设我的应用程序在此IntentService中排队5个Intent。假设用户最终屏幕可能会占用UI，同时从Web服务检索一些数据。如果此Web服务的Intent放在队列的后面，则可能需要很长时间才能调用Web服务，从而使用户保持不可接受的时间。
由于我无法将Intent注入IntentService队列的前端（据我所知），我决定为需要立即执行的调用创建第二个IntentService。由于我只想在任何给定时间拨打我的服务，所以我在实际的Http代码周围包含了一个互斥锁。因此，在这种情况下，Intent会立即执行（因为它位于不同的IntentService中），但是在互斥锁上循环，直到其他IntentService中的任何调用完成。
这对我有好处;我对所有这些都很好。
这是我的问题：
理论上，新的IntentService也可以排队。由于应用程序工作流程，这不太可能发生，但理论上可行。如果是这种情况，我希望新的IntentService在原始IntentService再次恢复之前完成。我这样做的想法是在新的IntentService的create和destroy方法中锁定/解锁一个新的互斥锁。同样的互斥锁也将在旧的IntentService的onHandleIntent方法的开头和结尾处被锁定/解锁。但是，我担心在创建IntentService时会锁定互斥锁会产生什么后果，从而阻止其创建（可能会在锁定之前调用super.create）。意图仍然可以排队吗？这样做还有其他陷阱吗？
答案 0 :(得分：0)
因为我无法将Intent注入到IntentService队列的前面（据我所知）
不符合标准实施。但是，IntentService并不是一个大课程。您可以克隆它，并将其今天使用的基于Handler的系统替换为PriorityBlockingQueue。
这样做还有其他陷阱吗？
除了在可能的死锁方面吓跑了我之外？
您可能会看到ReentrantReadWriteLock或其他内容，而不是Mutex对。虽然从技术上讲，你的不是“阅读”与“写”情景，但你可以把“阅读”和“写作”视为两个优先事项。有一些方法可以配置这样的锁以支持“写入”，因此您的第二个IntentService将是“写入”，而您的第一个IntentService将是“读取”。
但我真的希望将IntentService替换为具有您所寻求的特征的工作方式，而不是试图让两个IntentServices一起工作。