Minimize suspend/resume time (XAML)

The Windows 8 process lifetime system can suspend or terminate an app for a variety of reasons. This process is designed to quickly return an app to the state it was in before it was suspended or terminated. When done well, the user won’t be aware that the app ever stopped running. Here are a few tricks that your Windows Store app using C++, C#, or Visual Basic for Windows 8 can use to help the system streamline transitions in an app’s lifetime.

Avoid unnecessary termination

An app can be suspended when the user moves it to the background or when the system enters a low power state. When the app is being suspended, it raises the suspending event and has up to 5 seconds to save its data. If the app's suspending event handler doesn't complete within 5 seconds, the system assumes the app has stopped responding and terminates it. A terminated app has to go through the long startup process again instead of being immediately loaded into memory when a user switches to it.

Serialize only when necessary

Many apps serialize all their data on suspension. If you only need to store a small amount of app settings data, however, you should use the LocalSettings store instead of serializing the data. Use serialization for larger amounts of data and for non-settings data.

When you do serialize your data, you should avoid reserializing if it hasn't changed. It takes extra time to serialize and save the data, plus extra time to read and deserialize it when the app is activated again. Instead, we recommend that the app determine if its state has actually changed, and if so, serialize and deserialize only the data that changed. A good way to ensure that this happens is to periodically serialize data in the background after it changes. When you use this technique, everything that needs to be serialized at suspension has already been saved so there is no work to do and an app suspends quickly.

Serializing data in C# and Visual Basic

The available choices of serialization technology for .NET apps are the System.Xml.Serialization.XmlSerializer, System.Runtime.Serialization.DataContractSerializer, and System.Runtime.Serialization.Json.DataContractJsonSerializer classes.

From a performance perspective, we recommend using the XmlSerializer class. The XmlSerializer has the lowest serialization and deserialization times, and maintains a low memory footprint. The XmlSerializer has few dependencies on the .NET framework; this means that compared with the other serialization technologies, fewer modules need to be loaded into your app to use the XmlSerializer.

Some app and item templates in Visual Studio generate a Common.SuspensionManager class that uses DataContractSerializer to save and restore session and navigation state. If you use these templates, you can use the SuspensionManager class to store small amounts of your own temporary session data.

DataContractSerializer makes it easier to serialize custom classes, although it has a larger performance impact than XmlSerializer. If you need better performance, consider switching. In general, you should not load more than one serializer, and you should prefer XmlSerializer unless you need the features of another serializer.

Reduce memory footprint

The system tries to keep as many suspended apps in memory as possible so that users can quickly and reliably switch between them. When an app is suspended and stays in the system's memory, it can quickly be brought to the foreground for the user to interact with, without having to display a splash screen or perform a lengthy load operation. If there aren't enough resources to keep an app in memory, the app is terminated. This makes memory management important for two reasons:

• Freeing as much memory as possible at suspension minimizes the chances that your app is terminated because of lack of resources while it’s suspended.
• Reducing the overall amount of memory your app uses reduces the chances that other apps are terminated while they are suspended.

Release resources

Certain objects, such as files and devices, occupy a large amount of memory. We recommend that during suspension, an app release handles to these objects and recreate them when needed. This is also a good time to purge any caches that won’t be valid when the app is resumed. An additional step the XAML framework runs on your behalf for C# and Visual Basic apps is garbage collection if it is necessary. This ensures any objects no longer referenced in app code are released.

Resume quickly

A suspended app can be resumed when the user moves it to the foreground or when the system comes out of a low power state. When an app is resumed from the suspended state, it continues from where it was when it was suspended. No app data is lost because it was stored in memory, even if the app was suspended for a long period of time.

Most apps don't need to handle the Resuming event. When your app is resumed, variables and objects have the exact same state they had when the app was suspended. Handle the Resuming event only if you need to update data or objects that might have changed between the time your app was suspended and when it was resumed such as: content (for example, update feed data), network connections that may have gone stale, or if you need to reacquire access to a device (for example, a webcam).