3

Does anybody know how big the overhead for services in Android is.
And if there are any other argument helping me with the following design decision.

I have two SQLite Dbs, one storing actual data (basically read only product inventory), the other storing settings, lists of selected items, etc.

Now I created a service to take care of manageing these databases, for two main reasons:

  • I want to be able to "save on close" (settings), which is possible with the onDestroy
  • It takes some time to load the data, so a quick close of the app keeps the data in memory

From a design perspective, I could either:

  • Create one service handling both DBs
  • Create two services, each handling one DB

It feels cleaner to create a seperate service for each DB, e.g. extending a generic base class to take care of shutdown, timers, etc. It also allows me to configure them independent (which is NOT required right now).

On the other hand, I do not want to start going down this road, and then, when I am used to doing stuff like this in "services" discovering that there is a limit of 3 or 5 services.

So how is the Overhead of e.g. 5 running services, vs. one service hosting 5 different features? Any ideas?

Christian Ruppert
  • 3,749
  • 5
  • 47
  • 72

3 Answers3

1

From the Android dev docs...

Use services sparingly

http://developer.android.com/training/articles/memory.html#Services

user3829751
  • 712
  • 7
  • 20
1

The number of services effectively supported by Android should be nothing to worry about in your situation. Having seen lists of running services in some task managers, I tend to say that up to ~100 "running" services should be no problem on most devices.

However, I'm not sure if what you're trying to do actually should be implemented in a service. Can you elaborate why you think you need a service?

I want to be able to "save on close" (settings), which is possible with the onDestroy

Can't you do this in your normal Activity lifecycle callbacks?

It takes some time to load the data, so a quick close of the app keeps the data in memory

What do you mean by "quick close"? Are you trying to build some sort of cache for the DB data?

JimmyB
  • 12,101
  • 2
  • 28
  • 44
  • Thanks for your feedback. Regarding A - no, I dont want to save on each activity-switch. Only on "applicationExit", and there is nothing like this in the ApplicationClass (onTerminate only applies to emulator). – Christian Ruppert Nov 11 '11 at 18:28
  • Regarding B, its a nice side effect of using a service. Even if the App gets killed, the service can hold on to the objects a little bit longer (and terminate itself after e.g. 30 min of non usage) - but dont worry, my main motivation is A - saving at exit, not page switch. – Christian Ruppert Nov 11 '11 at 18:30
  • Ok, in that case, it seems to me that a service is probably the only viable way to reliably be notified of an application's death. (I don't see a.t.m. why Android does not provide a corresponding callback; didn't bother to further investigate, though.) You probably want to *bind* to the service so the service will be implicitly destroyed once the (last) binding client goes away. - I just found [this](http://stackoverflow.com/questions/7236782/is-an-android-service-guaranteed-to-call-ondestroy) about *onDestroy()* of a service... Seems like its not too easy to do what you want. – JimmyB Nov 11 '11 at 19:47
  • WTF....Damn and I thought I had it. Why the heck don't they provide a simple "onDestroy" callback. I dont want to save on every page switch! Damn damn damn... Well I can do it now (have the infrastructure in place anyway, but still)... Well, offtopic. Thanks for your answer and the link! – Christian Ruppert Nov 15 '11 at 13:25
  • Welcome. And don't let them upset you too much :) – JimmyB Nov 15 '11 at 18:07
0

If services are RemoteServices then they are launched in a separate process which add overhead and is memory intensive.

Try using a single service for both the scenarios.

Rajdeep Dua
  • 11,190
  • 2
  • 32
  • 22