How multitasking really works on Android and iOS | Hacker News Reader

How multitasking really works on Android and iOS

extremetech.com

46 pointsllambda27 comments

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

>they're just cleared from RAM

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

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

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

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.

pretty much, I think you can do anything you want in an android service. with iphone you can't run arbitrary code indefinitely, you can only run specific api calls.

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

Others mentioned it, "Staying alive" is indeed not regulated for services nor for activities on Android. It is however strongly recommended to make Services terminate themselves when they are done and instead use the AlarmManager service for handling periodic background tasks. The idea is that the AlarmManager syndicates all periodic tasks and performs then in batches to minimize battery consumption and maximize sleep mode.

Emphasis on "recommended"...

Anyway there are a lot of technical things to say about the Android Multitasking System. Of course, there is the whole application lifecycle thing that the article mentions, and the Service object that others mentioned, but then again your intuition is spot on: it's roughly the same mechanism on iOS and Android. The key difference for Android is that it's the exact same mechanism that is used to navigate between screens of an app and to navigate from one app to the other, and this mechanism is the Intent system. Its main problem is that it's apparently hard to vulgarize it for marketing people.

Let's look at it that way: I tell the phone "show my inbox", the phone looks up a list of apps that declared that they can "show" an "inbox", and checks if they have access to "my" inbox. Once it resolved a list of eligible applications, it executes it using the Intent as unique call parameter. If the executable is a Service, it starts code in the background. If the executable is an Activity, it brings its Screen to the front and updates its content using the Intent's parameters. In our case, it shows the inbox of the user. If the Activity was still in memory, it doesn't create a new one but rather reuses the same and just updates the content. This is essentially the system that allows the "Back" button to work seamlessly, since the history is nothing but a stack of Intent objects, each with enough information to recreate the whole screen from scratch, or just update the content back to what it was before.

The AlarmManager system I mentioned above works the same way: when you register an alarm, you put an Intent in front of a Date. When the Date comes, the Intent is fired, the OS resolves the corresponding Application, Activity or Service and starts it.

In the end, Multitasking in iOs is exactly the same as multitasking in Android, but with an added regulation on what can stay really alive and for how long - the main difference is that the whole Android OS is designed on top of a system that allows launch arguments and contexts to be stored and passed around seamlessly at high speed. The result is why the article author said "multitasks like a boss".

For the end user, the only visible difference is that Android has a Back button. Oh, and that his battery life is in the hands of app developers rather than Apple.

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.

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

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.

this does seem to be the behaviour on iOS, which leads me to believe that "x'ing it out" does actually free up memory.

on android before ICS there was no way to remove apps from the recent list, but you could shut down an app from the app management in settings.

i'm not sure if android 4's swiping apps away on the recent list "closes" them in a similar way to the android <= 3's app management "close app" button? anyone else able to verify?

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

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.

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.

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.

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.

> In reality, they may not be dead/suspended

Hence "likely".

> Google Latitude for example can 'run' (I'm not actually sure what code is executed, if any) even after being removed from the 'tray'.

That simply is not possible, once it's been removed from the switcher it can not be running unless it's the currently active application.

Furthermore location-aware applications are actually the easiest possible offenders to manage: they'll keep the location marker enabled in the status bar (although that can conflict with genuine users of the API such as Reminders) and they will appear with a purple arrow in Settings > Location Services.

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.

Hm, works just fine on my Galaxy Nexus.

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.

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

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.

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

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.

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?

Take a look at http://cryopid.berlios.de/

I've never used it before, but it seems to do what you want.

Edit: You might also want to take a look at http://checkpointing.org/ as well.

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.

Reply on news.ycombinator.com