Mobile Multitasking
April 14, 2010
NOTE: The NDA has been lifted. While the information in this post is still accurate, you're better off visiting the iOS App Programming Guide
There seems to be a bit of confusion about how multitasking works on the recently announced iPhone OS 4.0 in comparison to Android. This is an attempt to explain without getting too mired in the technical details.
Android
I'm starting with Android because it helps to give perspective to what Apple did differently. On Android, apps are suspended when they are no longer visible to the user. Suspended means the app is still in memory, but it is frozen. No processing or event handling happens. If the system needs additional memory, the least-frequently used apps that are suspended (in the background) have their state saved to persistent storage and are then killed, freeing up their memory. To the user though, those apps still appear to be in the background. When they are brought to the foreground to be used again, they are restarted and passed an object containing their last state so they can be restored to look exactly as the user left them.
If an app requires processing while in the background, then it must also have a service component. A service on Android is like a separate small application that runs without a user interface in the background (though not actually a separate application). The service has a server/client relationship with the app. It performs whatever action an app needs it to continue performing should the app be suspended. For example, the service might handle all uploading, so if an app is placed in the background while an upload is in progress, the upload continues. Or, like Pandora, the service might handle all network streaming and audio output with the app only acting as the front-end controls. Unlike apps, services are not suspended or killed (except in extreme low-memory conditions).
A thorough description can be found in the Application Fundamentals section of the Android Dev Guide.
iPhone OS 4
Multitasking in iPhone OS 4 is similar to Android. Like Android, apps that are moved to the background are suspended; they remain in memory but are frozen. If the system requires additional memory the app state is saved and then the app killed only to be restarted and have the state restored when brought to the foreground again. Apple refers to this as Fast App Switching.
Background processing is however vastly different than Android. For starters, there are no services. Apps do not need to be designed with a client/server architecture if they require background processing. Instead, apps that require background processing must follow certain rules. 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. Once the task is complete or the time-limit is reached, the app is suspended like other background tasks. The ability for apps to continue processing for a short duration before being suspended is what Apple calls Task Completion.
If an app needs to continue functioning indefinitely while in the background, it must either perform one of the permitted background tasks or be architected to use notifications. There are only three types of actions allowed to be performed in the background and each is handled differently. They are:
- Background Audio
- Voice over IP (VOIP)
- Background Location
For background audio, an app designates that it requires background audio in its configuration and it is allowed to continue running (minus UI) when placed in the background. In a VOIP app, the system controls the network socket while the app is suspended. When there is a network event like a new call, the system wakes the VOIP app and the app assumes control of the network connection to handle the request. Background location is handled in two ways. One is for apps that don't require constant location data. When a significant location change has occurred, those apps are woken up, given the position change and allowed a short time to process it, and then resuspended. According to the iPhone OS 4 presentation, a significant location change is 500 to 1000 meters. The other method is for apps that require constant location data like a navigation app. These apps are allowed to continue running in the background (again, minus UI).
For every other case, apps must use 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 requires an external server to do the time-based querying/polling and when updates are available, the server pushes them to Apple who then pushes those notifications to the iPhone device. For example, a Twitter app wouldn't remain in the background polling for new updates. Instead Twitter would be polled from a server and when there was an update, the update would be pushed to Apple and then the iPhone device by the Push Notification Service.
If an app requires a background process to do something that isn't covered by the above methods, such as background video recording, then it simply cannot be done at this time.
iPhone OS 4 vs. Android
Why did Apple make their implementation of background processing seemingly so restricted when compared to Android? The restrictions themselves and rules for implementation point to two reasons: battery life and compatibility.
The battery impact of the OS handling multitasking for 3rd party apps in addition to system apps is negligible in terms of processor power usage. As correctly pointed out already, memory is more of an issue to the system for multitasking. However, battery life is impacted by 3rd party background apps that use the network, GPS, and other hardware. Restricting the types of background processing and even how they are implemented is for power management reasons.
There are already a plethora of apps that use network services. 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). This is the reason apps must use Apple Push Notification Service (PNS) for background network updates. PNS maintains a single network connection which listens instead of polls for updates. If there is no cellular connection, PNS will only listen via wi-fi if the device is not sleeping (i.e. the screen is on) or is plugged in as the wi-fi hardware uses additional power.
Of the two background location methods, the first one is preferred. It uses cell towers to determine position. Because the cellular radio is always on, power usage isn't increased to obtain the location. The apps using this data are only woken up when there is a change in position, usually determined by a hand-off from one cell tower to another. As mentioned earlier, this means a location change every 500 to 1000 meters when moving. If an application needs more frequent location updates, like a navigation app, then the GPS hardware is powered on to provide the position. However, as most navigation apps are used in vehicles, there is a good chance the device would be plugged into a source of power.
UPDATE: Further evidence that the restrictions on background processing, especially network traffic, are indeed for extending battery life. Android has no such restrictions and as a result battery life can suffer with poorly implemented apps. As Steve Jobs said, 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.
UPDATE II: Straight from the horse's mouth:
When asked about Android’s weak battery life at the Google Zeitgeist forum, Google co-founder Larry Page said that if anyone is not getting a full day’s worth of battery, there’s “something wrong.” Page then went on to suggest it’s probably user habits and third-party apps causing battery woes. “When there is software running in the background, that just sort of exhausts the battery quickly,” said Page.
As for compatibility, if Apple were to introduce an unrestricted service object like Android has, all current 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.
Cross-Platform Development
There was a rumor that the blocking of cross-platform development tools in the new dev agreement had to do with the new multitasking additions to iPhone OS 4. I can see some truth to this. The design of applications on Android and iPhone OS 4 are so different concerning background processing that there is no way a cross platform development tool like the one from Adobe could target both completely. As a result, you would end up with apps that only partially implement the capabilities of iPhone OS. I'm with Apple. That's not something I want either.