WhaleTech: Windows Phone “multi-tasking”

Via mshcdn.com

Via mshcdn.com

This is a real nerd post.  You might want to skip it if you’re not interested in the way Windows Phone manages its programs and memory use.

I see many people mention that they want to see “improved multitasking” in Windows Phone, and attribute the “Resuming…” and “Loading…” screens to a fault with the operating system being “slow at multitasking”.

I want to explain how multitasking works on WP…


To understand how this works, you need to know some of the internals. An app has a number of states it can be in, suchActiveDeactivated and Tombstoned.

  • Active means that the app is in the foreground and is the current in use app.
  • Deactivated means that the app is in the background but the OS has not killed it. It is still in memory.
  • Tombstoned means the deactivated app has been released from memory. A deactivated app is tombstoned when the OS decides it wants the memory the app is using.

I see many people use “Tombstoned” to describe apps that are merely deactivated. This makes sense as there is really no way to tell the difference. Tombstoned apps appear in the back-stack, along with apps that are deactivated, and can be navigated back to, just like deactivated apps. However, internally there is a big difference between the two states.


Apps have a number of events, and developers can have the app run certain actions when that event happens. Four such events are Application_LaunchingApplication_DeactivatedApplication_ActivatedApplication_Closing.

  • Launching is when the app is started from scratch
  • Deactivated is when the app is sent to the background (deactivated)
  • Activated is when a deactivated or tombstoned app is activated, eg. navigated to using the back button or the back-stack
  • Closing is when the app is closed by pressing the back button only page in the history to exit the app

Code that is run in the Launching event delays the main page being loaded, and the “Loading…” screen is displayed. Most apps avoid doing anything time-consuming in the Launching event and instead show a splash screen or their own custom loading screen while preparing the app.

Just as with Launching, any code in the Activated event delays resuming, and the “Resuming…” screen is shown. For example, an app may want to log a user in to a remote service during the Activated event, which may take a while over a slow connection. In this instance, the resuming screen will be displayed until that completes.

It is not the OS being “slow at multitasking”, that is the perception given by the app running code while it resumes. The OS resumes the app almost instantly, it’s the app that is slow. From the OS perspective, resuming an app that is tombstoned takes roughly the same time as launching the app to begin with.

The Activated event is run if the app is deactivated or tombstoned. If a deactivated app is resumed, there is very little initialisation that needs to be done, as it still mostly functions as if the app was never closed. An app that is being resumed after being tombstoned has more work to do to reinitialise.


Therefore, in theory, the resuming screen should only appear if the app was tombstoned, however many app developers perform no checks in the Activated event to see if the app needs to be reinitialised or not, and run the code no matter if the app was deactivated or tombstoned. Having the “resuming” screen appear every time for some apps, again, creates a perception that Windows Phone is slow at multitasking, when it is actually the app. (Developers can check the value of ActivatedEventArgs.IsApplicationInstancePreserved in the Activated event to determine if the app was tombstoned or deactivated).


Now, the question everyone is thinking: Why does iOS not have this problem?

Because iOS does not tombstone apps; it only deactivates them and then kills them. Therefore, iOS apps have barely any use for an equivalent of an Application_Activated event, and iOS apps resume instantly, exactly like Windows Phone apps that run no excess code in their Activated event.

When an application is sent to the background on iOS (eg. when the home button is pressed), it is preserved in memory, exactly like on Windows Phone. When iOS decides it wants the memory, it kills the app. The app does not preserve its state and cannot resume from where it left off. The next time the app is run — even if it is accessed from the multitasking bar — it starts from scratch (eg. shows a splash screen). If iOS worked like Windows Phone, that app would be tombstoned, and the next time it was started from the multitasking bar, it would recover its state (which takes time) and start from where you left off.


Now conjecture: which way is better, iOS or WP?

iOS’ way is cleaner and easier on developers. It also avoids developers running unnecessary code every time the app is navigated back to. However, it also creates a situation where sometimes an app will start from where you left off and sometimes it will start from scratch.

WP’s way is a bit messy and harder on developers to implement and get right, but it creates a somewhat consistent experience where, if you access the app from the navigation stack, the app should always resume from where you left off. Microsoft have tried to create the same sort of experience as on a PC, where when you open a minimized application from the taskbar it starts from where you were, but on a PC the application is maintained in memory the whole time, on lower memory devices like phones, this is not possible, hence the trickery in trying to emulate that experience.


Can Microsoft “fix” the perception of multitasking in WP? Maybe. There are a number of tricks they could do to cover up what is actually happening. Such as, silently screenshotting each app as it is deactivated and showing that screenshot in place of the Resuming screen, is one possible solution.


Source: AlwaysPaysHisDebts at reddit/WindowsPhone

Do you want:

  • Ad-free access?
  • Access to our very popular daily crossword?
  • Access to daily sudoku?
  • Access to Incite Politics magazine articles?
  • Access to podcasts?
  • Access to political polls?

Our subscribers’ financial support is the reason why we have been able to offer our latest service; Audio blogs. 

Click Here  to support us and watch the number of services grow.