On mobile is there a reason why processes are often short lived and must persist their state explicitly?
- by Alexandre Jasmin
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.
