Big change for me this year; I dumped my iPhone for an Android because I wanted to have more control over my smartphone. For instance, I use a lot of different applications and I like to have full access to control what is or is not running. Well guess what, as it turns out, you actually don’t have to. Android does that for you. Wow, groovy!
And that’s what I’m going to talk about today – The inner workings of the Android Mobile phone and why it’s so awesome from a multitasking and memory management standpoint! So, sit down and prepare for some heavy reading.
1- First of all: What is multitasking?
Numerous sites explain multitasking as:
“Ability of an operating system: able to perform multiple tasks at once”.
Multitasking comes in handy when you want to listen to music and watch your timeline on Twitter at the same time (among other things). Granted, with the new update from iOs, this is now possible as it is on the Android. The best (in my eyes) explanation of multitasking in Android I found was written by Robert Love, at his website. Robert Love is an engineer and book author who works at Google. He tries to explain multitasking to us as a user, but also tells us what the reason is why it works on a Android, and not on a iPhone or iPad.
Why the iPad and iPhone don’t support Multitasking
Why don’t the iPad and iPhone support multitasking? The answer isn’t what you think.
There is a lot of misconception around support for multitasking in the iPhone and its giant cousin, the iPad. What follows is my analysis of the situation. I am not privy to any insider Apple information. Moreover, while my knowledge is certainly colored by my work on Android, I’m not drawing a comparison or using any Google-specific knowledge.
First, obviously the iPhone and the iPad do support multitasking. This is 2010 and both are built on modern, powerful operating systems that provide support for preemptive multitasking. Indeed, at the system level, there are many processes running concurrently. And some Apple-provided applications, such as the music player, clearly multitask.
So let’s redefine the complaint. What in actuality is not supported is the ability for third-party applications to multitask. That is, the system enforces a policy whereby once an application leaves the foreground, it terminates. In some ways, this makes sense. The iPad and iPhone user interfaces are single window, single document. Not allowing for background applications probably works out for a whole lot of use cases.
Apple says they do not support multitasking because it is a hamper to stability and a drain on battery life. That clearly isn’t true—the iPad has plenty of processing power and battery capacity. Rumor is that Apple is going to add multitasking in a future OS release. This rumor likely is true. Is Apple somehow going to make background applications not consume any battery? Of course not. These excuses are straw men.
The real reason that the iPad and iPhone do not allow third-party applications to multitask is likely more complex, more technical. Bear with me here. Both the iPad and iPhone, as mobile devices, have limited memory (256MB in the current incarnations) and no hard drive. No hard drive means no swap file. Limited memory and no swap imply that applications have a small, fixed amount of memory at their disposal. They don’t have the luxury of seemingly-infinite memory, as a modern system with swap has. Memory consumption is thus a critical system constraint. Like most systems, the iPad and iPhone deal with this by killing applications that use too much memory via a mechanism called the out of memory (OOM) killer. Unlike most systems, applications designed for the iPad and iPhone know how much memory they have at their disposal, and are designed to operate within those constraints. This is classic memory management in embedded programming. No swap, fixed memory, you deal.
What would happen if third-party applications could multitask? Some number of applications would be in the background. But each application was written presuming it had access to some fixed amount of memory. Thus, if the background applications consumed too much memory, the operating system would have to kill them. But the user would expect that he or she could switch back to an old application, and it would still be running where it was left. He or she certainly doesn’t expect applications to just die every time a new application is run, losing state and even data.
Simply put, the reason the iPad and iPhone do not support multitasking is because it is hard to allow multitasking in a system with no swap and a limited amount of memory. Apple could enable multitasking—indeed, there is no reason that the devices couldn’t support it right now, with a one or two line code change—but your applications would constantly be killed. That isn’t a very useful feature.
So how is Apple going to enable support for multitasking? Likely similar to how Android allows it. The Android platform was designed from the ground up for use on phones and other embedded devices. Consequently, we built in a mechanism whereby applications can save their state, including their current view, with the system. In fact, through this state saving mechanism, which we call Bundles, Android applications can operate as if they are stateless.
Thus, allowing for multitasking on Android is easy. Like the iPad and iPhone, we have a powerful, modern operating system (in Android’s case, based on the Linux kernel). Unlike the iPad and iPhone, we also have Bundles, which allow apps to save their state. Android’s OOM killer is aware of background applications and is capable of killing them in least-recently-used order. If the user switches back to an application that has been killed, the Android platform reloads the application’s state via Bundles. The whole process is seamless. Because Android has this state-saving framework, multitasking is feasible even on a device with limited memory and no swap.
In summary, the iPad and iPhone don’t support multitasking not because it would hurt battery life, but because it is hard to do so on a swapless, embedded device without platform support for serialization, which the devices lack. It is likely that Apple will add the requisite functionality in a future OS release. Until then, enjoy your giant iPhone. Or rock a Nexus One, which multitasks.
Folks have asked me how a serialization system such as Bundles enable support for persistent applications, such as music players or IM clients. You wouldn’t want these applications killed, even in low memory situations, and their state is ever changing so saving it isn’t productive. There are many ways Apple can provide this support. On Android, we do so via Services. Most applications use the Bundle framework to save their state and are thus easily interruptible. Applications that provide a service to other applications, are a server, or function as a long-running background task use the Service framework. These applications are managed by the system more like Unix daemons and are not killed in least-recently-used order when memory is low.
Whoohee, that’s some story about multitasking! But now you know why it works this way, and why this is another reason to choose for a Android device.
2 – How Android handles its processes and apps.
A common misunderstanding about Android multitasking is the difference between a process and an application. In Android these are not tightly coupled entities: applications may seem present to the user without an actual process currently running the app; multiple applications may share processes, or one application may make use of multiple processes depending on its needs; the process(es) of an application may be kept around by Android even when that application is not actively doing something.
The fact that you can see an application’s process "running" does not mean the application is running or doing anything. It may simply be there because Android needed it at some point, and has decided that it would be best to keep it around in case it needs it again. Likewise, you may leave an application for a little bit and return to it from where you left off, and during that time Android may have needed to get rid of the process for other things.
A key to how Android handles applications in this way is that processes don’t shut down cleanly. When the user leaves an application, its process is kept around in the background, allowing it to continue working (for example downloading web pages) if needed, and come immediately to the foreground if the user returns to it. If a device never runs out of memory, then Android will keep all of these processes around, truly leaving all applications "running" all of the time.
Of course, there is a limited amount of memory, and to accommodate this Android must decide when to get rid of processes that are not needed. This leads to Android’s process lifecycle, the rules it uses to decide how important each process is and thus the next one that should be dropped. These rules are based on both how important a process is for the user’s current experience, as well as how long it has been since the process was last needed by the user.
Once Android determines that it needs to remove a process, it does this brutally, simply force-killing it. The kernel can then immediately reclaim all resources needed by the process, without relying on that application being well written and responsive to a polite request to exit. Allowing the kernel to immediately reclaim application resources makes it a lot easier to avoid serious out of memory situations.
If a user later returns to an application that’s been killed, Android needs a way to re-launch it in the same state as it was last seen, to preserve the "all applications are running all of the time" experience. This is done by keeping track of the parts of the application the user is aware of (the Activities), and re-starting them with information about the last state they were seen in. This last state is generated each time the user leaves that part of the application, not when it is killed, so that the kernel can later freely kill it without depending on the application to respond correctly at that point.
In some ways, Android’s process management can be seen as a form of swap space: application processes represent a certain amount of in-use memory; when memory is low, some processes can be killed (swapped out); when those processes are needed again, they can be re-started from their last saved state (swapped in).
3 – Why Task killers are a no-no for Android
Android and Windows have very different memory management methodologies. People that are used to running Windows are mistakenly applying their bad habits to Android, and end up with completely different (and usually opposite) results.
In Windows, applications are allocated memory as they start up, and hang onto it until they either exit normally or are end-tasked. This means that if there’s no free memory, programs will either fail to launch or Windows will attempt to use the paging file (swap) to push other programs there. This obviously slows down the machine considerably, which is why freeing up memory is a good practice.
In Android (and Linux in general) the memory management is completely different. After the initial start-up when core services and apps load up, the OS tries to allocate the rest of the available memory to as many applications as it can, so that when you do launch them they spring to action much faster than they would from scratch (This by the way, is why you hear of people complaining that Android starts up apps that they have not yet opened). When you actually launch an app that hasn’t been allocated memory, the OS will automatically free it up by either de-allocating it from non-running apps, or even killing off other already running apps. Like Cyanogen himself said on multiple occasions, "Free memory is wasted memory."
Using a task manager on your phone to terminate an app that’s gone wrong from time to time is fine. However, having it kill off all "running" apps on a timer is simply wasting the phone’s CPU cycles, since the OS will simply try to re-allocate that memory again. Any perceived speed increase after end-tasking all running apps is a pure placebo effect. What you are actually doing instead is interfering with the normal Android OS operation, and are slowing things down.
Or as they say at Google:
Applications may seem present to the user without an actual process currently running the app; multiple applications may share processes, or one application may make use of multiple processes depending on its needs; the process(es) of an application may be kept around by Android even when that application is not actively doing something.
4 – Conclusion
The Android Market has dozens, possibly hundreds, of task killer apps all begging for attention. I’m sure some people may argue that there’s some short-term value to these apps; however, it appears that task killers are not necessary and in some cases do more harm than good. An additional 20 minutes of use or short bursts of freed RAM can be great, but users shouldn’t compromise experience and overall health of their device for that extra time.
Let me be clear in stating that apps like Advance Task Manager or TaskOS have great virtues like batch uninstall and app switching that many people can still benefit from using. With that said, it seems that constantly killing tasks, apps, and processes is not in the best interest of your phone. Android already has the natural ability to do this effectively, so let the phone do its job.