Windows Phone 7: The AnandTech Guide

Platform Architecture, Multitasking, and User Experience

There's a bit of confusion circulating around what form background processing or "multitasking" exists in on Phone 7 Series. A distinction needs to be made about multitasking at the OS level, background processing from the point of view of a standard marketplace-installed application, and multitasking as presented to the end user. To fully understand the situation, we need to talk about the software architecture. Let's dive into the details.

In the new-age of smartphone operating systems, WP7S' software architecture is completely unfamiliar. This is the managed, sandboxed architecture common to both iPhone OS and Android thus far. Gone are the close to metal compiled executables known to Windows Mobile developers. This time, virtually every experience runs atop either Silverlight or XML frameworks, or as HTML/JavaScript in the browser (though web-applications are still largely a cop-out).

WP7S' Software Architecture

First off, WP7S itself is a fully fledged multitasking operating system. Applications are called "sessions," and inside each session are other processes, called "pages." WP7S uses a state-based model to allow pages to be restored to the state they were at previously. When you leave a particular page or session, WP7S generally leaves the process running, until the dominant page with focus requests resources that require the old page to be terminated. At this point, the state of the prior page is saved temporarily. This process is called "dehydrating" the application. When you return, the page is "rehydrated" with the state data from before, allowing you to return:

The infamous slide illustrating state-saving, and suspended process killing

But the other side of the story is that a select number of first-party applications are allowed to be persistent, and truly run in the background. These are specific use scenarios that have been highlighted which Microsoft believes make sense. Those include loading a website in the background, playing music from the first party Zune music player, and allowing the phone to continue in the background. Other third-party applications, however, can be killed after suspension.

So the WP7S platform itself supports simultaneous process multitasking, but not for marketplace-installed third party applications. It's as simple as Charlie Kindel put it, "in this release, you cannot write code that will run in the background." So although multitasking is there, it isn't something that will be made accessable to third party developers. If you don't believe me, check out this demo screenshot from Istvan Cseri's awesome WP7S architecture deep dive presentation:

Two sessions, three pages, all running. Multitasking is there, you just can't use it. Yet.

It's even more compelling to see it in real time:

I asked Istvan after his demonstration flat-out whether there was any way that third party devs could enable multitasking for their programs. Be that setting a flag for persistent background execution, obtaining certification through additional marketplace vetting, or a lightweight executable. Pandora has become the perfect example of the kind of multitasking users pine for; streaming radio running in the background, with the same persistence as the first-party music player. I asked whether this use scenario would be possible on the WP7S platform scheduled for release holiday 2010. The answer was as clear as it was disappointing: no.

So you're probably wondering, why can't third party developers write applications that run persistently in the background? For now, it's because Microsoft isn't sure how to allow it without the potential for battery-draining to happen. Power users like AnandTech readers are able to make the distinction between a dead battery caused by the platform being poorly written, and poor battery life caused by running an application in the background. But ultimately, Microsoft is worried that your average end user won't see the distinction, instead faulting the entire platform as having poor battery life and power management.

Charlie Kindel, Microsoft's leading Windows Phone 7 Series evangelist, shared an anecdote several times about how a leading competitor's phone allowed for implicit multitasking (leaving applications running unless explicitly closed) which led to a poor end user experience, and dead battery for his daughter.

If you've ever used a Windows Mobile phone, you're probably completely familiar with that scenario. And it goes beyond just battery life; there's also the question of how best to allocate resources when other things are using CPU cycles and memory in the background. That kind of gradually-degrading performance is another Windows Mobile-ism Microsoft is dead serious about not letting happen. There's also the fact that existing SoCs are barely powerful enough to make running a single application feel quick. It won't be until we get multicore Cortex A9 or Intel Moorestown class hardware before we have the horsepower to multitask without a tangible performance impact.

I pitched an idea to Andre that he seemed receptive to while we talked about the reaction tech community had to the no third party multitasking announcement. As it stands now, multitasking isn't being included almost entirely as a design decision; Microsoft wants to get it right the first time so that the end user, out-of-box experience isn't like the one Charlie Kindel's daughter had. Its concern is that the lowest common denominator of users will attribute the rapid decrease in battery life to a platform or hardware problem, not just the sad reality of how quickly constant radio traffic and access to the audio stack can drain the battery.

What I argued is that users need to be empowered to make the decision between unitasking and multitasking themselves. They need a clear and obvious visualization about what the current power demands on the hardware are, and a prediction of how long the device will last based on that current use scenario. The analogous comparison is so obvious, I'm surprised nobody has made it yet: the laptop. For years now, users have been given direct control over whether they want to sacrifice battery life for performance, or performance for battery life. The obvious next step is to both extend this profile-based decision making to the mobile phone, and the problem will solve itself. I argue that if notebook users can do it and fully comprehend it, mobile phone users can as well.

Users already are forced to shape their expectations for both call quality and data throughput based on cellular signal visualizations (a far more nebulous metric than an unambiguous power report from the hardware). I argued that this same visualization and feedback should be passed onto the user for battery life and power draw so they can shape expectations and make decisions about what's best for them. Andre said he'd pass my thoughts on. It could be that this generation of ARM hardware doesn't have the metal taped-out to report power use in realtime, but in time, its offerings (and offerings from intel) must. Even then, it isn't as simple as enabling power reporting on the SoC, carriers think they know what's best for the user and are eager to value-add with their own performance and battery targets. It will be an uphill battle to wrangle control out of their hands, and into users'.