Optimize Startup Time

Optimize Startup Time

  • Comments 10
  • Likes

[This is the second in a five-part series on ways to help make your apps run better on lower-cost phones.--Ed.]

Fast startup is an essential component of any mobile application. It is the first impression a user has of your app and is the first chance you have to either impress or frustrate your users.

If you're wondering just how fast your startup time can get on Windows Phone, use the VS Project Templates as a starting point. Create a new project, deploy it to the device, and experience how quickly the app starts up.

A general principle to keep in mind is that any regressions in startup time from the VS Project Templates are the result of app code delaying the rendering of the first frame. The more app code you can remove or delay before the first frame is rendered, the closer your startup time will match the baseline startup time of the VS Project Templates.

To fully understand the areas of opportunity for improving startup time, it's important to understand the workflow of a launching application.

  1. The App constructor is called in App.xaml.cs.
  2. XAML in App.xaml is parsed.
  3. Application_Launching is called in App.xaml.cs.
  4. The Page constructor of your MainPage is called.
  5. XAML in your MainPage is parsed.
  6. OnNavigatedTo is called in your MainPage.

Once you understand this workflow, it is easy to conclude that any app code or XAML introduced in this workflow will result in startup time regressions from the VS Project Templates.

To minimize the impact of app code in this startup path, you should either remove code from these events or execute code on background threads to unblock the UI thread. Only code executing on the UI thread will have a severe impact on startup performance. Deferring activity to background threads will allow your first frame to render quickly. Use Dispatcher.BeginInvoke from background threads to return back to the UI thread when necessary.

To minimize the impact of XAML parsing on startup time, you can simplify and remove unnecessary XAML from both your MainPage and from App.xaml.

  1. Remove unnecessary namespaces declared in <phone:PhoneApplicationPage>.
    1. If your XAML elements aren't prefixed by a declared namespace, then the namespace declaration can be safely removed.
  2. Avoid explicit declarations of default attribute values.
    1. Grid.Row="0", for instance, is the default value if Grid.Row is not declared, so just don't declare it.
    2. SupportedOrientations="Portrait" and Orientation="Portrait" can be removed as well for portrait only pages since this is the default.
    3. Understand default values and remove redundant XAML.
  3. Avoid retemplating controls in App.xaml.
    1. Retemplating controls can require complex XAML which is expensive to parse.
    2. For Metro-style apps that are theme-aware, this is less of a concern. If you need to retemplate controls to support a branded experience, for instance, then understand what is necessary to override and what can be omitted.
    3. If templates are only needed for particular pages, consider moving the custom templates to the pages that need them. This will delay the cost of parsing the XAML until the necessary page is loaded rather than require the cost to be paid at startup.
  4. Normalize Style declarations.
    1. If you are consistently setting FontFamily, FontSize, and Foreground in a similar way on several TextBoxes, for instance, then consider using Styles instead.
  5. Simplify page layouts.
    1. Don't use nested Grids and StackPanels when one root container would be sufficient to layout your page.
  6. Declare your app bar in code.
    1. This will be faster to process than parsing the XAML and is actually the only way to localize your app bar components.

With your first frame rendered quickly, you can then turn your attention to indicating progress to the user while the rest of your content loads. Perceived startup time can go a long way to minimize the amount of frustration content load times can impose on users. The first frame of your app should always include the chrome of your application (system tray, app title, page title, pivot titles, app bar, etc.) as well as a ProgressIndicator to indicate that your content is loading. You'll want to use the ProgressIndicator over other progress bars as (1) the ProgressBar control has known performance issues and (2) the ProgressIndicator will provide the most consistent experience with the rest of the built-in experiences on the phone.

Note that the system tray and app bar are shell components and so will render more quickly than the content in your PhoneApplicationPage. You can take advantage of this to improve perceived startup time even further. You'll notice in the Weather app that the system tray and app bar appear first followed by the rest of the page content. If you're using the system tray ProgressIndicator as recommended above to indicate progress, it will appear as well immediately when the system tray is rendered.

A bonus to using both the system tray and app bar is that these components render together and provide a recognizable chrome for your app while it loads. Many apps hide the system tray and use only an app bar. If you've used these apps, you'll notice often that the app bar renders first before the rest of the content loads. The lack of symmetry in this case introduced by not showing the system tray actually contributes to the perception of lag that the user experiences. By adding the system tray, you can eliminate this perception while also providing a consistent chrome that is recognizable across apps. If you don't want to show the system tray but want to take advantage of it for the reasons mentioned above, show the system tray on launch with an opacity of 0. Using an opacity of 0 means the system tray won't affect your page layout at all. Once the rest of your content loads, you can then hide the system tray if you'd like.

Many apps use a splash screen to solve the perceived startup problem as it is cheap to implement and can promote the brand of the app. While this is a great practice, you may find that after following the guidance above, the splash screen will actually slow down your startup time. Adding a splash screen to the Weather app, for instance, would actually harm its startup performance. With your startup time optimized, assess whether a splash screen is really necessary. Your apps will actually feel more like integrated experiences if they don't use a splash screen, so don't be afraid to leave it off completely. The combination of fast startup time, no splash screen, and extensibility points like secondary tiles will really make your apps shine on Windows Phone.

Make sure to check out the other stories in this series:


You must be logged in to comment. Sign in or Join Now
  • JDB
    8 Posts

    What about localization, what's faster? a) add resource on App.xaml or b) name every string object on pages and set strings via code?

  • wp7Dave
    36 Posts


    I don't have any DataTemplates in the App.xaml, but was rather wondering if simplifying the MainPage.xaml would help.

  • @prelud: Welcome to Windows Phone. This is consistency of Start which means that any time you go to the start menu and click on an app it launches (same with the apps list). If you wish to switch to a running app, use the Back button (either short or long hold)

    @andyhammer: XAML parsing is always going to be slow (relative to simply creating a new instance of an object) as you're essentially parsing a string and using reflection to convert it into constructors and property settors. In it's compiled form it's slightly more efficient than this but you're still better off not setting properties with the default values.

    @BlackLightMagic: It's *always* worth going through and tuning for performance, again and again and again. You'll be surprised how much savings you'll get overall if you continuously refactor and improve the efficiency of your code.

    @ruysilva: You're referring to features that work "as designed". If you want to close IE, simply open another tab and then hit the back button. With music, it's designed to play in the background, but you can use the volume control to pause music to prevent battery drain. Most other applications are not "running" as such when in the background so aren't consuming battery life. There is no need to close apps that you're not using, just let the OS handle that side of things.

    @wpDave: I think the short answer is no - essentially in order to load the page that uses the listbox with the template or usercontrol it's still got to load the template. However, there may be some savings if you move the template out of the App.xaml and into the XAML for a page or user control.

  • wp7Dave
    36 Posts

    Would moving DataTemplate Layout's (example, for ListBoxes) to UserControls speed up or slow down application load time?

  • Good afternoon, is there any possibility to close the applications? eg when you are in internet explorer, to leave or you tap the home button and the application is running, or in the back and have to go back through all the pages where we sailed. In the music is equal, you have to put the music on pause and then the application is in standby, and the battery is over soon. Will the next software update this problem is solved?

  • @andyhammar - let me attempt to address your questions...

    the parsing is not necessarily slow, but writing out such assignments will cause the parsing of things that could have been left out. If it occurs once, it is negligable, but imagine you are restyling a lot of controls and showing a lot of things in your default page, that adds up to a non-trivial delay.

    When the XAML is being parsed it is true nothing is shown on screen, but nothing will be shown on screen till the XAML is parsed so if there is redundant XAML that will add to the wait time.

    I've never profiled to see if there are checks to see if the value is the same before assigning a value. Regardless of whether the controls just assign the value or perform these checks first, this code will be run unncecessarily. Those checks will add up - imagine the case of a twitter client showing 50 items, if there is redundant XAML in the template, this will be run a lot of times making the delay non-trivial; even if there are checks before assignment. If you don't specify a default value explicitly, the assignment won't be made, and as a result the check won't be made, and added up, this can be a significant boost to load performance.

    I hope that was helpful.

  • Hi,

    Great blog post. Do you have any metrics or rough idea of what the savings are in seconds/millisecondsfor each change. Particularly 1, 2 and 6. I have two very large apps and I want to know if its worth going through my apps and doing this.


  • How come it's faster to not override default properties with their default values?

    Is the XAML parsing that slow?

    When the XAML is parsed nothing is shown on screen anyway so no heavy methods are called anyway right? (Measure/Arrange)

    Also, does not the controls check and not sets the properties if the value is the same as the current?

    Thank you.

  • prelud
    9 Posts

    Consider the following flow: Launch an app (either from a tile or from the apps list). Hit the home button (win logo button). Now the app is available in the recent apps list when you hold the Back key, right? Now, tap the app's tile or icon in the apps list. One would expect the OS to switch directly to the "running" application, instead it launches a new instance of the application i.e. you get the splash screen and all. Why is that? This is totally counterintuitive and slow.

  • I wish that Nokia devs read that. All Nokia apps are the slowest to open.