次の方法で共有

Plan for performance

  • [アーティクル]

Slow, unresponsive, battery-intensive app experiences are among the biggest causes of user frustration. Apps that are fast, responsive, and battery-aware can help keep users satisfied and engaged. As you plan your Windows Store apps, be sure to keep performance in mind.

Performance is a feature that should be planned for, designed, and tested, just like your apps' other features. Follow this process to help plan your apps for performance.

  1. Set performance goals for your apps.
  2. Design for performance.
  3. Instrument your apps for performance.
  4. Test and measure your apps against your performance goals.
  5. Iterate and improve your apps' designs based on the results of your performance tests.

Here are the details for each of this process's steps.

Set app performance goals

Your apps' performance goals should be specific and measurable. To make these goals specific, it may be helpful to think about how fast, fluid, and efficient your apps can be: how long it takes users to complete their tasks in your apps, how responsive your apps are in responding to user interactions, and how well your apps conserve battery life.

Fast

One starting approach is to think of the acceptable time ranges for users to complete their tasks in your apps. We call these time ranges interaction classes. For each of these interaction classes, you could assign for example a label, a perceived user sentiment, a target time period, and a maximum time period. Here are some suggested interaction classes with examples for each.

Interaction class label User perception Target Maximum Examples
Fast Minimally noticeable delay 100 milliseconds 200 milliseconds Bring up the app bar; press a button (first response)
Typical Quick, but not fast 300 milliseconds 500 milliseconds Resize; semantic zoom
Responsive Not quick, but feels responsive 500 milliseconds 1 second Navigate to a different page; resume the app from a suspended state
Launch Competitive experience 1 second 3 seconds Launch the app for the first time or after it has been previously terminated
Continuous No longer feels responsive 500 milliseconds 5 seconds Download a file from the Internet
Captive Long; user could switch away 500 milliseconds 10 seconds Install multiple apps from the Windows Store

 

After you have a set of interaction classes, you could assign them to your apps' performance scenarios. For each scenario, you could assign for example the app's point-in-time reference, a portion of the user experience, and an interaction class. Here are some suggested performance scenarios for an example food and dining app.

Scenario

Time point

User experience

Interaction class

Navigate to recipe page

First response

Page transition animation started

Fast (100-200 milliseconds)

Responsive

Ingredients list loaded; no images

Responsive (500 milliseconds - 1 second)

Visible complete

All content loaded; images shown

Continuous (500 milliseconds - 5 seconds)

Search for recipe

First response

Search button clicked

Fast (100 - 200 milliseconds)

Visible complete

List of local recipe titles shown

Typical (300 - 500 milliseconds)

 

After you have a set of performance scenarios, you'll be better able to test, analyze, and improve how fast your app is.

Fluid

For smooth user responsiveness, specific measurable performance goals for your apps can include:

  • No screen redraw stops and starts (glitches).
  • Screen animations happen at 60 frames per second (FPS), 16 milliseconds of CPU and graphics processing unit (GPU) work per frame.
  • When a user pans your app, you should target presenting up to 3 to 6 pages of content per second.

Efficient

For efficiency, specific measurable performance goals for your apps can include:

  • Maximum memory usage at or below a specified CPU percentage and memory in megabytes at all times.
  • Whenever the user isn't using the app, the CPU and disk percentages stay at zero.

Reduce battery consumption

Most of the performance work you do naturally reduces the amount of power your app consumes. The CPU is a major consumer of battery power on devices, even at low utilization. Windows 8 tries to keep the CPU in a low power state when it is idle, but activates it every time you schedule work. You can further reduce your app's consumption of battery power by ensuring that your app doesn't have timers unnecessarily schedule work on the CPU when it is idle. For example, an app might poll for data from web services and sensors (such as the Global Positioning Systems (GPS)). Consider battery consumption when deciding how often you poll for data.

This is also an important consideration for animations that require constant updates to the screen and keep the CPU and graphics pipeline active. Animations can be an effective in delivering a great user experience, but make a conscious choice about when you use them. This is particularly important for data-driven apps where the user may be looking at your app but not interacting with it. For example, a user may spend a while looking at content in a news reader or photo viewer without interacting with the app. It can also be wasteful to use animations in snap mode because the user is not giving the app their full attention.

Many apps connect to web services to get new info for the user. Reducing the frequency at which you poll for new info can improve your battery consumption.

Reduce memory consumption

Reducing memory helps avoid sluggishness and is even more important for Windows Store apps because of the Process Lifetime Management (PLM) system. The PLM system determines which apps to terminate, in part, by the app's memory footprint. By keeping your app's memory footprint low, you reduce the chance of it getting terminated when it is not being used. For example, you can reduce your app’s memory footprint by releasing unnecessary resources such as images on suspend.

The PLM system may also choose to swap out your app to disk, and swap it back into memory the next time it is switched to. If you lower the memory footprint of your app, it will resume faster.

After you have your performance goals, you can use them to help influence your app's design.

Design for performance

As you design your app, keep your performance goals in mind. Using our example food and dining app, after the user navigates to the recipe page, you might use virtualization as a technique to more quickly load the initial ingredients list but not display any accompanying images until later. Here are some other areas to consider.

Multiple pages of content

For displaying multiple pages of content, performance design and coding techniques include:

Rich visuals and functionality

For displaying rich visuals and functionality, performance design and coding techniques include:

  • Defer loading UI and code as much as possible.
  • Use code-free UI—large portions of hard-coded HTML or Extensible Application Markup Language (XAML) that the runtime can load in batches—whenever possible.
  • Identify distinct functionality for your app and load minimal elements whenever possible.
  • Display portions of the UI to users in multiple stages.
  • Images you load should be loaded at a size that is appropriate for the view in which you are presenting it, using the GetThumbnailAsync method.
  • For animations in Windows Store apps using JavaScript, use Cascading Style Sheets (CSS) Animations, the WinJS.UI.Animation namespace, or both. See also the HTML animation library sample.
  • For Windows Store apps using JavaScript, position UI components with HTML and CSS, avoiding inline layout such as the offsetWidth and offsetHeight properties.
  • For Windows Store apps using C++, C#, or Visual Basic, use XAML theme transitions and animations. For details, see Fast and fluid animations in your Windows Store app and the XAML personality animations sample.

Live content

For displaying live content, performance design and coding techniques include:

  • Identify content freshness goals. For example, is the goal to refresh content every few seconds? Or is refreshing content every few minutes, every few hours, or even once a day an acceptable user experience?
  • Cache content whenever possible. For more info, see:
  • When caching content isn't possible, show a responsive UI as quickly as possible—a UI that users can navigate, but shows some indication to the user that the app is still trying to load some content.
  • Transition from cached to live content in a way that is not jarring to the user. For example, the app won't change the position of content under the user's finger as the app loads live content.
  • Prefetch content. For details, see:

App launch

For launching apps, performance design and coding techniques include:

App resume

For resuming apps, performance design and coding techniques include:

  • Transition smoothly from cached to live content in a way that is not jarring to the user. For example, the app won't change the position of content under the user's finger as the app loads live content.
  • Don't relaunch the app or reanimate content.
  • Higher memory usage translates into slower app resumes. Manage your app's memory as follows:
    • Reduce your code's working set.
    • Avoid memory leaks by unregistering event handlers and dereferencing visual elements whenever possible.
    • For Windows Store apps using JavaScript, use the createObjectUrl method and oneTimeOnly property.
    • If possible, avoid creating hybrid apps that use both HTML/JavaScript and XAML to minimize circular references.

App resizing and rotating

For resizing and rotating apps, performance design and coding techniques include:

  • For Windows Store apps using C++, C#, or Visual Basic use the VisualStateManager class.
  • For Windows Store apps using JavaScript, use HTML/CSS instead of JavaScript as much as possible.
  • Complete only required work immediately, deferring intensive app work until later—your app has between 200 and 800 milliseconds to complete work before the user sees your app's UI in a cropped state.

Panning content

For panning through content, performance design and coding techniques include:

  • Plan for 3 to 6 pages per second of user panning.
  • Virtualize large sets of items. For details, see Using virtualization with a list or grid.
  • Use project templates with the lowest number of elements that you can.
  • Render content in multiple stages.

Note that as you go, you may discover that there are other general performance-related design considerations that don't match up to any of these performance scenarios. For example, what happens if the device has an intermittent wireless connection, has a slower dial-up connection, or has no Internet connection at all? In the case of our example food and dining app, one approach may be to cache the accompanying images after they are initially downloaded. For other techniques, see Connection usage data.

With your performance-related designs in place, you can start coding your app.

Instrument for performance

As you code your app, you can add code that logs messages and events at certain points while your app runs. Later, when you're testing your app, you can use tools such as Windows Performance Recorder and Windows Performance Analyzer (both are included in the Windows Performance Toolkit) to create and view a report about your app's performance. In this report, you can look for these messages and events to help you more easily analyze the report's results.

The Windows Runtime provides logging APIs, backed by Event Tracing for Windows (ETW), that together offer a rich event logging and tracing solution for Windows Store apps. The APIs, which are part of the Windows.Foundation.Diagnostics namespace, include the FileLoggingSession, LoggingActivity, LoggingChannel, and LoggingSession classes.

To log a message in the report at a specific point while the app is running, create a LoggingChannel object, and then call the object's LogMessage method, like this.

// using Windows.Foundation.Diagnostics;
// ...

LoggingChannel myLoggingChannel = new LoggingChannel("MyLoggingChannel");

myLoggingChannel.LogMessage(LoggingLevel.Information, "Here's my logged message.");

// ...

To log start and stop events in the report over a period of time while the app is running, create a LoggingActivity object, and then call the object's LoggingActivity constructor, like this.

// using Windows.Foundation.Diagnostics;
// ...

LoggingActivity myLoggingActivity;

// myLoggingChannel is defined and initialized in the previous code example.
using (myLoggingActivity = new LoggingActivity("MyLoggingActivity"), myLoggingChannel))
{   // After this logging activity starts, a start event is logged.
    
    // Add code here to do something of interest.
    
}   // After this logging activity ends, an end event is logged.

// ...

For more examples, see the LoggingSession sample and FileLoggingSession sample.

After you've instrumented your app's code, you can test and measure your app's performance.

Test and measure against performance goals

After you've instrumented your app, use the following techniques and tools to test how your app stacks up against your original performance goals:

  • Test against a wide variety of hardware configurations that you think users will have, including all-in-one and desktop PCs, laptops and ultrabooks, and tablets.
  • Test against a wide variety of screen sizes that you think users will have. Note that while wider screen sizes can show much more content, bringing in all of that extra content can have a negative impact performance.
  • Eliminate as many random testing variables as you can. For example:
    • Turn off background apps on the testing device. To do this, in Windows, select the Settings charm > Change PC settings > PC and devices. Select each active app in the Lock screen apps area, and select Don't show quick status here.
    • Create native code images on the testing device for Windows Store apps built for Windows using C# or Visual Basic. To do this, Windows, from the Desktop, open Action Center. In the Maintenance area, under Automatic Maintenance, select Start maintenance.
    • Run the app multiple times to help eliminate random testing variables and help ensure consistent measurements.
  • Test for reduced battery consumption. When you create an app, be aware that the type of computer that your users have might have significantly less power than your development environment. Windows 8 was designed with low power devices, such as tablets, in mind. Also, Windows RT uses these same design principles to take advantage of the low power consumption characteristics of ARM-based platforms. Windows Store apps need to do their part to ensure that they perform well on these devices. Operations that seem to run fast on your development machine can have a big impact to the user-experience on a low power device. As a heuristic, expect that a low power device is about 4 times slower than a desktop computer, and set your goals accordingly.
  • Use a combination of toolsets like Microsoft Visual Studio and Windows Performance Analyzer to measure app performance. Visual Studio is designed to provide app-focused analysis, such as source code linking. Windows Performance Analyzer is designed to provide system-focused analysis, such as providing system info, info about touch manipulation events, and info about disk input/output (I/O) and GPU cost. Both toolsets provide trace capture and export, and can reopen shared and post-mortem traces.
  • Before you submit your app to the Windows Store for certification, be sure to incorporate into your test plans the performance-related test cases as described in the "Performance tests" section of Windows App Certification Kit tests and in the "Performance and stability" section of Windows Store app test cases.

Iterate and improve app design based on performance test results

After you analyze your performance test results, determine if any changes are needed, for example:

  • Should you change any of your existing app performance goals?
  • Should you change any of your current design decisions?
  • Should you add, remove, or change any of your instrumentation in the code?

If any changes are needed, go back through the start of this process and iterate.

Plan your app

Performance (Windows Store apps)

General best practices for performance

Performance best practices for Windows Store apps using JavaScript

Performance best practices for Windows Store apps using C++, C#, or Visual Basic