February 15, 2011

Windows Phone Silverlight Application Faster Load Time

Yochay Kiriaty

By design, your Windows Phone application should load and run (display something to the user) as soon as possible—not simply to comply with the Windows Phone Marketplace certification process, but primarily to ensure a better user experience. Users hate to wait for an application to load on their mobile devices. For example, if your application takes eight seconds to load, you can expect some user frustrations. While eight seconds may not sound like a lot of time, one of the Windows Phone Marketplace certification requirements is for your application to display something besides the built in Silverlight splash screen in no more than five seconds. If that is not a good enough reason for you to optimize your application’s load times, don’t forget that users can simply press the Start button and effectively exit your application before it completes its loading process.

This blog address such issues, and introduces the “Ways to Load Applications Faster” paper. It is not the usual Windows Phone Recipe, since we don’t have real code that can be used, but rather a set of steps to follow.

Even if your application loads in just a few seconds, this blog post and paper are a good read to gain a better understanding of the Windows Phone Silverlight Application loading time requirements.

Note: Application startup is also discussed in Performance Considerations in Applications for Windows Phone. That paper provides excellent background information and can help make your Windows Phone applications shine

A little background information please…

We can’t talk about proper loading techniques and optimizing application start-up time without explaining Windows Phone application lifetime events. I am not going to dive into the details of the Windows Phone execution model; for further information about this, please refer to the MSDN documentation, “Execution Model for Windows Phone” or read the Understanding the Windows Phone Application Execution Model, Tombstoning, Launcher and Choosers, and Few More Things That Are on the Way – Part 1, part 2 and part 3 series of blogs.

While I will not explain the Windows Phone Silverlight application execution model, I do need to provide some background about the problem we are trying to solve.

The Windows Phone Silverlight Application lifetime is governed by the Windows Phone operating system, and is exposed to you via four methods in the PhoneApplicationService class, which you can find in the Microsoft.Phone.Shell namespace. The four methods are: Application_Launching, Application_Activated, Application_Deactivated, and Application_Closing.

While these events play a critical role in your application loading (and closing) time, they are just half of the story. There is a certain sequence of methods that gets called during application launching, tombstoning, and returning from a tombstone state. It is critical to understand this sequence of methods in order to optimize your application load time.

Generally, when your application is launching or returning from a tombstone state, these methods are being executed in the following order:

Application constructor: App() found in App.xaml.cs
Application launching: Application_Launching found in App.xaml.cs
Your application’s “first page” constructor
Your application’s “first page” OnNavigatedTo method

Two important side notes: First, when returning from tombstone, the “first page” is actually the last page displayed by the application before the user navigated away from the application, and therefore not necessarily the actual first page of the application. Second, if your application was not tombstoned, the Application constructor and the Page constructor are not executed. Just keep that information in mind as we present the loading time problem.

There are two more terms we need to define before we can explain the actual problem:

Application Startup time – Includes launching or returning to a tombstoned application. It is defined as the time from when your application process started executing until your application becomes active or visible. Your application becomes visible only after the execution of the first page the application navigates to OnNavigatedTo method ends. Until then the application’s splash screen is displayed and the application is not considered active.
Application Shutdown time – Includes deactivating and exiting from the application, and mostly consists of the time from which the forward navigation was invoked until the Deactivated or Closing methods execution ends.

Windows Phone gives your application 10 seconds of “real world clock time” (not actual 10 second of CPU time) to load your application. Windows Phone Marketplace certification requirements further limit your application’s allowable load time to about 5 seconds. Therefore, it is important for you to get your load time under control.

So what is exactly the problem?

Imagine that your application needs to load some content from the web, and you have to display the content on the application’s first page. Making the web request as part of the page constructor or OnNavigatedTo method looks like a good idea. Well, what if the network connection is spotty, and the outbound IO (a web request is an IO operation) is delayed and you are blocked? Another example could be a game, for which you might want to run a long calculation during the game load time. Sometime, you simply need to read a lot of content from disk (like a dictionary application), and it takes more than 10 seconds. In all these scenarios, and others, you need to find ways to optimize your load time.

The recipe includes code samples that show slow load times. The sample also shows that no matter where in the Startup methods sequence you put your work load, as long as it is in any of the four methods mentioned above, your application load time can become a major problem.

You can demonstrate this by downloading the recipe, opening the solution using Visual Studio, and un-commenting any line of code that has the // Simulate workload Comment.

When you run the sample on a real phone (not the emulator) in release mode (so the debugger is not attached) the application will start loading, you’ll see the splash screen, and then after about 10 or 11 seconds, the phone will display the Start screen. What just happened? Well, Windows Phone killed your application since it took too long to load.

How can I solve the long load time problem?

If your application load time is longer than 5 seconds, you seriously need to consider optimizing the load time. There are few steps that will guarantee improvements in your application load time.

Any Windows Phone Silverlight application has a default splash screen. Make sure to use it, but change it to reflect your application theme. It may not help your app loading time, but it will at least give the user the sense that something is happening.

The next step is to defer any work that is not critical. You need to look into your code and figure out what workloads are not critical for loading your application. This can be a little tricky, but the idea is to look for any work that is not related to the user experience on the application’s first page. Your goal is for your code to complete the launching method sequence as soon as possible. On the same note, always prefer the lazy loading pattern for your objects over initiating objects during the application’s start-up time.

Sometimes, you simply can’t defer the workload to a later time and you need to load your application’s content when the application launches. And since you want your code to complete the launch methods sequence as soon as possible, you’ll want to execute your workload on a background thread. There are a few techniques for using a background thread and they are all described in the recipe.

If you do go down the path of using background threads, you’ll need to present something to the user. Now your application loads quickly, but you might be waiting for the background thread to complete its work, and until the thread completes its work you might not have any content to display. Therefore, if you start some work on a background thread, you should consider showing a busy / loading indicator in the form of a progress bar, some other animation, or even a short video during the time you wait for the background thread to complete its work. Jeff Wilcox has a very good blog post on Windows Phone loading bar animation.

Another important aspect to remember is the actual and perceived user experience. There is more than one way to show loading progress than a progress bar, but it is important to show something that is meaningful and tells the user, “Hey, soon you’ll see your favorite app.

Windows Phone applications must load quickly and provide a good user experience. This is enforced by the application certification process as well as the operating system. While the sample provided in the recipe is rather simple, the concepts remain true for any Windows Phone application, and the techniques explained here will work for any Windows Phone application.