This documentation is archived and is not being maintained.
This documentation is archived and is not being maintained.
Windows Phone Application Analysis for Windows Phone 8
[ This article is for Windows Phone 8 developers. If you’re developing for Windows 10, see the latest documentation. ]
The Windows Phone Application Analysis tool is a monitoring and profiling tool to evaluate and improve the quality and performance of your Windows Phone apps. This tool lets you easily make quality assurance a part of the development cycle, and not just an afterthought. This topic provides an overview of the Application Analysis tool and describes how it can help you to improve the quality and performance of your Windows Phone apps.
The Application Analysis tool provides the following options:
App Monitoring. With the app monitoring option you can evaluate the most important behaviors of your app that contribute to a good user experience, such as start time and responsiveness.
To use app monitoring, you have to run your app on a Windows Phone 8 device or emulator. However, you can monitor apps that target Windows Phone 8 or Windows Phone OS 7.1. App monitoring is supported only for managed apps - you can’t monitor Direct3D apps.
If you want to create a successful Windows Phone app that users will enjoy, then you have to spend time to improve its quality and performance. Even if you have a great idea for an app, users will stop using it and will give it negative reviews if the app is slow, unresponsive, or crashes periodically.
In addition to creating a great user experience, Windows Phone apps must meet certain performance requirements to be published in the Windows Phone Store. For example, there are certification requirements regarding the following:
App launch time
Maximum memory usage by the app
You can use the Windows Phone Store Test Kit to identify some of these issues. However the Application Analysis tool helps you to identify, understand, and troubleshoot the source of these issues in your apps.
For more information about the requirements and tools discussed in this section, see the following topics:
The Application Analysis tool enables you to capture the most important measurements of app quality and performance while exercising its features as an ordinary user would use it.
The Application Analysis tool is installed as part of the Windows Phone SDK and is fully integrated into Visual Studio. Each time you run the Application Analysis tool, a file is created in the project folder that contains performance information for that session. When selected, the contents of the file are displayed within Visual Studio and show the results in a series of tables and graphs that contain additional information.
You can run app analysis while running your app in the emulator or on a phone.
The following illustration shows the options that are available when you launch Windows Phone Performance Analysis.
Typically you stop an analysis session by clicking End Session. However an analysis session is also interrupted when one of the following conditions is true:
If you switch to another app and your app is deactivated, then analysis pauses.
If your app is tombstoned, then analysis stops.
If you terminate the app in some way, then analysis stops.
The Application Analysis tool analyzes multiple aspects of your app’s behavior and performance and displays the results in a graph format. Each area is color-coded so it is easy to recognize in the graph. The following image shows an example graph.
The following rows of information are displayed in the graph after both app monitoring and app profiling.
User events such as UI input or simulated network changes.
Displays the number of screen redraws, in frames per second, the app completed at that point in the timeline. This information is only available for periods in the timeline where the app was updating the display in some way. Windows Phone apps should average between 30 and 60 frames per second.
Frame rate is not captured or displayed for XNA Framework applications.
CPU usage %
Displays the percentage of phone CPU in use while the app was running. CPU usage is indicated by thread type in the graph. The following table lists the thread types.
Color in Graph
User Interface (UI) thread
Indicates screen updates and touch inputs. You should try to keep the UI thread to less than 50% of CPU usage.
Indicates app activity that is not on the UI thread. This could be composition thread or background threads.
Indicates activity that is not for the app. A large system thread percentage indicates that the system is busy with other background tasks and is affecting app performance.
Indicates available CPU percentage. The higher the idle thread percentage, the more responsive the app is likely to be.
Indicates the responsiveness of the app’s UI to input.
Network data transfer MBps or KBps
App monitoring displays network data transfer in kilobytes per second (KBps); app profiling displays the same value in megabytes per second (MBps).
Battery consumption mAh
The approximate rate of battery consumption while the app is running.
Memory usage MB
Displays the amount of phone memory being used by the app measured in megabytes.
The following rows of information are displayed in the graph only after app profiling.
Displays an S flag on the timeline to indicate the occurrence of storyboard events. Typically a storyboard event indicates the start of an animation. There are two kinds of flags.
Red flag indicates a storyboard that is CPU-bound.
Purple flag indicates a storyboard that is not CPU bound.
Displays an I flag on the timeline to indicate when image assets are loaded into phone memory.
Displays a G flag on the timeline to indicate when garbage collection occurs. This provides details about when the runtime reclaims memory space that was recently freed.
The following is a list of key performance terms you should be familiar with when using the Application Analysis tool. You can hover over column headers in the tool to see tooltips that describe the data in each column.
Readiness of the app’s UI thread in responding to user inputs and screen updates.
The number of iterations required in positioning the indicated visual element in the selected duration.
The amount of time (in milliseconds) spent positioning the indicated visual element.
The percentage of available phone CPU capacity in use at that point in the timeline. This information is broken down by thread in the graph display, and can be broken down by method name in the detailed performance analysis section.
The amount of time within the selected time period during which the indicated visual element was obsolete (awaiting rendering update).
The total number (or percentage) of samples collected during the direct execution of the instructions of the indicated (target) method. Exclusive samples do not include samples that are collected during the execution of functions that are called by the target method.
The ratio of the total number of pixels composed for a frame to the total number of pixels available on the screen.
The number of screen updates rendered at that point in the timeline, expressed in frames-per-second.
The total number (or percentage) of samples collected during the execution of the indicated (target) method. This includes samples that are collected during the direct execution of the method code and samples that are collected during the execution of child methods that are called by the target method.
The number of iterations required in sizing the indicated visual element in the selected duration.
Measure Time Exclusive
The amount of time (in milliseconds) spent sizing and positioning the indicated visual element. This measurement does not include time spent sizing any elements that were children of the indicated element in the visual element hierarchy (tree).
Measure Time Inclusive
The amount of time (in milliseconds) spent sizing the indicated visual element. This measurement includes time spent sizing any elements that were children of the indicated element in the visual element hierarchy (tree).
The private working set of phone memory being used by the app at that point in the timeline.
Notifications of possible performance problems. Warnings are displayed in the detailed performance analysis section.
A statistical profiling method that shows you the functions that are doing most of the user mode work in the app by measuring the amount of time an app spends executing the sampled tasks and code paths.
The number of textures loaded into phone memory for the frame.
Texture Update Count
The number of textures being updated in the selected duration.
Total Draw Time Exclusive
The amount of time (in milliseconds) that was required to render the indicated visual element. This measurement does not include time spent rendering any elements that were children of the indicated element in the visual element hierarchy (tree).
Total Draw Time Inclusive
The amount of time (in milliseconds) that was required to render the indicated visual element. This measurement includes time spent rendering any elements that were children of the indicated element in the visual element hierarchy (tree).