阻止 IntentService 创建
我的应用程序从 IntentService 进行 Web 服务调用。每个 Intent 实际上都是需要进行的 Web 服务调用。
如您所知，IntentService 对 Intent 进行排队；因此在任何给定时间只会发生 1 个 Web 服务调用。这实际上是期望的行为。
然而，这确实存在一个问题。假设我的应用程序在此 IntentService 中排队了 5 个 Intent。假设用户最终看到的屏幕可能会显示 UI，同时从 Web 服务检索一些数据。如果此 Web 服务的 Intent 被放在队列的后面，则可能需要很长时间才能调用 Web 服务，从而使用户等待一段不可接受的时间。
由于我无法将 Intent 注入 IntentService 队列的前面（据我所知），因此我决定为需要立即执行的调用创建第二个 IntentService。由于我只希望在任何给定时间有 1 个调用访问我的服务，因此我在实际的 Http 代码周围封装了一个互斥体。因此，在这种情况下，Intent 将立即执行（因为它位于不同的 IntentService 中），但会在互斥体上循环，直到其他 IntentService 中的任何调用完成。
这对我来说很有用；我对这一切都很好。
这是我的问题：
理论上，新的 IntentService 也可以排队。由于应用程序工作流程的原因，这种情况不太可能发生，但理论上是可能的。如果是这种情况，我希望新的 IntentService 在原始 IntentService 再次恢复之前完成。我的想法是在新 IntentService 的创建和销毁方法中锁定/解锁新的互斥体。同样的互斥锁也会在旧 IntentService 的 onHandleIntent 方法的开头和结尾处被锁定/解锁。但是，我担心在创建 IntentService 时锁定互斥体会产生什么后果，从而阻止其创建（大概， super.create 将在锁定之前被调用）。 Intent还能排队吗？这样做还有其他陷阱吗？
My application makes its web service calls from an IntentService. Each Intent is effectively a web service call that needs to take place.
As you know, an IntentService queues Intents; so only 1 web service call will be taking place at any given time. This is actually desired behavior.
However, this does present a problem. Suppose my app queues up 5 Intents in this IntentService. Say the user ends up on a screen that maybe holds up the UI while some data is retrieved from a web service. If the Intent for this web service is put on the back of the queue, it could be a long while before the web service is called, holding the user up for an unacceptable amount of time.
Since I can't inject Intents to the front of an IntentService's queue (as far as I know), I've decided to create a second IntentService for calls that require immediate execution. Since I only want 1 call hitting my services at any given time, I've wrapped a mutex around the actual Http code. So, in this case, the Intent would execute right away (because it's in a different IntentService), but loop on the mutex until whatever call in the other IntentService is finished.
This works good for me; I'm fine with all of it.
Here is my question:
Theoretically, the new IntentService could queue up, too. Because of the application workflow, this is unlikely to happen, but it's theoretically possible. If this is the case, I'd like the new IntentService to finish before the original IntentService resumes again. My idea for doing this is locking/unlocking a new mutex in the create and destroy methods of the new IntentService. The same mutex will also be locked/unlocked at the beginning and end of the onHandleIntent method of the old IntentService. However, I'm concerned about what ramifications locking a mutex in the create of an IntentService will have, holding up its creation (presumably, super.create will be called before the lock). Will Intents still be able to queue up? Are there any other pitfalls to doing this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不能使用标准实现。然而，
IntentService并不是一个大类。您可以克隆它并用PriorityBlockingQueue替换它目前使用的基于Handler的系统。除了可能出现的僵局之外，这还把我吓坏了？
您可以查看
ReentrantReadWriteLock或类似的东西，而不是Mutex对。虽然从技术上讲，您的情况不是“读”与“写”的情况，但您可以将“读”和“写”简单地视为两个优先级。有多种方法可以配置此类锁以支持“写入”，因此您的第二个IntentService将是“写入”，而您的第一个IntentService将是“读取”。但我真的希望用具有您所寻求的特性的类似工具来替换 IntentService，而不是尝试让两个 IntentServices 一起工作。
Not with the standard implementation. However,
IntentServiceis not a big class. You could clone it and replace theHandler-based system it uses today with aPriorityBlockingQueue.Besides it scaring the crap out of me, in terms of possible deadlocks?
You might look at
ReentrantReadWriteLockor something along those lines, instead of theMutexpair. While technically yours is not a "read" vs. "write" scenario, you can think of "read" and "write" as simply being two priorities. There are ways to configure such a lock to favor "writes", so your 2ndIntentServicewould be the "write" and your 1stIntentServicewould be the "read".But I'd really look to replace
IntentServicewith a workalike that has the characteristics you seek, rather than trying to get twoIntentServicesto work together.