By Daniel Eran Dilger

Published: 06:00 PM EST (03:00 PM PST)

Costly Multitasking with Services

In order to actually do things in the background, Android apps must supply a "service" component, which spins off tasks that can continue even when the associated app is suspended. An Android service uses a client/server model to perform background tasks such as music playback or polling a server for new messages.

It's often these background services that are most likely to eat up battery life on Android phones, because they can open network connections to a remote server and keep those connections open. This forces the 3G or WiFi radio to remain constantly active, which is one of the fastest ways to drain the battery on a mobile device.

An Android service can also activate GPS to obtain regular location updates. This can be even more expensive in terms of battery life, as GPS exercises both the mobile network and the GPS antenna (as mobile signals are used to assist in the task of GPS tracking). Services can also eat up available RAM and consume CPU, but battery life is usually the primary problem.

Multitasking in iPhone 4.0 vs. Android

Apple was certainly aware of how Google had designed Android's multitasking model, and there's no evidence that Google patented the concept of services in its publicly documented, open source operating system. So the fact that Apple didn't clone Google's entire model for multitasking indicates that Steve Jobs wasn't just blowing hot air when he said Apple had studied the problem and devised its own approach to multitasking that it believed to be better.

At the same time, some aspects of Apple's new multitasking APIs are very similar in approach to Android's. According to an overview of the differences in Android and iPhone 4.0 by David Quintana, the "apparent multitasking" of iPhone 4.0, which Apple calls "Fast App Switching," is nearly identical to Android's app suspending concept described above.

When you switch from one app to another in iPhone 4.0, the previous app is held in memory but all activity is frozen. As noted earlier, this isn't really multitasking in the sense of desktop OS multitasking, but rather just an illusion that multiple apps are all running, when they're really not. They're just ready to run again as soon as you switch back: hence the name Fast App Switching.

Before Apple announced this mechanism, many iPhone programmers had expressed the idea that the system didn't really need "multitasking" as much as a "saved state" concept that would allow users to rapidly switch between apps. That's exactly what Fast App Switching does.

Just as with Android, iPhone 4.0 can reclaim memory by saving and then terminating apps that are frozen in the background, so when the user returns, the app can be reopened to the same place it was when the user quit. However, unlike Android, iPhone 4.0 presents a simple way to expressly quit a running app without needing a process management utility like TasKiller.

Because hitting the Home button no longer exits the app, Apple has now made a touch and hold shortcut that presents a red minus badge on running apps that can be used to quit them and remove them from the task tray of running apps, just like the Home button used to do. There's no manual management of apps and systems processes that could result in unanticipated problems for users.

Incidentally, this type of "apparent multitasking" is also what Microsoft plans to use in Windows Phone 7 at the end of the year. And once again for emphasis: this aspect of multitasking isn't really about running multiple apps at once as occurs in a desktop environment, it's about leaving them in memory so you can quickly switch between them.

More Efficient Multitasking in iPhone 4.0

Going beyond the apparent multitasking of Windows Phone 7, iPhone 4.0 will also support a specific set of tasks in third party apps that users will actually want to continue in the background after they leave an app. This is conceptually similar to Android's services, but is implemented in a new way. As Quintana writes, on iPhone 4.0 "background processing is however vastly different than Android."

A primary difference, Quintana notes, is that there is no concept of services in iPhone 4.0. Apps don't provide a background client/server component. Instead, Apple developed a set of rules that apps must follow in order to continue doing tasks after the user switches away from the app.

The idea of apps continuing to work after the user switches away is not new to the iPhone; it's only new to third party apps. Apple's Phone app already does this, as the company has long touted in its ads. With a call in progress, the user can hit the Home button and browse the web or look up a contact or check email while the Phone app remains on the call.

The same thing happens with the iPod app, which can continue to play music. SMS and Mail continue to get messages in the background and so on. However, this would quickly become a problem for users if all of the scores of apps they installed were all consuming resources without restriction as they checked for messages and streamed updates and continued other operations in the background.

In order to balance users' desires to do multiple things at once against users' expectations that their phone would work responsively for a reasonably long period of time, Apple defined a number of background tasks that third parties can implement, and set up rules that ensure these tasks are performed as efficiently as possible.

System-Wide Notifications as a Prerequisite for Efficient Multitasking

The first step down this path was delivered last year: Push Notifications. Rather than having apps sit in the background or spawning background services to poll remote servers for updates, Apple created a system wide service to efficiently listen for updates on behalf of the user's apps, and then present the user with notifications that the user then can act on (when convenient) by launching or switching to the app that has received the notification.

This is something other platforms don't really have in place. Even RIM's Blackberry, which is hailed for its push messaging savvy, has only recently opened up a public push messaging facility for third party apps. The result of this is that most Blackberry apps have already been designed to inefficiently poll their server for updates because unregulated multitasking was already there to allow them to do it "the wrong way." Users pay with shorter battery life.

Android apps similarly cause problems for users' battery life because they're each polling in the background rather than allowing a unified system thread to watch for updates while the individual apps all remain asleep. Apple's Push Notification feature therefore thoughtfully solved a complex problem before multitasking for third party apps was even attempted on the platform.

With iPhone 4.0, there's a second type of system level notification being added: Local Notifications. This mechanism allows apps to set reminders on a schedule that the system handles for them. Rather than being events that are pushed from an external server, they're set up by an app while it's awake, and then held and delivered on time by the system while the app sleeps.

An example might be an app that sets a reminder of a live webcast; the app doesn't need to remain in the background counting down to the notification; the system accepts the reminder and delivers it to the user at the set time on behalf of the app while the app itself goes to sleep.

On page 3 of 3: Getting things done in the background, reasons for multitasking differently.