Apple iPhone vs. Android Multitasking: A Comparison
This is the kind of thing you bookmark: an excellent analysis (at least it seems so to me) by David Quintana, who compares how multitasking is implemented in Android and iPhone 4.0.
I have to confess I don't know who Quintana is: the link to his "mobile multitasking" post was provided by John Gruber on his DaringFireball blog. And it turns out to be pretty popular name when I googled it, so I've not yet tracked down his bona fides. (If anyone knows more about Quintana, please let me know via email or in comments.)
Having said that, his analysis is intriguing: partly because it's clearly, straightforwardly, simply written, there's a sense of a mind really interested in exploring how these two platforms actually implement multitasking, understanding how each works, and what the differences are and what those differences mean.
So, you can read the whole thing but he starts with Android: applications that are no longer visible to the user are suspended -- remaining in memory but without event handling or processing.
If this background app needs processing, it requires a "service" -- which Quintana likens to a kind of separate small application that runs without a user interface, doing stuff like completing a file upload on behalf of the suspended app.
iPhone 4.0 handles app suspension in a very similar manner. The difference lies in how iPhone handles background processing. This is much more bound or limited than in Android, according to Quintana. The iPhone OS doesn't have the same idea of "services." So "If an app merely needs to finish what it is doing before it is suspended, it asks for a limited amount of time to continue processing in the background. An example would be a file upload that needs to finish," he writes. As soon as that task is done, the OS suspends the app as usual.
But things get more complicated if the app needs to continue functioning while in background. If so,"it must either perform one of the permitted background tasks [background audio, VoIP, or background location] or be architected to use notifications.
Apple offers two kinds of notifications: Local Notifications or Apple's Push Notification Service. "Local Notifications are for time-specific alerts that would usually require the use of a timer, like an alarm clock or calendar alert. Instead, before the app is suspended, it schedules with the OS the alerts and times to notify the user. The OS then delivers those notifications while the app is suspended."
The Push Notification Service involves a server that generates time-based querying or polling, and then hands them off to Apple's hosted service, which then pushes the update or notice down to the iPhone client. The example he gives is for Twitter: instead of a Twitter app running on the iPhone checking the Twitter, the server application checks Twitter, finds updates, sends them to the Apple service, which then sends them to the iPhone.
Then his discussion gets REALLY interesting. Quintana notes that the battery impact of the actual multitasking -- consuming CPU cycles, for example -- is negligible. Instead, one danger lies in applications that continually make use of the available network connections, GPS, or other phone-based, and battery-powered resources.
"If for example, a Facebook client, a Twitter client, an email client, an IM client or two, and a newsreader all ran in the background and polled the network every minute or so for updates, there would be enough network usage to have an effect on the battery (it would be even worse if it happened over wi-fi vs 3G)." That's why, he says, Apple requires the use of the Push Notification Service for this kind of communication.
"Android has no such restrictions and as a result battery life can suffer with poorly implemented apps. As Steve Jobs said [during the iPhone 4.0 announcement], if you need a task manager, you already failed. I think it is safe to assume that Apple thoroughly tested the different methods of allowing background processes before deciding on this restrictive, yet power friendly implementation."
A second danger is due to the limited memory in all smartphones. Quintana has a link to Robert Love, who has written about this: "Both the iPad and iPhone, as mobile devices, have limited memory (256MB in the current incarnations) and no hard drive. No hard drive means no swap file. Limited memory and no swap imply that applications have a small, fixed amount of memory at their disposal. They don’t have the luxury of seemingly-infinite memory, as a modern system with swap has."
Love continues: "Memory consumption is thus a critical system constraint. Like most systems, the iPad and iPhone deal with this by killing applications that use too much memory via a mechanism called the out of memory (OOM) killer. Unlike most systems, applications designed for the iPad and iPhone know how much memory they have at their disposal, and are designed to operate within those constraints. This is classic memory management in embedded programming. No swap, fixed memory, you deal."
Quintana concludes by noting that if Apple introduced Android-like unrestricted multitasking, "all current [iPhone] applications that might take advantage of background processing would require a redesign to use a client/service architecture. Developers would have to maintain a completely different app for pre-iPhone OS 4 devices or iPhone OS 4 devices with no multitasking. In addition, the backend server infrastructure required for PNS would only be used for pre-iPhone OS 4 devices and non-multitasking iPhone OS 4. This would fragment development severely."