[Android General] LordManhattan:
I find it quite funny that not a single person here can tell why Android's multitasking is "better" than iOS' multitasking, and how it's true multitasking and iOS' is not (Spoiler: It's not).

iOS​

iOS apps can exist in any of five states of execution. These are:

Not Running: The app has been terminated or has not been launched.

Inactive: The app is in the foreground but not receiving events (for example, the user has locked the device with the app active).

Active: The normal state of “in use” for an app.

Background: The app is no longer on-screen but is still executing code.

Suspended: The app is still resident in memory but is not executing code.

When you press the home button, the app moves from Active to Background. Most apps usually then go from Background to Suspended in a matter of seconds. (Suspended apps remain in the device’s memory. This is so they can resume more quickly when you go back to them. They’re not using processor time and they’re not sucking battery power.)

You may think that if an app is resident in memory, you might have to remove it manually in order to conserve memory. But you don’t: iOS does it for you. If you launch a memory-intensive app such as a game, iOS will start to purge Suspended apps from memory and move them to the Not Running state. That is, they will be completely removed from memory and will launch afresh the next time you tap their icon.

Here’s the confusing part: None of these states are reflected in the multitasking bar. That bar always shows a list of recently used apps, regardless of whether they’re in the Background, Suspended, or Not Running states. (You may also have noticed that the app that is currently Active does not appear in the multitasking bar.)

Android​

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).

It is useful to think of an application in Android having three "lifetimes" associated with the preceding diagram and table

The Entire Lifetime: the period between the first call to onCreate() to a single final call to onDestroy(). We may think of this as the time between setting up the initial global state for the app in onCreate() and the release of all resources associated with the app in onDestroy().

The Visible Lifetime: The period between a call to onStart() until a corresponding call to onStop(). Although this is termed the "visible lifetime", the app may not be directly visible and interacting with the user at any one time if it is not in the foreground. The feature that distinguishes this lifetime is that, even if not in the foreground, the app maintains resources such that it can instantaneously return to the foreground.

The Foreground Lifetime: The period between a call to onResume() until a corresponding call to onPause(). During foreground lifetime the activity is in front of all other activities and interacting with the user.

This multitasking capability is part of what makes Android devices quite nimble, with apps often appearing to load and initialize much faster than for the iPhone. However, as with all good things there is a price: the developer must remember that just because you execute a finish() command in your app does not mean that it is no longer running. It is very likely still in the background in a paused or stopped state if the device is not overtaxed for resources. This means that as a programmer you have to be careful that an app not in the foreground is not consuming valuable system resources to no useful end. For example, various features of the device like the GPS or cameras can consume power rapidly, so a poorly written app can lead to very short battery life for the device, and an unhappy user.

Sources:

- Android

- iOS

And while we're at it, here's why Android's UI will never be as smooth as iOS.

"We’ll start off with Google engineer Dianne Hackborn’s post. She states that hardware acceleration – i.e. using the GPU, instead of CPU alone, to render the user-interface – has existed on Android since version 1.0 for things such as sliding the notification bar, pop-up dialogues etc. Full hardware acceleration only came with Android 3.0 Honeycomb and, unsurprisingly, Android 4.0 Ice Cream Sandwich actually has the same kind of hardware acceleration and this won’t necessarily sweeten things up.

Hackborn states that hardware acceleration “is not all full of win” since it takes away a lot of RAM when used for devices like Nexus S, Galaxy Nexus with OpenGL. Each process takes about 8MB of RAM and “isn’t worth it” considering the minimal effect it has on how “smooth” the UI looks after implementing it. So yes, hardware acceleration certainly helps, but it takes far too much processing power for it to be implemented to all parts of the UI.

She ends her post on how full, complete, A-to-Z hardware acceleration that results in 60 frames-per-second graphics is simply not possible, even with powerful chips like the Tegra 2.

Now, the question arises: why is it that even seemingly outdated phones like the iPhone 3GS offer a smoother UI than the latest Android smartphones? iOS uses hardware acceleration and that too on weaker hardware. How does Apple’s engineers manage to pull it off, then? Why can’t Google do the same?

That has been answered by Andrew Munn – software engineering student, ex-intern at Google and future intern with Windows Phone 7 team at Microsoft – who states that UI rendering processes in iOS occur with dedicated threads with real-time priority whereas on Android, UI rendering processes occur along with the main thread with normal priority. Whenever an iOS devices detects touch, it stops other processes and focuses all attention to rendering the UI. Android devices don’t do this, instead general processing and UI rendering occurs concurrently which results in choppy UI."

Source: RedmondPie