
How multitasking really works on Android and iOS - llambda
http://www.extremetech.com/computing/112013-how-multitasking-works-on-android-and-ios
======
masklinn
The iOS description is lacking, to say the least.

> When an iOS user hits the home button, an Active app moves to Background.

Not entirely correct, this is only for "multitasking-aware" applications: 1.
applications linked against the iPhoneOS3 SDK are not multitasking-aware; 2.
applications linked against the iOS4 (or 5) SDK can opt out of multitasking by
setting the `UIApplicationExitsOnSuspend` key.

Multitasking-unaware applications are killed when they leave foreground, they
do not get in the background and do not get suspended. They get a message
`applicationWillTerminate:` and are then killed.

> If the device needs more memory for a game or other large app, Suspended
> apps will be cleared from RAM.

Incomplete, _all_ non-foreground applications can be terminated and cleared
when the device is low on memory. The difference is priority, suspended
applications will be killed first (they're just cleared from RAM), then
backgrounded (but running) applications will be terminated if the device still
needs to reclaim memory.

> Apps are only allowed to remain Background tasks and run code for longer
> than a few seconds in specific circumstances

That's not quite true, Apple provides specific "infinitely-running" services
(location, GPS or cell; VOIP; music playing; as well as a local notification
system which allows applications to wake themselves up) but it also provides a
service called "Task Completion" which lets applications do whatever they want
for up to 10 minutes. Task completion has no "specific circumstances".

~~~
cma
>they're just cleared from RAM

Don't various sockets, file descriptors, and related buffers get freed as
well?

~~~
masklinn
As far as I know, that happens automatically when the process owning them is
killed. A suspended application is conceptually a process with priority 0

------
AshFurrow
"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."

This is the description of Android multitasking, but it's just as applicable
as a description of iOS multitasking.

You can't really talk about the benefits of Android multitasking over iOS
multitasking when you're describing the same thing.

~~~
lambada
Agreed. It seems to me (and my only experience of multitasking for iOS /
Android is from articles such as this) that the only difference is that the
API's for staying alive on Android aren't tightly regulated.

I may be mistaken, and if so please show me where I'm wrong.

~~~
masklinn
Android provides a "puzzle piece" which is not available in iOS in the form of
"services".

An Android application is composed of any number of Service components (0 or
more) and an Activity (I think this is optional, so a package can provide
services to third-party applications, see Bound Services[0]).

The Android "Activity" is what corresponds to an iOS Application: it's stuff
with an UI which the user can interact with. An activity can not "act" in the
background, if it's not visible it's frozen or dead.

A service, on the other hand, is headless (it has no UI). As a result, it has
no concept of "foreground" and "background", if it's been launched it runs
until it's been killed. I believe services also have little to no
restrictions.

In Android, background activity (for applications needing those) is generally
implemented via a dedicated service. These services can do _whatever they
want_ , which is a strict superset of Apple's limited set of backgrounding
APIs. A drawback is that, because services can implement arbitrary behavior,
it's harder for the OS to optimize them and it leaves them more open to abuse
or coding errors than iOS's (or WP7's) more limited multitasking provision.

tl;dr: Android offers pretty much full multitasking, iOS only offers a
limited, Apple-defined subset of it unless you jailbreak.

[0]
[http://developer.android.com/guide/topics/fundamentals/bound...](http://developer.android.com/guide/topics/fundamentals/bound-
services.html)

------
CmdrKrool
I have a game on my iPod Touch called "Scene It? Movies 2". If I start that up
while having too many other apps 'open', it shows me a dialog box saying, "Low
Memory Warning - The system memory is low. To improve performance, please quit
the game and then restart your device". Ever since seeing that, I've felt
obliged to remove every app (except perhaps the built-in ones) from the iOS
'task switcher' after I'm done with it.

The article says "If the device needs more memory for a game or other large
app, Suspended apps will be cleared from RAM", so what might Scene It be
complaining about? Perhaps it's about apps in 'Background' state (no wait,
masklinn has stated in this thread that /any/ non-foregrounded application can
be terminated to free up memory).

While Scene It is probably just a crappy app (and I don't play it anymore
anyway), I have to admit that I'm still unsure and I'm probably going to carry
on, reflexively, closing apps myself just to be sure, and because I'm a bit
OCD that way. Hooray for leaky abstractions.

~~~
irq
The main reason some iOS apps say this is because of how sensitive some iOS
apps are to low memory conditions.

It's true that iOS will automatically terminate non-foreground applications to
free RAM, however this process is not instantaneous. It's fast, but sometimes
all it takes is a few milliseconds for a poorly written memory-hungry app to
crash due to insufficient memory.

Another scenario poorly written iOS apps come into is being too aggressive
about memory allocation, which can trigger iOS to kill the app (which looks
like a crash to the end user).

Even well-written apps can run into this problem, especially on older devices
(only the iPhone 4, iPhone 4S and iPad2 have 512MB RAM. Everything else has
256MB or less.)

------
kokey
This doesn't explain one thing to me: If I have an app that is misbehaving,
and x it out from the 'recent apps list', when clicking on that app again it
will behave like the first time I'm using the app after boot. To me it looks
like it did kill the app.

~~~
masklinn
> To me it looks like it did kill the app.

On iOS it does. Removing an app from the "recent apps list" 1. removes it from
the list and 2. kills it if it was "alive" or suspended.

But because it's a "recent apps list", not a task switcher, most of the
applications in the list are likely either already dead or suspended (frozen
in memory with no CPU activity)

~~~
CraigRood
In reality, they may not be dead/suspended, and due to poor programming by the
developer it could be sitting there wasting resources (read: battery). This is
not acceptable.

Now, I know Apples current method of working with background apps is correct
(easiest for everyone). Apple does need to do something about it though.
Google Latitude for example can 'run' (I'm not actually sure what code is
executed, if any) even after being removed from the 'tray'. This all adds up
to a pretty shitty experience for those who have no idea on how all this
actually works, be it Apples fault or not.

~~~
glhaynes
Can you say more about the Google Latitude "continuing to run" thing? Are you
maybe just getting Push Notifications for Latitude? If so, they're entirely
handled by the system - the process doesn't need to be running.

~~~
CraigRood
I'm not an iOS developer (at least for now) so I'm not sure on the details
behind it all. All I know is Latitude (and other applications such as OkCupid)
can use the GPS and push data periodically - making a noticeable difference in
the battery life with no real indication besides the location settings details
beyond the setting menu.

It's fine for me, I can working it all out. But the average iPhone owner
can't. You would be surprised at how many dont even know about removing the
'tasks'. All usage adds up especially with the limited resources on a phone.

~~~
kokey
As I understand it, the iOS API for background tasks allows certain routines
to run in the background, in this case the regular sending out of location
data to Google. It doesn't let the Latitude app as a whole run in the
background.

------
MattBearman
Dare you to try view this site on an iPhone, it's unusable. The scrolling
jumps around all over the place instead of smoothly scrolling. I've seen this
mobile theme on a few sites, can't figure out how any one could possibly think
it's a good idea.

~~~
cellularmitosis
It's called OnSwipe, I think. I just hope extremetech didn't get swindled too
badly when they paid for that abomination. The onl thing worse than wasting
everyone's time is having to pay large amounts of money to do so.

------
spearo77
As a developer, testing the multitasking lifecycle of your app can be fairly
difficult. I'm surprised Android doesn't make it easier, especially on a
device (as opposed to the emulator).

For anyone interested in the hoops you have to jump through to force the
extended lifecycle situations on a device, check out a recent write up by Theo
at Bricolsoft – [http://bricolsoftconsulting.com/2011/12/23/how-to-test-
onsav...](http://bricolsoftconsulting.com/2011/12/23/how-to-test-
onsaveinstancestate-and-onrestoreinstancestate-on-a-real-device/)

------
Splines
Out of curiosity, is there a desktop OS that provides the same level of
"multitasking" application control? I mean, sometimes I want to minimize an
application and I'm not interested in it doing any work. In other words, I'd
like to "freeze" it at will.

~~~
glhaynes
Mac OS X Lion has a feature called "Automatic Termination" that kills
background processes (that support Automatic Termination) when the system
feels like it.

[http://arstechnica.com/apple/reviews/2011/07/mac-
os-x-10-7.a...](http://arstechnica.com/apple/reviews/2011/07/mac-
os-x-10-7.ars/8)

It's not under user control and it can be a bit wonky, but it's a sign of
where Mac OS X and iOS are becoming more alike.

~~~
Splines
Very interesting thanks for sharing that. I'm not an OS X user so I didn't
know about that one. As a Windows user this makes me jealous.

I've dabbled in Linux (Arch) but I'm not aware of a similar feature. Does one
exist?

~~~
gwillen
On both Linux and OS X, you can 'freeze' an app by sending it the old-style
unix signal SIGSTOP. I've done this before, and it sort-of-works, but it
doesn't tend to play very well with GUIs. If an app has a window up when you
SIGSTOP it, the window will hang until you send the app SIGCONT to continue.
And under OS X, at least, if you leave an app stopped for too long it seems to
make the rest of the GUI become unresponsive; so I wouldn't really recommend
it. But it's something you can experiment with.

