CODEWITHSUNDEEP
androidservice
user496854
user496854

Reputation: 6810

Questions about services running on the UI thread in Android

I've read in a few places that services run on the UI thread (and can block it), but I'm not sure exactly how that works. My service has no need to interact with the UI, but I do need to be able to process concurrent requests from activities, so I can't use the IntentService. So I had a few questions:

  1. If the service was started from within a thread, would it still block the UI?

  2. If all the work inside the service is done inside a thread, would it still block the UI?

  3. How does this work if I have multiple activities sending data to the same service? For example, activity A initially runs startService(), which starts the service and makes it do a bunch of work. While the service is running, acrivity B needs to send more work to the service, so it runs anorhter startService(). So, the same service instance will be processing intents from both activities, but do each of them get affected by that service? Does each activity run the risk of the UI being blocked, even though the service was originally started inside activity A?

  4. Is there anything like an IntentService that runs 'outside' of the UI, but can handle asynchronous input instead of waiting for one intent to finish before starting another?

Upvotes: 2

Views: 1033

Answers (1)

Larry Schiefer
Larry Schiefer

Reputation: 15775

My service has no need to interact with the UI, but I do need to be able to process concurrent requests from activities, so I can't use the IntentService.

Actually, this sounds exactly like what you'd want to use IntentService to do.

If the service was started from within a thread, would it still block the UI?

Yes, where you start the service from does not matter. What is meant by the service running in the same thread as the UI is the callback entry points for the service (i.e. onCreate, onDestroy, onBind, etc.) These are always run in the main thread of your app.

If all the work inside the service is done inside a thread, would it still block the UI?

No, in fact this is the recommended approach. IntentService simplifies this for you by automatically creating a worker thread for you and handing the Intent(s) to the thread to handle. You could accomplish the same thing if you used your own thread pool and queued them up with however many Intents are coming in. Note that you'd have to be careful not to create too many threads in the pool so you may overwhelm the system.

How does this work if I have multiple activities sending data to the same service? For example, activity A initially runs startService(), which starts the service and makes it do a bunch of work. While the service is running, acrivity B needs to send more work to the service, so it runs anorhter startService(). So, the same service instance will be processing intents from both activities, but do each of them get affected by that service? Does each activity run the risk of the UI being blocked, even though the service was originally started inside activity A?

I think this may be part of the confusion. The service runs in the main thread of the process belonging to the service's package. Activities from other packages are not blocked unless for some reason they are specifically waiting for some type of reply, etc. Intents are essentially inter-process communication (IPC) messages which ride on top of special IBinder plumbing managed by the framework. The Intent is sent across a binder and queued to an internal handler and ultimately used by the framework to call your Activity/Service/BroadcastReceiver at the appropriate callback.

Is there anything like an IntentService that runs 'outside' of the UI, but can handle asynchronous input instead of waiting for one intent to finish before starting another?

No, not out of the box. But, as I mentioned above, you could do this with a thread pool or even using AsyncTask. Just remember that you must manage the threads and AsyncTask objects with respect to your service's life cycle as these things are not lifecycle aware.

Upvotes: 11

Related Questions