How important is it for a mobile device to support background multitasking?
Specifically, how important is it that users can install, onto the device, applications which will continue to run well in background whilst the user is simultaneously using the device for another purpose?
Humans are multitasking creatures. We get involved in many activities simultaneously: listening to music, browsing the web, holding conversations, taking notes, staying on the alert for interruptions… – so shouldn’t our mobile devices support this model of working?
One argument is that this feature is not important. That’s because the Apple iPhone fails to offer it, and the sales of the iPhone don’t seem to have suffered as a result. The applications built into the iPhone continue to operate in background, but downloaded apps don’t. iPhone apps continue to sell well. Conclusion: mobile multitasking has little importance in the real world. Right?
But that’s a weak argument. Customer sentiment can change. If users start talking about use cases which the iPhone fails to support – and which other smartphones support well – then public perception of the fitness of the iPhone system software could suffer a significant downturn. (“iPhone apps – they’re so 2009…”)
How about Android? That offers background multitasking. But does it do it well?
My former colleague Brendan Donegan has been putting an Android phone to serious use, and has noticed some problems in how it works. He has reported his findings in a series of tweets:
I say, with all honesty that Android’s multitasking is a huge travesty. Doesn’t even deserve to be called that
Poor prioritisation of tasks. Exemplar use-case – Spotify [music playing app] + camera
Spotify will jitter and the photo will be taken out of sync with flash, giving a whited out image
Symbian of course handles the same use case flawlessly
Android really is just not up to doing more than one ‘intensive’ task at a time
Even the [built-in] Android music player skips when taking a photo
(Brendan has some positive remarks about his Android phone too, by the way.)
Mark Wilcox suggests a diagnosis:
sounds like the non-real-time, high interrupt latency on Linux is causing some problems in multimedia use cases
Personally, I find this discussion fascinating – on both an architecture level and a usability level. I see a whole series of questions that need answers:
- Are these results applicable just to one Android phone, or are they intrinsic to the whole platform?
- Could these problems be fixed by fairly simple software modifications, or are they more deeply rooted?
- How do other mobile platforms handle similar use cases? What about feature phone platforms?
- How important is the use case of playing music in background, while taking a photograph? Are there other use cases that could come to be seen as more significant?
Perhaps this is a good topic for a university research project. Any takers?
(Related to this, it would be interesting to know more about the background processing abilities of modern feature phones. For example, it used to be the case that some feature phones would discard the contents of partially written text messages if there was an incoming voice call. Has anyone looked into this recently?)
Regardless of the merits of these particular use cases, I am convinced that software responsiveness is important. If the software system is tied up attending to task A when I want it to do task B, I’m frustrated. I don’t think I’m alone in this feeling.
My 1990’s Psion PDA typically runs more than a dozen apps in parallel (several word processors, spreadsheeets, databases, plus an individual agenda, tube map app, calculator, and so on) and switches instantly between them. That sets my baseline expectation.
Here’s another mobile use case that’s on my mind a lot these days. It applies, not to a PDA or mobile phone, but to my laptop. It’s not (I think) a device problem, but a wider system problem, involving network connectivity:
- I frequently find myself in mobile situations where I’m browsing websites on my laptop (for example, on the train), and the pages take ages to load;
- The signal indicator on the built-in wireless modem app says there’s a strong signal, but for some reason, wireless traffic is squeezed;
- I sit watching empty tabs on my Firefox browser, waiting and waiting and waiting for content to appear;
- In frustration, I’ll often open another tab, and try to visit the BBC website – to rule out the possibility that the server for the other web pages(s) has gone down – but that gives me another blank page;
- Eventually, things recover, but in the meantime, I’ve been left twiddling my thumbs.
When I switch to a WiFi connection instead of a cellular connection, things are usually better – though I’ve had the same bitter experience with some WiFi hotspots too (for example, in some Starbucks coffee shops).
So what should the highest priority be for system architects to optimise? Responsiveness comes high on my own wishlist. I recognise that this will often require changes in several parts of the software system.
dw2 
Hi David,
Thanks for taking an interest in this. I too am very curious whether this is as fundamental as Mark suggests. I would like to try similar use-cases on other devices, such as the N900 and possibly some feature phones.
I do plan to do a general posting about the experience with the Milestone on my personal blog, which will certainly mention this issue – but a lot more besides. Look out for it in about two weeks, once I finish with the trial.
Comment by Brendan Donegan — 10 February 2010 @ 12:00 pm
Lots of interesting and varied points in here…
1. Are these results applicable just to one Android phone, or are they intrinsic to the whole platform?
A combination of the two – for example, some hardware will sync flash with the taking of the picture automatically, others require a very precisely timed response from the processor, which is hard when you don’t have guaranteed low interrupt latency and are busy processing other interrupts from, say, the audio hardware (which also needs rapid servicing to avoid jitter).
2. Could these problems be fixed by fairly simple software modifications, or are they more deeply rooted?
Some are fairly deeply rooted (there are “soft real-time” patches for Linux which help with things like audio and video processing but they won’t resolve everything) whereas others could be solved by restructuring where processing gets done – for example moving any intensive processing out of the kernel context (i.e. not in the driver!) and prioritising it appropriately. Most could be solved by choosing appropriate hardware for the capabilities of the software, or vice-versa.
3. How do other mobile platforms handle similar use cases? What about feature phone platforms?
Feature phone platforms typically have no problem with this variety of multi-tasking, since they have RTOS’s at the core, however this also stops them supporting native 3rd party apps, so you’d never be running a service like Spotify in the first place…
4. How important is the use case of playing music in background, while taking a photograph? Are there other use cases that could come to be seen as more significant?
Some people have music playing in the background all day. For them it’s pretty important. However, knowing the problem exists, this could trivially be solved by pausing the music while the camera focuses…
There are far more significant use cases of this type but most of them would only matter when the cellular stack is running on the same processor as the applications, and Symbian’s the only smartphone platform that really supports that.
I expect the gaming + music use case to be far more popular, if not more important, than the photo + music use case.
I share your frustration with on-train mobile internet access. I strongly suspect this is actually the mobile network. I use Joikuspot for the same thing, so can see what’s going on with the data connection. The HSDPA coverage outside big cities is really poor. Your signal can be really strong, but if you’re in an umbrella cell (for the high speed train) with only GPRS or EDGE coverage, you’ll probably only get one timeslot and in fact just a really, really slow connection. Add some increased packet loss for the difficult RF environment and your connection slows to an absolute crawl – then you move into a cell with 3G or HSPA support again and everything recovers as if by magic.
Another issue when on the move is that you occasionally get a new IP address (as evidenced by Joikuspot free edition taking you to the store page again) at a cell handover – don’t know why this happens, some kind of internal network stucture? This does tend to confuse all of your existing TCP/IP connections in the browser! You then end up waiting over a minute for them to time out naturally and re-connect to the servers.
Poor public wifi is usually just too many users disrupting the wireless links and sharing some cheap low-bandwidth backhaul.
In two out of three cases, I suspect these are infrastructure investment problems rather than system architecture issues. For the new IP address case, there is certainly something that can be done with the system architecture to better optimise for responsiveness while mobile.
Comment by Mark Wilcox — 10 February 2010 @ 12:41 pm
I’d like to point out that I’ve also done this use-case with Androids built in music player and similar jitter happens, so it’s not just Spotify. As for the gaming + music use case, this is an interesting one; I would really like to listen to Spotify while playing a game of Tower Defense (a free download from the Android market, oh how I wish Symbian had free games like this) but it’s just not possible. Both the game and the music slow down to unusable rates – multitasking in this way is practically pointless. If I use the built in player then it’s fine – but I expect a growing number of people are using streaming services (whether online, or offline like I am) so it’s not really a valid counter argument to say ‘oh well just use the built in player then’.
Comment by Brendan Donegan — 10 February 2010 @ 12:51 pm
Tower Defense is no longer free.
Comment by ruabelk — 27 November 2010 @ 7:33 pm
I don’t know for sure, but my guess is that Spotify is very CPU intensive as music players go, particularly on Android. For the desktop at least, Spotify use Ogg Vorbis – decoding that in Java would be very CPU hungry (if they do). They also have their own DRM solution, which will probably mean doing their decryption in Java…
The built-in player should just be letting the system DMA unencrypted music from the file system to the audio DSP – hardly any CPU usage at all.
Comment by Mark Wilcox — 10 February 2010 @ 12:56 pm
I wouldn’t be at all surprised if the Spotify folks aren’t using the new Native Development kit for doing Ogg Vorbis decoding, and content decryption as part of LibSpotify.
Comment by Tyson Key — 16 February 2010 @ 1:26 pm
Hi David,
Your post explained some of my own behavior.
Responsiveness is up high on my personal list of non-functional requirements when choosing or using devices. I tried an iPhone for 15mins and got fed up already with the one-app-at-the-time limitation. I stick to my Blackberry 8520 instead, as it is very predictable on responsiveness, no matter how many extra Google and other stuff I add to it.
Same thing for laptops, I tried several different brands and formats. I tried the small sized Windows XP (3 of them), but stored them away somewhere since the performance was so slow when trying to do 2 or 3 things at a time. Now I use some Compag laptop, but prefer my desktop at home, since it never locks up when switching tabs in my browser.
Conclusion is that only devices offering multi-tasking and predictable responsiveness survive in my personal tool box …
Off course I was one of the many enthusiastic Psion users, and I think I was spoiled back then 🙂
Comment by Bart Hansen — 10 February 2010 @ 1:12 pm
So the two most popular smartphone platforms in the world both support multitasking and support it well. But somehow people come to the conclusion that it’s not needed because one very popular device does not support it.
Comment by Brendan Donegan — 10 February 2010 @ 1:31 pm
Oh, by the way – it has been rumoured that Windows 7 will not support true multitasking either. Rather, background apps will be ‘suspended’. If this is true then Microsoft seem to be following the false logic you described in the first paragraph.
Comment by Brendan Donegan — 10 February 2010 @ 1:23 pm
I think it’s fair at one level to call out Android on this issue, but it’s also unfair to not mention to manufacturer of said Android devices. That does matter.
I’d leave it up to the individual user to consider whether it’s a worthwhile use case or not. For myself, it seems rather irrelevant but if *you* want it – that’s up to you, it’s a free market.
Hardware adaptation and the role of the manufacturer should be presented as potential issues. For hardware both in terms of physical integration i.e. choice of components, SoC etc and then the adaptation software itself we know that bad choices and implementation in this domain will bring low any multimedia intensive use case. Further to driving these choices the manufacturer is also obviously responsible for the thoroughness of their QA too.
The fact is that Symbian OS or Linux/Android might not have a particularly large role in this particular issue – we’ve seem too many bad Symbian devices to prove this haven’t we? 😉
Another interesting factor here IMO is how easily could one research the effect of this in the Android space compared to Symbian? To my eye it is typically easier to obtain the source for h/w adaptations for Android than it is for Symbian, though I would strongly caveat whether one could obtain the complete adaptation.
Comment by tl — 10 February 2010 @ 3:57 pm
I’ve thought about this a bit. Researching the difference in Android vs Symbian in this area objectively is almost impossible at present (and possibly always will be). Even if you took a completely common hardware platform, the adaptation would be very different. You could get one person or group to do the adaptation and keep working on it until these issues are resolved, and see which takes most effort, but even that would depend on the ability and experience of the individuals involved quite heavily.
I think the best we’ll get is statistical results – how many devices based on platform X have problems of type Y. As a scientific method this suffers badly from bias introduced by the split in companies (and teams within companies) producing products based on certain platforms.
Comment by Mark Wilcox — 10 February 2010 @ 4:18 pm
Psion and Symbian spent enormous amounts of saliva, grey matter, money and were subjected to a lot of kicking and bashing from non Epoc developers in trying to train developers not to use polling and tight loops on something that runs on batteries. We struggled to explain and convince about the merits of event driven application development etc etc etc.
Rather than doing so, Apple went with the flow and enabled desktop developers to bring their wares on a mobile device and provided them with great tools to do so. They made this transition delightful and natural….but as a matter of policy they forbid them from running their apps on the background. The ‘while(true) { do something}’ has always been the enemy and they fended this one by matters of policy. I’m sure they will change this in upcoming releases of their SDK as they will train and police them of course.
Comment by John Pagonis — 12 February 2010 @ 11:02 am
On the subject of those empty tabs in Firefox and other blockages, the annoyance for me is having to jump through hoops to get an inkling of what’s really going on.
That’s sometimes compounded by the outright lie of a moving progress bar when there is actually no data flowing.
It shouldn’t be beyond the wit of application framework developers to provide the information you want to know – how fast is the data coming; is my system busy doing something else; is there local bandwidth available and so on.
In the past I think application designers often deliberately stifled this information in a misguided attempt to make the system look “simple”. Perhaps that idea remains and should be challenged.
Comment by Peter Jackson — 12 February 2010 @ 7:24 pm
[…] last very long in using this though for reasons which I tweeted about and which David Wood blogged about. To summarise, Spotify is basically impossible to use in combination with most other […]
Pingback by My experience with Android & the Motorola Droid/Milestone « YASB (Yet Another Symbian Blog) — 23 February 2010 @ 1:31 pm