How multitasking really works on Android and iOS

As the horsepower packed into mobile devices gets ever greater, more full-featured forms of multitasking are possible. The market leaders have very different ways of going about things, and there are numerous misconceptions about what is going on behind the scenes. This isn’t all the fault of the user, though. In the interest of ease of use, sometimes the multitasking metaphor is overly simplified on both Android and iOS.

iOS: It’s more complicated than it looks

Ever since iOS 4, Apple’s platform has had a limited form of multitasking accessed with a double tap of the home button. The multitasking bar is displayed at the bottom of the screen, and allows you to flip between apps. A long-press on an icon lets the user remove an app from the multitasking bar. You might think this is closing a background app that is easting up resources, but that’snot the case.

Apple only intended the multitasking bar to be a list of recent apps, not apps that are running in the background. It’s not a task manager, no matter how much it looks like one. In fact, almost nothing in the multitasking bar is truly “multitasking.” Apple’s tightly controlled platform instructs most apps to stop running code when the home button is pressed.

There are five states of app activity on iOS, with the least interesting being Not Running, and Inactive. Not Running simply means the app is closed or hasn’t been launched. Inactive is a running app that isn’t running code, for example if the device is asleep. Active is the state of an app when it is in the foreground being used.

When an iOS user hits the home button, an Active app moves to Background. A Background app is not on the screen, but is still executing code. Most Background apps immediately switch to Suspended mode. A Suspended app is cached in memory, but uses no processor cycles, and thus is running no code on the device. If the device needs more memory for a game or other large app, Suspended apps will be cleared from RAM.

Apps are only allowed to remain Background tasks and run code for longer than a few seconds in specific circumstances. A series of tightly controlled APIs allow indefinite backgrounding for things like VoIP, location tracking, and audio playback. None of this has any bearing on what is in the multitasking bar. A well-written app should suspend itself when it’s done running code, and users shouldn’t really have to monitor such things on iOS.

Android: Multitask like a boss

Google made some fairly significant changes to the way multitasking is accessed on Android 4.0 Ice Cream Sandwich. In the new recent apps list, you can swipe apps away like cards to remove them from the list. Just like in the case of iOS, this tends to give users the feeling that they are managing tasks; freeing up memory even. However, that is just as wrong here as it is on Apple’s platform.

The recent apps list is just that, a list of recent apps with thumbnails. There is no guarantee that the apps are actually running any code just because they are in the list. When a user hits the home button, an app does not immediately enter some thing akin to Suspended mode on iOS. The process associated with an Android app remains in the background and is allowed to do any work it needs to. Apps on Android might use multiple processes, and multiple apps can share a single process.

When users want to return to an app they have left, the process is restored as a foreground app almost instantly. In a perfect world, an Android device would never run out of memory, and all these processes could live in RAM forever. This being the real world, your device will probably run short of RAM at some point. When that happens, it’s much the same as iOS. The system kills the process and the kernel reclaims the resources. The next time a user opens that app, it has to completely reloaded. This app could still be in the recent apps list, which has no bearing on whether or not its process is still running in the background.

In more recent iterations of Android, the platform has gotten much smarter about managing tasks for you. There is simply no reason to use a task manager to keep the system running smoothly. In fact, this could interfere with Android’s automatic process monitoring. Developers have two ways to explicitly run code in the background and prevent it from being stopped unexpectedly. A manual task manager would interfere.

The ways Android apps avoid being killed in the background has a parallel on iOS with the limited Background APIs. The BroadcastReceivers component lets apps wake up for a short time to run some task or another, and then shunts it back to a background state. This is useful for location check-ins or file syncing.

The other way to forcibly maintain an app in the background is the Service component. An app that is running as a Service can run indefinitely and should almost never be killed by the system. This is what makes Android multitasking unique. Regular processes will be ended before a service, and a developer can further indicate a Service’s importance by running it as “foreground,” but this requires a notification icon to be persistently visible in the notification bar. You will see this behavior with automation apps like Locale as well as with music playback.

It’s about control, and you don’t have much

Be it iOS or Android, the operating system does most of the task management for you. iOS never really allowed users to monkey around with running tasks, and even now it forces developers to very clearly declare why an app needs to exist as a non-Suspended Background process for more than a few seconds. Suspended processes are killed as needed, and the recent apps bar has nothing to do with that.

Android also closes down processes that are no longer needed, but it gives developers a few more ways to run behind the scenes. The process associated with an app is free to run whatever code it needs in the background, but if memory is constrained, it could be ended at any time. By running a BroadcastReceiver or Service, apps can be assured of a little more functionality, though. Even in Android 4.0 with its slick recent apps interface, removing an app won’t force-kill the underlying process. That’s up to the system.

The bottom line is this: don’t worry about it. The apps running in the background, be they Suspended iOS apps or Android Services, will be handled by the system in the most efficient way. Both platforms know to kill apps that are no longer needed, and removing things from your recent apps list on either platform isn’t going to help.

Source : http://www.extremetech.com/computing/112013-how-multitasking-works-on-android-and-ios