There are a few exceptions. First, let's distinguish between a service which continuously runs, vs one for which there is a continuing need.
You NEVER want a service to be continually running, or even frequently running. You'd even strongly prefer to not have it maintain a process. My own app does so, but reluctantly, because there's no other way to provide the user with the feature. You can start a service, and make it sticky, so that it can be killed in low memory situations, but recreated when memory is available. If the service responds to events, or periodic timers that are not too frequent, the impact is non-zero, more than you'd like, but often better than not having the service. Even so, it's not free. The fact that your service is there, means some other service the user values more may be killed instead of yours. One reason to split client and service is to allow for multiple clients sharing a service. Unfortunately, the Market doesn't really support doing this well. But the clients from the same vendor as the service could still share that address space if there's no strong security reason not to. Another reason to do this would be memory management -- if the client really stresses memory management in a way that results in fragmentation, you could benefit from allowing it to be completely killed, and separate from the service. I think that would be an unusual case -- one that you should test and verify carefully, rather than on some theory it might be helpful. And a future version of the system is likely to make that less of an issue, I'm told. As Mark points out, that has to be weighed against actually INCREASING the peak memory requirement. I don't know anybody that does that, or needs to -- so far, that's a theoretical point. Another reason for multiple processes is to get past the memory limitations of a single app. I don't know of anybody that does this, except my as-yet-unfinished memory-stress tool! Finally, you may want to consider going the other way -- allowing multiple of your applications to share the same process. I do that with my free and pro versions. (Pro not yet released, if you're wondering). On Apr 12, 5:21 pm, Mark Murphy <mmur...@commonsware.com> wrote: > Michael Elsd rfer wrote: > > I have a service that runs continuously. > > Please try to avoid that. This is why users attack us with task killers. > > http://www.androidguys.com/2009/09/09/diamonds-are-forever-services-a...http://www.androidguys.com/2010/03/29/code-pollution-background-control/ > > > Is there actually any gain here? if Android frees the memory of > > finished Activities anyway, is there any benefit to using a separate > > process, or is it maybe making things worse, even? > > While the client is up, two processes will make things worse. > > > I can't help but notice that no other app seems to use a remote > > process, including builtin one's like Google Talk or the Music Player. > > I'm I correct in assuming that this is the recommended approach then? > > Avoiding multiple processes is right up there with avoiding everlasting > services -- in this case, avoidance is a good thing. :-) > > -- > Mark Murphy (a Commons > Guy)http://commonsware.com|http://twitter.com/commonsguy > > Android Training...At Your Office:http://commonsware.com/training -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
