By Daniel Eran Dilger
Published: 06:00 PM EST (03:00 PM PST)
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.
On page 2 of 3: Multitasking in iPhone 4.0 vs Android.
