Android vs. iOS Battery-related Myths

Apple just recently introduced the new version of its mobile operating system, iOS 5. Among many enhancements that were announced, the ones that caused the most attention are definitely the new notification system and introduction of more powerful (and more complex) lock screen. Especially the notification centre resembles the system used by Android for several years (some call it a blatant rip-off) and lock screen is now also closer to what can be found on many other "smartphones".

These new features fueled somewhat dying discussions about possible introduction of still-missing "widgets" to enhance spartan Springboard home screen of iOS and the evergreen debate concerning the differences of implementation of the multitasking and the its availability for the third party developers.
The old demon of presumed better energy efficiency of the iOS implementation got a sprinkle of the fresh water and it become a popular argument of the iOS supporters once again, so perhaps it is good time to have a closer look at many myths that surround the multitasking implementation in the respective operating systems.

Widgets on iOS are definitely possible, if you don't mind jailbreak

Let's kick-off with the facts. Both iOS and Android are (relatively) modern OS, based on strong, battle tested cores (BSD Unix in the iOS case, mobile optimized Linux version for Android) running on modern, powerful hardware, that makes any form of multitasking perfectly possible. Both OS are built around multitasking and it is used by the System software.

Both systems are heavily optimized for the mobile usage. Not only the power consumption is of a big importance, there is strong focus on availability of the system resources in case of urgent need : if there is a immediate demand for the uninterrupted processor power, such as in the case of the incoming call (which is top priority to be handled without interference from whatever tasks that may be keeping the CPU busy). Both systems are very able in that regard and the entire OS metaphor is build around idea that app might exit expeditiously - in both cases there are very few states, there are no dialogs that expect the user to explicitly confirm to complete the current action, there is no "Quit" command in the menu etc.

Android engineers spent quite a lot of time optimizing the platform for the power consumption

iOS metaphor was initially designed to be very simple. There was no sense of multitasking at all, this was only introduced later, and in quite a limited form for the third party software running on iOS. Apple hype machine tried to sell this as paramount feature as being super power efficient. Developers are irresponsible idiots, the system needs to make sure no resources are wasted so only a very special, limited form of background activity is permitted for third party, was iOS mantra and at the same time Apple tried to depict their rival as total battery hog driven by many apps that all arrogantly eat precious juice of the pesky green bot machines even if there is no real need to do so. We are so much better designed system, was the conclusion of iOS supporters.

Wait...it is not that apps on Android live happily in the background and all they do is ruin the battery life. As mentioned earlier, both platforms apps are designed to be ready to die at any given moment. That moment usually comes right when the user navigates away from the given application to another one. It is usually suspended, or straight killed. The happy live in the backyard bush is only granted to special code on Android too, known as services. There are rules for them too and service is not automatically granted unlimited resource access. However Android gives developers more freedom to suck the battery, based on idea that perhaps there are situations where user really wants to use apps that do some intensive tasks in the background for a limited period of time and are OK with the reduced battery life. If they fathom that their device run on single charge is too short, Android gives them ways to track the offending piece of code quickly and take action (uninstalling, one-starring, even mailing the developer until order is restored).

Android service lifecycle

But that "we are more efficient" illusion of iOS is not something its fans want to cede easy. The stronghold argument of the power consumption superiority remains the home screen and widgets. New lock screen of iOS 5 might be seen as precursor of third party widgets coming soon. "Never, widgets are just catastrophe, ever updating on the background". This is just another myth. Lets have a look at the following :

How Android can be more power efficient, despite widgets and more relaxed rules for services ?

"Impossible, we are the best" is the short answer from the iOS camp. Well perhaps not really. Let's go for more arguments. "iOS is build around notifications, your application get will start once there are new data for it, no need to poll the server. iOS rocks !"

This is true. It is also true that very same system is available on the Android too, no need to poll the server either. But wait, there is actually more. Android is build about idea of small pieces of code, Activites, that constantly share information through the mechanism called Intents. OS provide a wide array of such data on its own, through system called Event Broadcast.

"Ha ! Another battery life trap ! Android developers constantly run some code, while the iOS is quietly conserving power". Well not quite like that. Sure, if you execute some code in Broadcast filter, this means extra consumption, but this code is super light. On the other hand, it gives the developer information, that is not available to third party software on iOS and must be obtained by - guess what - polling. If your application wants to do something special if some event just happened, it can, just running that little snippet of code. Say there is some other application trying to get the latest GPS location - listen for this type of event and your application can get the the most accurate location info for free. Another example : your application needs to send some stuff to the server. Again, if time of delivery is not that critical, wait for some other application to establish the network connection (which is expensive operation in terms of battery life) and take opportunity to bundle some data while radio is on. This is how a lot of battery life can be saved.

Android battery profiler reveals most juice is lost thanks to display. If you want to save power, don't use the damn device !

The best proof this is a viable concept is the fact that Apple is introducing similar concept in the latest iterations of iOS and developers can register at the NSNotificationCenter, however it is still quite limited in comparison to Android system-wide mechanism.

We, developers at Perpetum Design are super serious about the quality of our apps, and the impact the application has on the battery life of the device is an integral part of our design decisions. There were multiple cases when we were able to convince our customers to tackle the problem differently just because of the battery life concerns.

We believe most of developers think that way, thus more flexibility you have as the developer, the better for the entire ecosystem. Fortunately, the OS vendors seems to understand this too, and iOS and Android are looking more and more similar in that regard.

Hope this article helped to get light on some of those myths that surround differences between mobile platforms and their battery life related architecture and performance.