On Wed, May 9, 2012 at 4:02 PM, Kostya Vasilyev <[email protected]> wrote:
> I see your point about long running processes possibly fighting for RAM, > but restarting the process burns up the battery too (you'd previously given > a number of about 1 second to launch from Zygote to a running process... > maybe it's faster these days). > If the device isn't actively doing anything, service processes won't get killed. What happens is that after being in the started state after a certain amount of *uptime* (not including time the CPU is asleep) which I think is currently something like 30 minutes, the process drops into the background group. But it will still stay around until enough other processes have been put into the background for it to drop off the end of the list due to the out of memory killer. So if you have the power off and your device is relatively idle, these processes will get killed very infrequently, and lost in the noise... unless you do something like lots and lots of unneeded networking each time you are restarted. And if you are getting killed more frequently, then there is much more other stuff draining the battery, and again you should be mostly lost in the noise. As far as Zygote, our target for launching a new process and displaying a simple UI has always been about 200ms. We generally hit that (or do much better on faster devices), and most of that time is consumed with building and displaying the UI. Just launching a process is really fast -- it's just a fork() of zygote, bringing up the binder thread pool, attaching to the system process, and opening the app classes and instantiating and executing whatever is first being run in the process. Where launch is slow is if you aren't forking from Zygote. In that case we are talking about seconds usually. This is why commands like "adb shell am" are kind-of slow to run -- all of that delay is creating and initializing a fresh Dalvik process because "am" is written in Java. > There is, as far as I can tell, perception that just having a process > around somehow increases battery use, even if the device has plenty of free > RAM. > Yes well there is this meme spread by certain perhaps not unbiased entities that having multitasking at all, I mean doing multitasking like Android, is bad because it is intrinsically battery consuming. This is of course not true -- if you create a process and it sits there doing nothing, it ain't going to drain your battery. The difference between Android and some other platforms is that it does give background code a lot more freedom to do what they want and run when they want, so they have more freedom to do stuff that will drain your battery. Android does have some safe-guards for this -- it looks for some fairly clear signals like background processes using wake locks or CPU excessively and kills them if this happens, and a UI to help the user understand how applications are using their battery. It doesn't have such rigid control where there are only X specific types of things that can be done in the background. It's a different set of trade-offs, but background processes being intrinsically more battery draining is not one of those trade-offs. To some degree my answer to this claim would be, "well does the battery use UI show the app as actually draining the battery?". Ideally that would be the end of the story. In practice there are certain types of abusive behavior that we currently don't do a good job of measuring (such bringing up the cell radio often for very brief spurts of data) which it may miss. But it will catch a lot of common bad behavior. The perception is certainly helped by the multitude of various > system-info-management-optimizer apps, many of them being off the mark for > both memory and battery usage. > Yes these are frustrating. :p -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
