7

Most mobile platforms (such as Android, iOS, Windows phone 7 and I believe the new WinRT) can kill inactive application processes under memory pressure. To prevent this from affecting the user experience applications are expected to save and restore their state as their process is killed and restarted.

Having application processes killed in this way makes the developers job harder.

On various occasions I've seen a mobile app that would:

  • Return to the welcome screen each time I switch back to it.
  • Crash when I switch back to it (possibly accessing some state that no longer exists after the process was killed)
  • Misbehave when I switch back to it (sometimes requiring a restart or tasks killer to fix)
  • Otherwise misbehave in some hard to reproduce way (e.g. android service killed and restarted at the wrong time)

I don't really understand why these mobile operating systems are designed to kill tasks in this way especially since it makes application development more difficult and error prone.

Desktop operating systems don't kill processes like that. They swap out unused pages of memory to mass storage. Is there a reason why the same approach isn't used on mobile? Mobile hardware is only a few years behind PC hardware in term of performance.

I'm sure there are very good reasons why mobile operating systems are designed this way. If you can point me to a paper or blog post that explain these reasons or can give me some insight I'd very much appreciate it.

Improve this question
8
  • 6
    There is no explanation for poorly written apps. I have only come across 3 - 4 apps out of the hundreds I have on my iPhone 3GS that misbehaved after "true multitasking" was introduced. They were updated quickly and I kept them, or they were never updated and got deleted from my device.
    – user7519
    Commented Jun 7, 2012 at 6:16
  • 1
    @Jarrod I'm not trying to justify poorly written apps but to give an idea of the pitfalls a mobile programmer can get into. It's not so hard to get right really but mobile can be harder to develop for than say Unix or Windows desktops for this reason. And I'm not sure I understand the rationale for this "explicitly serialize state and kill" approach used in mobile OS. This is a very common approach now but I don't get it. Why not transparently persist the process state (as in swap it out) instead putting the burden on the programmer? Is it demonstrably more efficient? I'd like some explanation
    – Alex Jasmin
    Commented Jun 7, 2012 at 6:54
  • 2
    So you essentially want your customers phone to start swapping?
    – user1249
    Commented Jun 7, 2012 at 8:09
  • @Thorbjørn Maybe. Perhaps in a more constrained way than on your typical PC. e.g. limit RAM per process and one foreground app a the time. Or perhaps find novel ways to tackle the problem. Right now it's all libraries and user code. I guess what I find strange is that I have to think about this process kill thing on a powerful tablet but this wasn't an issue on my old 486 PC. If this boil down to "we'd have to do swap but experience has show that swap sucks" I'm okay with it. But I was never really clear on the details so I though I'd ask.
    – Alex Jasmin
    Commented Jun 7, 2012 at 9:00
  • 7
    So, you want an infinite amount of swap space to persistently store app states in? You can't guarantee that the user will even have a memory card installed, so where do you propose that the state of an app that was loaded 23 hours ago, run for 30 seconds, and generated 2Mb of data is stored? Also, how much battery power will it take to, constantly move this information around?
    – Jamie Taylor
    Commented Jun 7, 2012 at 9:24

5 Answers 5

Reset to default
17

For most users the primary function of a smart phone is as a phone, followed by receiving text messages, and receiving e-mails. The designers of a smart phone OS must ensure that no application can interfere with these primary functions.

The other constraint of mobile is battery life, any app which "spins" in the background it will consume current and shorten battery life. The designers of a smart phone OS must ensure that any applications not being currently used are put to sleep so battery life can be extended.

Improve this answer
6
  • 3
    +1 for For most users the primary function of a smart phone is as a phone, followed by receiving text messages, and receiving e-mails.. Really.
    – Florian Margaine
    Commented Jun 7, 2012 at 7:26
  • 10
    "For most users the primary function of a smart phone is as a phone, followed by receiving text messages, and receiving e-mails." Do you have a reference for this? My experience when talking to people is pretty much the polar opposite, really; the smartphone is seen as a computer terminal, with telephony usage almost as an afterthought.
    – user
    Commented Jun 7, 2012 at 12:29
  • 1
    @Michael This was my impression as well but maybe we don't hang around normal people often enough. ;-)
    – Alex Jasmin
    Commented Jun 7, 2012 at 16:29
  • @michael Wait 'til the next time those people are at the scene of a car accident. Would they rather crash dialing out, or "Angry Birds?"
    – mjfgates
    Commented Jun 7, 2012 at 22:23
  • @AlexandreJasmin The modern normal seems to be texting. Phone versus other features is much more debatable, though.
    – Izkata
    Commented Jun 8, 2012 at 2:47
9
  • Battery life - many applications running in the background will drain your battery really fast.
  • Available memory
  • Processor
  • Small screen
  • Did I mention Battery life? :)

Here is an article about this feature on the Windows Phone Platform. It starts by explaining the reason why this it is a "necessary evil": Mobile Matters - Windows Phone 7 Tombstoning

A good mobile platform should acknowledge the hardware constraints that mobility imposes on the device. Compared to desktops, mobile devices have less memory, less processing power, limited screen real-estate and limited battery life. Add up these constraints and you should conclude that, on a non-dedicated device where many applications will run, applications will eventually be closed or shut down to make resources available to other applications...

Improve this answer
9
  • I don't know. Battery life seems mostly related to CPU usage and the OS could be design not to schedule your app process any CPU time (unless it is in the foreground or has to play background music or something). In fact I think that's already the case but nuking the processes seems a bit extreme just save CPU cycle (and thus battery). Doing it to save RAM may be more justified but still...
    – Alex Jasmin
    Commented Jun 7, 2012 at 7:34
  • 2
    @AlexandreJasmin typical RAM (random access memory) "eats" the battery at refreshes - persisting app gets rid of that. At PC, it is the same as at the phone, only less noticeable
    – gnat
    Commented Jun 7, 2012 at 7:49
  • 1
    @Silviu I was a bit confused by your Small screen point in relation to the question. But I guess it makes sense in that with a small screen there is no point in having more than one app running at a time.
    – Alex Jasmin
    Commented Jun 7, 2012 at 9:25
  • 1
    @AlexandreJasmin: Processes aren't simply nuked outright. Most mobile OSes that work on the "persist-your-state" model also work on a "prepare-to-be-nuked" model. They also don't kill off processes to save RAM, they do it because they're running out of it and would have to refuse to run something new. I've been developing for Android for a couple of years and don't see what the big deal is; it adds a small amount of code that isn't particularly complex, difficult to maintain or prone to errors.
    – Blrfl
    Commented Jun 7, 2012 at 12:15
  • 1
    Getting it right is what separates the professionals from the pikers. The docs say you have to do this if you want your stuff to work, so if the bugs go unnoticed it's because the software isn't getting tested or wasn't written correctly in the first place.
    – Blrfl
    Commented Jun 7, 2012 at 16:46
5

It's not an easy task to completely hibernate and awaken a process even on desktop OS. Apart from memory pages, processes need other resources to operate correctly -- network connections, local files, locks, semaphores etc. -- all kinds of kernel/user space objects that you need to consider. And the list is growing. I thinks this answers why the apps are required to handle the dump&restore issue themselves.

Hibernate a process in Linux question from StackOverflow

Improve this answer
1
  • Good point. Some of these kernel object could be made persistable I guess. But I can see the problem.
    – Alex Jasmin
    Commented Jun 7, 2012 at 9:52
2

So, you want an infinite amount of swap space to persistently store app states in? You can't guarantee that the user will even have a memory card installed, so where do you propose that the state of an app that was loaded 23 hours ago, run for 30 seconds, and generated 2Mb of data is stored?

Also, how much battery power will it take to, constantly move this information around?

Comparing mobile operating system design to desktop operating system design seems a little silly. I mean, with a desktop operating system you can (pretty much) guarantee that you have unlimited power, and (compared to smart phones) infinitely more memory and storage capacity.

I suppose the main problem with implementing traditional (desktop) multitasking on a smart phone is that we might end up with thrashing - when the storage/ram/swap runs low, which could lead to a kernel panic. this would be disastrous on a smart phone.

Improve this answer
1

Swapping goes some way towards fixing the problem, but it isn't necessarily a complete solution. Here are some reasons why you might not want to swap:

  • When swap space gets low, you would have to kill apps anyway, and deal with their potential bugginess. You could partially mitigate this by reserving some space on the flash for swap, but then you're taking that space away from users.
  • Some memory can't be swapped out. Which memory this is normally depends on the OS. One example might be a gallery application that uses hardware acceleration to scale photos - in that case, a sizeable portion of its memory might not be swappable because it's mapped into the GPU.
  • Swapping costs power and a bit of time (even if it's not very much), whereas killing apps would normally save power.

Another reason (although this is just speculation) might be that if you run out of swap and apps that normally behave well start misbehaving because you had to kill them, users will perceive that to be a problem with your OS. If some apps always misbehave because you kill them all the time and they can't handle it, users are more likely to see that as a bug in the app.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.