> Example: <suchandsuchapp>crond_service.. CROND service? This is what > the alarm manager is for, doing a repeated task every so often. If you > are consuming memory being in the background all the time, when you > could simply invoke the alarm_manager to wake you every so often, that > is much better for performance and battery.
I don't know the corresponding app. But who tells you the service is actually doing something all the time? It might as well be a service that only does some background work whenever it's been triggered by some Intent (including those sent by alarm manager) and then sleeps in the background... I've got similar "problems" since I respond to media mount/dismount in my audio player. Since peekService returns null in 95% of all cases, no matter whether the service is running or not, I have to forward the information with startService. If no work is necessary, I do nothing and call stopSelf. But now app and service are in memory and people ask me why I start the app when the device is booted (the SD is mounted immediately afterwards, and thus the Intent is broadcast...). I'm afraid as long as people don't understand the difference between "running" and "in memory", task managers as well as the "running services" information just cause confusion. > The fact that devs aren't using the APIs correctly and using > background services for EVERYTHING is part of the reason why smart > people who have 75% of a clue are telling the tech blog writers that a > task killer is a "necessary part of the Android experience". I think the main reason is that they just don't get Androids handling and assume it's like Windows, where even the most unnecessary task gets CPU time. Of course badly programmed services make it worse, but that goes even when a task manager is used. If you do too much as response to an alarm manager, the effect is the same. Besides, the service which often slows down the system the most is the media scanner. And there's not much to avoid that... > Obviously the solution isn't to eliminate task killers. One possible > solution is to contact the authors of the most prominent task killers > and get them to try to change their UI to highlight "top resource > consuming tasks" as opposed to emphasizing the "kill all" button. And what's wrong with "resource consuming"? I coud cache several MB of data in a non-running service, it wouldn't matter. Android would just kick it if the memory's required, and the service would just reload the data when it's restarted. It's similar with CPU usage. If your service happens to do something in the instance the task killer loads it, it'll be killed, even if it only does that on certain events or once a day? And some services just need to do more than others... Besides, most task managers only show the main application, not the service. So CPU usage alway is 0, and memory usage, as said, doesn't really matter. > Another part of the puzzle is educating the iditions, I'm afraid that's pretty hopeless... > They can't kill your service if it's not running and is > triggered by AlarmManager. With some task managers, they can: it might still be in memory, even if "stopped". But it would have no big effect in that case, except onDestroy will never be invoked, which might have bad side effects in some cases. However, they can kill the service if it's actually doing something triggered by AlarmManager, and that'd be the worse case. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
