Multitasking in Android vs iPhone OS 4.0

source: appleinsider.com
How you work on a smartphone is very different from how you work on a desktop computer. This reality is particularly true when it comes to multitasking. The approach to multitasking taken by Google's Android and Apple's upcoming iPhone 4.0 is also very different. Here's how they compare.

Desktop Multitasking

On a desktop system running Mac OS X, you don't just want to have multiple apps open and running, each with its own set of open windows. You also want lots of stuff happening in the background, because otherwise your expensive CPU and GPUs are just sitting there idle when they could be doing useful stuff.

Over the last decade of Mac OS X's development, Apple has added lots of new technologies to keep the processors working. The operating system debuted in 2001 with a fancy new compositing graphics engine, which with each new release kept giving the CPU (and later GPUs) additional busy work to do in the background, from shadows to translucency to reflections.

Mac OS X also has Spotlight indexing happening at regular intervals, and throws in automatic file system defragmentation and Time Machine backup change tracking as files are accessed, just to mention a few background features. The faster Macs get, the more extra background tasks the system can throw at the various available processor cores without causing (hopefully) any discernible slowdown for the foreground app.

Many of the new improvements in Snow Leopard were centered around managing how to most efficiently parcel tasks out to the various processor cores available in the system (Grand Central Dispatch) and taking novel advantage of the often idle GPU (OpenCL). The more a desktop operating system does in the background, the richer the experience it can offer.

Mobile Multitasking

When the iPhone appeared and debuted Apple's first mobile variant of Mac OS X, the design goals for the new operating system were turned completely upside down. When a system has to run off its own limited battery, you don't really want it to be doing lots of stuff in the background at all. You really want everything to be idle as much of the time as possible.

Of course, there's still lots that needs to be done, and in many cases, even more to do than a typical desktop. For example, there's a constant need to watch for incoming phone calls or SMS messages. This means the baseband unit has to constantly track the nearest cell tower with an acceptable signal in order to be ready to accept incoming calls or messages.

Power management certainly wasn't an entirely new idea; Apple had been selling notebooks for nearly twenty years, and had created increasingly sophisticated methods for shutting down unnecessary hardware to conserve battery life.

But on a handheld mobile device like the iPhone, there's not just hardware power management to think about. There's also a radically new user interface for working with apps. Apple invested a lot of engineering into deciding how to best deliver a mobile device that balanced features and functionality with acceptable battery life.

Not Multitasking on Purpose

A major design decision of the iPhone was to limit effective multitasking to core system apps, including Phone, SMS, iPod, Clock, and processes that supported these and similar features. When third party apps appeared with iPhone 2.0, there was no provision for running these in the background.

Apple's explanation was that enabling third party apps to run concurrently would simply consume too much battery while presenting potential security problems, and would necessitate providing a manual tool to manage background processes so that they didn't consume all available system resources.

Instead, Apple said it was working on a solution to the primary reason apps would want to run in the background: listening for external updates. Apple's strategy was delivered later than expected as it realized what a huge undertaking this would be, but the resulting Push Notification service enabled iPhone apps to seem responsive to external updates without actually running in the background, constantly polling servers for updates.

There was no technical limitation that kept third party apps from multitasking; the restriction was artificially imposed by Apple to simplify and optimize the performance of its mobile devices. By jailbreaking the iPhone, users can activate unregulated multitasking among third party apps. However, this results in battery life and performance issues the user will need to manage manually.

Apparent Multitasking

Google created multitasking for Android that works very differently than multitasking on a desktop system. In fact, they're so different that its almost confusing that both are referred to using the same word.

On a desktop system, multiple apps all open at once (in addition to background processes) are all able to do work concurrently. As the mouse moves between windows of different apps and clicks on things, events are sent to each app. They're all on and active, although tasks can sit in the background and essentially do nothing, taking up no real processing power and consuming no real memory (thanks to the mechanism of virtual memory) until the user activates them.

On Android, when a user switches from one app to another, the background app is suspended. This is like going into a coma; it's still taking up memory (which is scarce) but can't respond to anything or continue work or begin any new tasks. If the system runs low on memory, it begins saving the state of suspended apps and terminating them.

Terminated apps still appear to be running. When the user jumps to the app, it is relaunched and passed its saved state by the system so that it loads up to look like nothing ever happened and it has been actively running in the background. So far, this isn't really multitasking at all, but rather just a faster way to switch between apps that each run one at a time like the iPhone.

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.

Getting Things Done in the Background

While it's most efficient to have apps sleep, there are a few cases where an app actually needs to do something in the background. The most obvious involves finishing some time-consuming task such as a file upload. Users don't want to be forced to watch a progress indicator, which is what they currently have to do.

Right now, if a user quits a third party app while it's finishing an operation, the operation will fail because the app is forced to quit by the system. Apple's own apps, including Mail and SMS, can continue to send messages after the user appears to have quit the app, but that's because Apple's own bundled apps aren't forced to quit. Other apps are.

To accommodate this type of multitasking in iPhone 4.0, Apple added the Task Completion API, a feature that enables app developers to design their app so that it can request a specific amount of time to continue a task after the app is supposed to be put to sleep in the background. Once the app finishes its task or its requested time period expires, the system suspends the app as usual.

Three Special Background Tasks: VoIP, Audio, and Location

There are three other multitasking scenarios Apple supports in iPhone 4.0 which are related to ongoing tasks an app might want to do. This mechanism of granting exceptions to the "one app at a time" model for specific types of apps was anticipated in AppleInsider's earlier coverage of the development of multitasking in the iPhone OS.

The first exception API allows apps to work like the bundled Phone app: being able to accept calls and continue a call while other apps are being used. Only Apple's Phone app can place mobile calls, so this feature is called Voice over IP, as it's designed to support calls placed over an Internet connection using an app like Skype.

In order to make use of this new background VoIP mechanism, an app registers with the system and can then be suspended while the system maintains a network socket listening for incoming VoIP calls. When a call request occurs, the system wakes up the VoIP app and transfers it control of the network connection to service the call.

A second scenario is similar to the built-in iPod app: Background Audio. This allows apps such as Pandora to request the ability to continue playing a music stream even when it is not in the foreground. Apple ties the same background playback controller used for iPod to the app that has requested the use of the new Background Audio facility.

A third scenario for multitasking involves regular location updates. The new Background Location serves two types of apps that use location data: GPS apps that supply driving directions and social networking apps that use the user's location to notify their friends or suggest nearby events.

In the first case, Apple allows apps devoted to driving directions (like TomTom) to remain awake and access GPS in order to provide audible directions even when the app is put into the background. This would normally drain the battery pretty quickly, but most people who are using GPS do so in a car with a kit that supplies constant power.

On the other hand, social networking apps such as Loopt similarly need to know the user's location in order to be useful, but are not typically used in a car kit. If they used GPS, they'd nail the iPhone's battery pretty rapidly just to offer a lightweight service of limited value. In order to support these types of services efficiently, Background Location supplies them with data the phone already gets on a regular basis every time the user moves between mobile cell towers.

This update happens when the user moves between 500 and 1000 meters. When a location change is noted, the system wakes the app, updates its location, provides it with a period of time to process the change, and then suspends it again. This gets around the battery taxing use of GPS while still allowing these types of apps to work without constantly being in the foreground (as is currently the case on the iPhone).

Reasons for Multitasking Differently

In addition to increased efficiency, Apple's approach to regulated multitasking allows for simplified compatibility between devices like the iPhone 3G, which won't support multitasking, and more recent devices that do. Apps that take advantage of the new APIs simply request the ability to do things in the background, so if the hardware doesn't support it the requests are just denied by the operating system.

Google's approach with services requires a new model of client/server components. If Apple had copied that, developers would have to create one set of apps for older devices and an entirely different code base of apps for newer ones, a complex and problematic transition step given that Apple already has a vast library of existing titles in the App Store.

Additionally, much of what developers do with services on Android is already handled by the iPhone OS with Push Notifications. So implementing an Android-like services architecture for iPhone 4.0 would suggest to Android developers wanting to port their apps that they should do so using services rather than the more efficient Push Notifications, creating a problem like the one that exists on the Blackberry, where push features are largely ignored and go unused.

Unified development tools: Clang, LLVM and Xcode

This also all leads to the conclusion that Apple's design for incorporating multitasking features in iPhone 4.0 is all about doing what's best for the iPhone OS platform, rather than trying to create compatibility or similarities with other platforms that do things differently.

It should come as no surprise that Apple is not at all interested in making it easy or simple to port apps between the iPhone OS and other platforms. Doing so would only water down the advantages of the iPhone OS and encourage developers to aim at a lowest common denominator that worked across platforms rather than aspiring to take full advantage of the unique features of the iPhone OS.

This is the same reason why Apple has no interest in supporting Flash or Java as a meta-platform on the iPhone, and also why the company does not want to support third party efforts to create development tools that output iPhone apps. The Flash Professional strategy Adobe hoped to roll out will not offer its users the ability to support iPhone 4.0's multitasking features, Adobe would not be able to rapidly add these features as soon as Apple would like, nor would it necessarily even be in Adobe's interest to add them.

Apple's new prohibition of iPhone 4.0 development in languages other than C, C++ and Objective-C was largely seen as an attack on external development tools like Adobe's Flash CS5. However, observers including Rainer Brockerhoff have since noted that Apple's focus on C languages likely has more to do with the company strategy for optimizing iPhone OS development using Clang.

Clang (short for "C Language") is an open source project Apple funded to serve as a new front end compiler for (unsurprisingly) C, C++ and Objective-C code. Clang connects to LLVM, the Low Level Virtual Machine, which serves as the back end compiler for Apple's Xcode development tool for both Mac OS X and iPhone OS.

The combination of Clang and LLVM effectively replaces GCC (GNU Compiler Collection, the GPL-licensed compiler for Unix-like operating systems). Because Apple's replacement compiler tool chain is licensed under the more permissive BSD license, Apple can integrate it more closely into its Xcode Integrated Development Environment.

Additionally, Clang and LLVM enable Apple to better optimize various steps of the code compiling workflow, creating Mac and iPhone apps that are more efficient, faster, more compact, and easier to debug, due to a variety of optimizations and enhancements that the flexible, modular new compiling tools provide over GCC.

Having invested so much strategic work into Clang and LLVM, it's no wonder Apple is working to push developers to use its own development tools rather than trying to leverage emerging lowest common denominator platforms to deliver iPhone apps that aren't optimized for the iPhone or the latest features of the iPhone OS, including new support for multitasking.