Select a language to translate this page!
Powered by Microsoft® Translator
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:
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:
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.
Download the sample and documentation
I also want to thank Arik Poznanski who help (a lot) writing this paper…
Follow Windows Phone announcements on Twitter at WP7DEV
Follow Yochay on Twitter
Get started with free tools and free training
(Post edited by Barbara Alban)
I heard that the update to windowsphone 7 due in march will reduce application load times significantly.
What did you do.Do the developers have to optimize apps to take advantages of the changes?
Have any details to share?
@hdw - That would take an engineering blog like IEBlog or Engineering Windows 7, of which they seem to have none for WP7.
You can defer the loading of parts of your UI via the DeferredLoadContentControl:
Please note that the document in the download (zip) appears to still contain review notes on page 3. Is it the "marketplace ingestion process" or "marketplace testing"?
@Matt Lacey - Thanks updating this as I write...
I'm processing everything on my own background thread that manage a queue of operation (Download, Load, Process, Parse, Serialize, Deserialize). The only thing I'm still having issue with is related to the UI virtualization that request way too much of visual element to be build.
Ex: Let’s say we have a Pivot control having 4 pivot item and each pivot item containing a databinded listbox where each list box item contain text and a small image coming from the right source the cache (IsolatedStorage) or the server itself.
When the application start, a few pivot items will then be loaded that will trigger the load of the content of each listbox 's that will then load more than just the visible listbox item's on the screen that will trigger the load or the download of all those text and glyph.
Saying that, this also mean that I will have to implement data virtualization on my list of object. Or find out if there is more appropriate visual component.
Here a small video of my application : screencast.com/.../u2daShbpVf0F
Oh, I'm also concern about my background thread that manages a queue of operation since lots of those operations are asynchronous. Download mostly 30 small glyph at the same time may not be the best thing to do. Maybe I sould implement a sort of do not run more that 5 operation at the same time.