One thing that has annoyed me for the longest time now is this myth that multitasking somehow reduces battery life. The iPhone multitasks today, it just doesn’t allow multiple third party apps to run concurrently.
I’ve written a lot of software, both application and system level (right down to the lowest levels of an RTOS), and believe me, if it is written properly a background app does little or no harm to battery life.
Many of the applications that people would like to see running in the background would spend almost all of that time waiting for a system event. That waiting state doesn’t harm your battery life; only when the application is actually processing something does it really consume power. The push mechanism on the iPhone today might actually be worse since it has to load the app each time, a far more expensive operation (in CPU, and therefore battery) than just switching to one that is already “running.”
Consider the IM app example that is so often used to support the claim that background apps kill battery life. Sure, if you run the IM app (background or foreground) and stream messages at it continually, then it will reduce the battery life. If you just have it sitting there in case somebody tries to start a session though it isn’t doing anything most of the time (occasional presence messages perhaps). I ran an IM app all the time on my Nokia N95, connected over AT&T’s network 24/7. My battery life was unaffected, as expected.
Another example of a well behaved background app is the daemon that we wrote for the jailbroken version of Devicescape’s app (before the SDK and app store existed). It made no difference to battery life because it spent almost all the time blocked waiting for a system event. One that only happened when a new Wi-Fi connection was made. We run in the background on Nokia, Windows Mobile and Android (not to mention Windows XP/Vista/7 and Mac OS X) today without impacting battery life.
So what will affect battery life? Well, an app that continues to do something in the background, rather than waiting for an event, one that polls for an event rather than blocking until the OS tells it about the event, or one that requires a power-hungry piece of the hardware to be on all the time (e.g. GPS). But even those apps have their place. Imagine a background image uploader: it will do something in the background while it is needed, and then exit or wait for a new photo to be taken. Or an app that checks your location every 5 minutes. It is my choice to use the battery that way, so why restrict it? Just make sure it is reasonable for the application, explained to the user, and under my control (can be checked as part of the review process).
These types of apps don’t take any more power than they would if I left them running in the foreground, but letting me push them to the background allows me to choose if I want to watch them work, or read my email etc.
Above all, please stop spreading this myth that multitasking or background processes will harm battery life. Only badly written apps would do that.
You expect rumor-central (the folks who insinuate, but don’t dare to actually claim, that Macs are immune to viruses) to stop generating rumors? What would they do with that multi-million-man-hours rumor generator if they did? Turn it into a useful background app?
Isn’t is so that background apps consume battery also because of their memory usage? So even if the app is not using CPU, it still drains battery, because part of RAM where the app is stored can not be powered off to save battery life?
Just noticed my Wifi on the Android will poll for networks every 30 seconds. Does that use battery life?