How Multitasking Works on a Smartphone – Gizmodo
[Via Gizmodo]
Multitasking! On phones! Everybody does it now. But each smartphone platform does it differently. Here are the various tricky ways that the major platforms try to juggle multiple apps.
The Constraints
A smartphone is a computer that fits in your pocket, but it has some constraints that a desktop doesn’t, which make multitasking far trickier (hence the reason we’re even explaining it). Namely, these four resources are constricted, and they’re what mostly shape the way multitasking works on phones:
• Screen real-estate: There’s only so much you can do with a 3-to-4 inch screen at one time
• Battery life: You want your phone to actually last all day, or come close to it, right?
• CPU: It’s slower than anything in a laptop, because of size and battery life
• Memory: There’s not that much of it, also partly because of battery life
This fourth item, a lack of memory, means you can do far fewer things at once; there’s also no disk swap in any of the major OSes, so you can’t use the phone’s actual storage as virtual memory, either. Lack of plentiful RAM is perhaps the most pernicious constraint after battery life, actually.
From a user perspective, multitasking doesn’t work so differently if you move from Windows to Linux to Mac on a desktop. But on a phone, everybody has their own ideas about how to make it work, ranging from leaving things nearly wide open for third-party apps to run willy-nilly (old-school Windows Mobile and BlackBerry) to making things pretty damn restrictive (iPhone pre-4.0 and Windows Phone 7). Even the common smartphone elements—notifications and fast app switching—can differ wildly from platform to platform. So here’s the gist of how multitasking works on each major smartphone.
Android
The Android model is perhaps the most interesting, a hybrid system that’s fairly open about allowing stuff running in the background, but at the same time aims to be completely invisible to you, the end user, so that you don’t have to actively manage whether an app is open or closed. It’s a little complicated so we talked to an Android engineer about what’s going on inside.
What happens when I switch to another app?
The app you switched from doesn’t stop—the process stays open. At least, as long as it can. When Android detects it’s running low on memory, then it kills processes to free up resources. It asks apps to save their state when you switch, so that any can be killed at any point, then reopen like it was never killed when you return to it.
What can apps do in the background?
Android has two basic facilities for third-party multitasking—broadcast receivers and services. With a broadcast receiver, an app that goes into the background is basically asking to be told about an event, like if you move 500 meters, or your battery level hits a certain percentage. (That’s how Google’s apps that use push, like Gmail work—instead of pinging the server for mail constantly, it waits to receive a notification that mail has arrived.) That way the app can go away, and not use resources, but restart when something happens that it needs to act on.
Services are what you’d consider more traditional background processes, with apps running to play music, or do turn-by-turn navigation—they’re essentially a request from the app to say it needs to run for X amount of time.
What can’t apps do in the background?
Remember Android’s garbage battery life when it first came out? That’s because there really were no restrictions on what kind of resources an app could consume in the background. Since Android 1.5, apps running in the background are capped at using 5-10 percent of the CPU altogether—which is the only major restriction placed on apps in the background. The other is that it’s not easy for app to push itself to the foreground—they’re supposed to the window shade notifications system.
iPhone 4.0
iPhone has always been a multitasking OS, but only for first-party apps. That changes with iPhone 4.0, which delivers multitasking and background processes for third-party apps, but in a characteristically tight-gripped way. Like Android, the idea is that users won’t actually manage applications themselves, but that the system will take care of it for them. Unfortunately, a lot of the technical details are still wrapped up by non-disclosure agreements, but we have a basic idea of how stuff works.
What happens when I switch to another app?
Of the seven new multitasking services, two can come into play when you switch to another app: With fast-app switching, an app is frozen instead of killed, allowing users to immediately pick up where they left off, without having to reload the app. Since the user isn’t actively managing whether applications completely quit or not, the system presumably kills apps when it has too many hanging around. (This is a lot like Android, in some respects.) The other is task finishing, where, if you leave an app when it’s mid-task, the app can tell the OS it needs to keep running in the background to finish whatever it was doing.
What can apps do in the background?
Besides finishing a task, a third-party app is able to perform a limited set of functions in the background via Apple’s new multitasking services. The difference between iPhone and Android is that with iPhone, the app isn’t full-blown running, but just operating via these services. For users, that mainly comes down to VoIP (making and receiving calls via Skype or whatever), background audio (being able to listen to Pandora, Rhapsody and Slacker in the background), and background location, which comes in two flavors, cell tower location checking, to save battery life, and full GPS tracking, for navigation apps.
What can’t apps do in the background?
Basically anything not set forth in the seven services. So if it’s not VoIP, or background audio or location, it probably ain’t running in the background. (It can stay frozen in memory for a speedy return, though. In situations where you don’t need it to do anything while you’re away, this is just as good.)
WebOS
Palm—newly acquired by HP mainly for its WebOS smart platform—has perhaps the most elegantly transparent approach to task-based multitasking—users do in fact manage apps, but it’s so transparent, the open-apps-as-floating-cards metaphor so straightforward, it simply works. But there’s actually a few different things going on with Palm’s approach, which is slightly more complex than you might realize. So I talked to Palm’s CTO Mitch Allen about it.
What happens when I switch to another app?
Well, it depends on what you mean by switch to another app. If you have a card open and flick it up to get rid of the card, the app is killed entirely. If you simply switch to another card without closing it, however, the app is considered “minimized,” so it goes into a semi-dormant state, with restrictions on the services it can access, like the accelerometer. Or if you’ve run out of memory by opening too many cards, you get a warning from the OS.
What can apps do in the background?
There’s a couple different ways that apps can run in the background. As a minimized card, an app can “mostly do what it wants to do in terms of data and network access” says Allan, because “our desire was a fairly open architecture.” A “pure background app” can schedule itself to be woken up and run for up to 30 seconds to generate data requests, or to schedule another wake up. If you do close an app entirely, it can open what Palm calls a dashboard, which is “like a traffic monitor,” which basically means it can listen for notifications.
What can’t apps do in the background?
It actually varies from app to app. The standard web language apps—basically everything pre-January—have mostly open access when they’re minimized, as Allan says, but Palm throttles services that are “battery expensive,” like constant data requests and accelerometer access. Palm’s actually making things slightly less restrictive—the 30-second window background apps have for wakeup data requests used to be 15 seconds. Apps that run using the PDK—like the intense games Palm showed off at CES, with deeper access to the underlying hardware—have a slightly different set of restrictions, so memory use is constricted, and graphics are suspended when they’re in the background.
Windows Phone 7
Oh, irony—Microsoft goes from having one of the most open multitasking smartphone OSes with Windows Mobile to one of the most restrictive. Their goal in designing the way multitasking works with Windows Phone 7 is to stick to delivering the “core experiences” people want out of multitasking, without going full bore on it. Sounds like it’s…hmmmm…so we talked to Microsoft’s Aaron Woodman, director of the mobile communications business, about it.
What happens when I switch to another app?
Apps don’t die when you leave them in Windows Phone 7. So when you switch from an app, it saves its state in memory and is frozen, for fast-app switching—like Android and iPhone 4.0. Woodman says “as you get further away from an app, and resources are needed, it frees them, but you can go right back.” When it needs to free up resources, an app is “dehydrated,” which is “one level above being killed” and then when you open it back up, with that saved state, it’s “rehydrated.”
What can apps do in the background?
Um, not a lot—it’s very much back to the olden iPhone days, where notifications are an app’s primary way of getting anything done when it’s not running. The fancy demos of Pandora running in the background? That’s for an elite group of third-party partners only, and Woodman says access like that, it’s “hard to know if that’ll scale in the broad term.” In terms of notifications, Microsoft has an impressively wide variety though: A tile notification, which pushes new info to a Live Tile on the home screen; a toast notification, which is a pop-up, like an incoming call; or a raw notification, which is raw data sent to the application.
What can’t apps do in the background?
Basically? Anything. They can receive notifications and send notifications to the top. That’s about it, unless they is special. The bright side? Woodman says “at the end of the day, we will change the platform based on third party and user input.”
And that’s about it, or at least, what you actually need to know. We left off old-school Windows Mobile because it’s effectively obsolete, along with BlackBerry OS because it’s in flux with OS 6, as well as Symbian, which is undergoing its own contortions with S^3—not to mention their models aren’t complicated as the ones here.