How to identify and fix common performance issues using Windows Phone Application Analysis for Windows Phone 8

Article
11/23/2015

[ This article is for Windows Phone 8 developers. If you’re developing for Windows 10, see the latest documentation. ]

You can use the Windows Phone Application Analysis tool to identify performance issues with your app. After monitoring or profiling your app, you can highlight a section of interest on the timeline, such as an area with high CPU usage or a low frame rate, to display a detailed performance analysis of the selected section. Many of the performance warnings in the Application Analysis tool make the problem straightforward to investigate. For example, High CPU Usage for Operations Other Than Frame Drawing indicates that you need to take measures to unblock or unburden the UI thread so it can better handle frame drawing. However, the actions to be taken to investigate other warnings are less obvious. This topic describes how to use the Application Analysis tool to identify and fix some common performance issues.

This topic contains the following sections.

Improve animation performance

This section describes how identify and fix a common performance warning related to animations.

High frequency of cache invalidations due to animation of a cached UI element

A cache invalidation occurs when the cached version of an element becomes obsolete. A cache invalidation occurs because a change in the app state affects how the element should be displayed onscreen. When this kind of change occurs, the UI element and all of its child elements must be redrawn to reflect the state update. Also, it is important to note that during an animation, an update occurs every frame. Because the updates are so frequent, it is important that the updates caused by an animation are limited to the necessary UI elements.

To investigate the high cache invalidations warning

Click the arrow next to Performance Warnings and select Frames in the menu.

A list of all the frames rendered during the selected period in the timeline displays.
Click the CPU Time column header until the values are sorted by descending (highest to lowest) order.

This tells you the frames that used lots of CPU resources and indicates a high probability of frequent cache invalidations.
Select the frame with the highest CPU usage.
With the frame that has the most CPU usage selected, click the arrow next to Frames and select Cache Updates.

The UI elements that have the highest Measure Time, Arrange Time, or Texture Update Time are the elements that were updated when that frame rendered. High values for these columns indicate cache invalidations.
Return to the Frames view, and select the frame with the highest CPU usage.
Click the arrow next to Frames and select Visual Tree for Frame {x} in the menu.

The visual tree at the time of the frame’s rendering is displayed, together with every UI element’s resource usage.
Click the Total Draw Time (incl) column header until the values are sorted by descending order.

The UI elements that took the longest time to render during that frame update will be at the top. The elements are listed with the number of milliseconds spent rendering each UI element and all its children in the visual tree hierarchy. To determine which type is causing the element you identified in the Cache Updates report to constantly invalidate, find the element where the child elements do not account for a significant percentage of the draw time. This indicates the parent element caused the render delays.

Eliminate common unresponsive UI issues

This section describes how identify and fix some common performance warnings related to unresponsive UI.

Moderate / High CPU Usage on User Interface thread for Operations Other Than Frame Drawing

The Moderate / High CPU Usage on User Interface Thread for Operations Other Than Frame Drawing performance warning this indicates that you may need to unblock or unburden the UI thread. When you do this, it enables the UI thread to better handle frame drawing. Rewriting code to be more efficient can help, but the best solution is to move all operations that do not have direct interaction with UI elements onto their own thread. This way non-UI operations do not create a backlog on the UI thread, which bears the sole responsibility of rendering the user interface as efficiently as possible. For more information about threading in Windows Phone apps, see the Understanding Threads section of App performance considerations for Windows Phone 8.

Note

Code related to animation does not cause this particular performance warning, as the execution of an animation is considered a frame drawing operation by the Application Analysis tool.

To investigate high CPU usage on the UI thread

To investigate a high CPU usage warning, click the arrow next to Performance Warnings and then click Frames and then Functions in the menu.

The Functions view will be displayed. The Functions view shows every method that was called during the selected part of the timeline. These can be methods in platform code or app code.
Click the Inclusive Samples column header until the functions are sorted by these values in descending order (highest to lowest).
Look for methods that are part of your app code on the top of the list.

One or more the apps methods will likely be up at the top of the highly-sampled functions. This could, meaning you may be calling the method very often, or the method might be inefficient or take a long time to successfully execute. Either way, it is causing a UI block that is leading to a problem with the app’s responsiveness.
Optimize the code for that method or move it to non-UI thread.

Issues with high CPU usage due to redrawing content

You may see areas of the performance graph that indicate high CPU Usage, and possibly a low frame rate. The following image shows an example of this.

There are two warning that indicate issues with content redrawing too frequently that could lead responsive user interface (UI).

Low Frame Rate Due to High CPU Usage in Redrawing Content
Indicates UI elements are not being cached automatically. This is typically because of an overly complex visual tree (hierarchy of UI elements). The solution could be simplifying the visual tree, or reducing the amount of code that runs on each element in the visual tree during an animation.
High CPU Usage While Redrawing the Content
Indicates UI elements are not being cached automatically. This is typically because of an overly complex visual tree (hierarchy of UI elements). The solution could be simplifying the visual tree, or reducing the amount of code that runs on each element in the visual tree during an animation.

To investigate high CPU usage due to redrawing content

Click the arrow next to Performance Warnings and select Frames in the menu.

A list of all the frames rendered during the selected period in the timeline is displayed.
Click the CPU Time (ms) column header until the values are sorted by descending (highest to lowest) order.

This tells you the frames that relied most on the CPU while rendering.
Select the frame with the highest CPU time.
With the highest CPU frame selected, click the arrow next to Frames and select Visual Tree for Frame {x}.

The visual tree at the time of the frame’s rendering displays, along with every UI element’s resource usage.
Click the Total Draw Time (incl) column header until the values are sorted by descending order.

You can determine which UI elements that took the longest time to render during that frame update by observing the milliseconds spent rendering each UI element and all of its children in the visual tree hierarchy.
Look for an element with several child elements that take a long time to draw. This kind of element indicates a problem and you should consider simplifying the visual tree for that element.

If you simplify the visual tree for this element, it would mean fewer elements would need updating and caching during a frame redraw.
Search your solution for any code that is run when the element is updated, manipulated, or displayed, and once located, search for CPU-bound operations that can be omitted or made more efficient. If this is not possible, consider moving the execution of these functions to a thread of your own creation rather than the UI thread.