ユーザーは、アプリの応答性が維持され、自然に感じられ、バッテリーを消耗しないことを期待しています。 技術的には、パフォーマンスは機能しない要件ですが、パフォーマンスを機能として扱うと、ユーザーの期待に応えるのに役立ちます。 目標を指定し、測定することは重要な要因です。 パフォーマンスにおいて重要なシナリオを決定し、良好なパフォーマンスとは何かを定義します。 その後、プロジェクトのライフサイクル全体を通して早期かつ頻繁に測定し、目標を達成できると確信できます。
目標の指定
ユーザー エクスペリエンスは、優れたパフォーマンスを定義するための基本的な方法です。 アプリの起動時間は、パフォーマンスに対するユーザーの認識に影響を与える可能性があります。 ユーザーは、アプリの起動時間が 1 秒未満が優れている、5 秒未満が良い、5 秒を超える時間が悪いと考える場合があります。
他のメトリック、例えばメモリは、ユーザーエクスペリエンスに対する影響があまり目立ちません。 中断中または非アクティブな状態でアプリが終了する可能性は、アクティブなアプリによって使用されるメモリの量と共に増加します。 メモリ使用量が多い場合、システム上のすべてのアプリのエクスペリエンスが低下するという一般的なルールであるため、メモリ使用量を目標にすることは妥当です。 ユーザーが認識するアプリの大まかなサイズ (小、中、または大) を考慮してください。 パフォーマンスに関する期待は、この認識に関連します。 たとえば、大量のメディアを使用しない小さなアプリで、100 MB 未満のメモリを消費することが必要な場合があります。
最初の目標を設定してから、後で修正する方が、目標をまったく持たないようにすることをお勧めします。 アプリのパフォーマンス目標は、具体的で測定可能であり、ユーザーまたはアプリがタスクを完了するまでの時間 (時間) という 3 つのカテゴリに分類する必要があります。ユーザーの操作 (流動性) に応じてアプリが自身を再描画する速度と継続性。また、バッテリ電力 (効率) を含むシステム リソースをどの程度節約できるかを確認します。
時間
ユーザーがアプリでタスクを完了するために必要な経過時間 (相互作用クラス) の許容範囲を考えてみましょう。 相互作用クラスごとに、ラベル、認識されるユーザーセンチメント、理想的な期間と最大期間を割り当てます。 いくつかの提案を次に示します。
| 相互作用クラス のラベル | ユーザーの認識 | 理想的 | 最大値 | 例示 |
|---|---|---|---|---|
| 速い | 遅延がほとんど目立たない | 100 ミリ秒 | 200 ミリ秒 | アプリ バーを表示します。ボタンを押す (最初の応答) |
| 典型的な | クイックですが、高速ではありません | 300 ミリ秒 | 500 ミリ秒 | リサイズ;セマンティック ズーム |
| 応答 | 迅速ではありませんが、応答性が高い | 500 ミリ秒 | 1 秒 | 別のページに移動します。中断状態からアプリを再開する |
| 開始 | 競争力のあるエクスペリエンス | 1 秒 | 3 秒 | アプリを初めて起動するか、以前に終了した後にアプリを起動する |
| 継続的 | 応答性を感じなくなった | 500 ミリ秒 | 5 秒 | インターネットからファイルをダウンロードする |
| 囚人 | 長くなると、ユーザーが切り替える可能性がある | 500 ミリ秒 | 10 秒 | ストアから複数のアプリをインストールする |
これで、アプリのパフォーマンス シナリオに対話クラスを割り当てることができます。 アプリの特定の時点の参照、ユーザー エクスペリエンスの一部、および対話クラスを各シナリオに割り当てることができます。 食べ物や食事のアプリの例に関するいくつかの提案を次に示します。
| シナリオ | 時間点 | ユーザー エクスペリエンス | インタラクション クラス |
|---|---|---|---|
| レシピ ページに移動する | 最初の応答 | ページ切り替えアニメーションの開始 | 高速 (100 ~ 200 ミリ秒) |
| 応答 | 材料リストが読み込まれました。画像なし | 応答性 (500 ミリ秒から 1 秒) | |
| 完全に可視 | すべてのコンテンツが読み込まれ、画像が表示されました。 | 連続 (500 ミリ秒から 5 秒) | |
| レシピを検索する | 最初の応答 | クリックされた [検索] ボタン | 高速 (100 ~ 200 ミリ秒) |
| 完全に可視 | 表示されているローカル レシピ タイトルの一覧 | 標準 (300 ~ 500 ミリ秒) |
ライブ コンテンツを表示する場合は、コンテンツの鮮度の目標も考慮してください。 数秒ごとにコンテンツを更新することが目標ですか? または、数分ごと、数時間ごと、または 1 日に 1 回でもコンテンツを更新することは、許容できるユーザー エクスペリエンスですか?
目標を指定すると、アプリをテスト、分析、最適化できるようになりました。
流動
アプリの具体的な測定可能な流動性の目標は次のとおりです。
- 画面の再描画の停止と開始 (グリッチ) はありません。
- アニメーションは、1 秒あたり 60 フレーム (FPS) でレンダリングされます。
- ユーザーがパン/スクロールすると、アプリは 1 秒あたり 3 ~ 6 ページのコンテンツを表示します。
効率性
アプリの具体的な測定可能な効率目標は次のとおりです。
- アプリのプロセスでは、CPU 使用率は N 以下であり、メモリ使用量 (MB) は常に M 以下です。
- アプリが非アクティブな場合、N と M は、アプリのプロセスに対してゼロになります。
- アプリはバッテリー電源で X 時間通常使用できます。アプリが非アクティブな場合、デバイスは Y 時間充電を保持します。
パフォーマンスを向上させるためにアプリを設計する
これで、パフォーマンス目標を使用して、アプリの設計に影響を与えることができます。 食べ物と食事のアプリの例を使用して、ユーザーがレシピ ページに移動した後、レシピの名前が最初にレンダリングされ、食材が遅延され、画像の表示がさらに延期されるように、 項目を段階的に更新
UI
- XAML マークアップを最適化
することで、アプリの UI (特に初期ページ) の各ページの解析と読み込みの時間とメモリ効率を最大化します。 簡単に言うと、必要になるまで UI とコードの読み込みを延期します。 - ListView と GridViewでは、すべての項目を同じサイズにし、ListView と GridView の最適化手法をできるだけ多く 使用します。
- UI をマークアップの形式で宣言します。これは、フレームワークがコード内で命令的に構築するのではなく、チャンクで読み込んで再利用できます。
- ユーザーが UI 要素を必要とするまで、UI 要素の作成を遅らせる。 x:Load 属性を参照してください。
- テーマのトランジションやアニメーションを、ストーリーボードで作成されたアニメーションより優先して使用してください。 詳細については、「アニメーションの概要」を参照してください。 ストーリーボードに設定されたアニメーションでは、画面を一定に更新する必要があり、CPU とグラフィックス パイプラインをアクティブな状態に保つ必要があります。 バッテリーを保持するために、ユーザーがアプリを操作していない場合は、アニメーションを実行しないでください。
- 読み込むイメージは、GetThumbnailAsync メソッドを使用して、表示するビューに適したサイズで読み込む必要があります。
CPU、メモリ、および電源 を
- 優先順位の低いスレッドやコアで実行するように優先順位の低い作業をスケジュールします。 非同期プログラミング、
Dispatcher CoreDispatcher 参照してください。 - 中断時に高価なリソース (メディアなど) を解放することで、アプリのメモリ占有領域を最小限に抑えます。
- コードのワーキング セットを最小限に抑えます。
- 可能な限り、イベント ハンドラーの登録を解除し、UI 要素を逆参照することで、メモリ リークを回避します。
- バッテリのために、データのポーリング、センサーのクエリ、アイドル時の CPU での作業のスケジュールを設定する頻度は控えめにしてください。
データのアクセス
- 可能であれば、コンテンツをプリフェッチします。 自動プリフェッチについては、ContentPrefetcher クラスを参照してください。 手動プリフェッチについては、Windows.ApplicationModel.Background 名前空間と MaintenanceTrigger クラスを参照してください。
- 可能であれば、アクセスにコストがかかるコンテンツをキャッシュします。
LocalFolder の を参照してください。 - キャッシュ ミスの場合は、アプリがまだコンテンツを読み込んでいることを示すプレースホルダー UI をできるだけ早く表示します。 プレースホルダーからライブ コンテンツへの切り替えは、ユーザーには問題のない方法で行います。 たとえば、アプリがライブ コンテンツを読み込む際に、ユーザーの指またはマウス ポインターの下のコンテンツの位置を変更しないでください。
アプリの起動と の再開
- アプリのスプラッシュ画面を延期し、必要な場合を除き、アプリのスプラッシュ画面を拡張しないでください。 詳細については、「アプリの起動を高速かつスムーズにする方法」と「スプラッシュスクリーンの表示時間を長くする方法」をご覧ください。
- スプラッシュ画面が閉じた直後に発生するアニメーションを無効にします。これは、アプリの起動時間の遅延を認識することにつながるだけなのでです。
アダプティブUIと方向についての、および
- VisualStateManager クラスを使用します。
- 必要な作業のみをすぐに完了し、集中型アプリの作業を後まで延期します。ユーザーがアプリの UI をトリミングされた状態で表示する前に、アプリの作業が完了するまでに 200 ~ 800 ミリ秒かかります。
パフォーマンス関連の設計が整ったら、アプリのコーディングを開始できます。
演奏用の楽器
コードを作成するときに、アプリの実行中に特定の時点でメッセージとイベントをログに記録するコードを追加します。 後でアプリをテストするときに、Windows Performance Recorder や Windows Performance Analyzer などのプロファイリング ツール (どちらも Windows Performance Toolkitに含まれています) を使用して、アプリのパフォーマンスに関するレポートを作成および表示できます。 このレポートでは、これらのメッセージとイベントを検索して、レポートの結果をより簡単に分析できます。
ユニバーサル Windows プラットフォーム (UWP) には、Event Tracing for Windows (ETW)によってサポートされるログ記録 API が用意されており、一緒に豊富なイベント ログ記録とトレース ソリューションを提供します。 Windows.Foundation.Diagnostics 名前空間の一部である API には、FileLoggingSession、LoggingActivity、LoggingChannel、および LoggingSession クラスが含まれます。
アプリの実行中に特定の時点でレポートにメッセージを記録するには、LoggingChannel オブジェクトを作成し、次のようにオブジェクトの LogMessage メソッドを呼び出します。
// using Windows.Foundation.Diagnostics;
// ...
LoggingChannel myLoggingChannel = new LoggingChannel("MyLoggingChannel");
myLoggingChannel.LogMessage(LoggingLevel.Information, "Here' s my logged message.");
// ...
アプリの実行中にレポートの開始イベントと停止イベントを一定期間ログに記録するには、LoggingActivity オブジェクトを作成し、次のようにオブジェクトの LoggingActivity コンストラクターを呼び出します。
// 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.
// ...
ログのサンプルも参照してください。
アプリをインストルメント化すると、アプリのパフォーマンスをテストして測定できます。
パフォーマンス目標に対するテストと測定
パフォーマンス計画の一部として、パフォーマンスを測定する開発中のポイントを定義します。 これは、プロトタイプの作成、開発、デプロイのどちらで測定するかによって異なる目的で機能します。 プロトタイプ作成の初期段階でパフォーマンスを測定することは非常に価値があるので、意味のある作業を行うコードがあればすぐに行うことをお勧めします。 早期測定では、重要なコストがアプリ内のどこにあるかを把握し、設計上の決定を通知します。 これにより、アプリのパフォーマンスとスケーリングが高くなります。 一般に、以前よりも後で設計を変更する方がコストがかかります。 製品サイクルの後半でパフォーマンスを測定すると、直前のハッキングやパフォーマンスの低下が発生する可能性があります。
これらの手法とツールを使用して、元のパフォーマンス目標に対してアプリがどのようにスタックアップするかをテストします。
- オールインワン PC、デスクトップ PC、ノート PC、Ultrabook、タブレット、その他のモバイル デバイスなど、さまざまなハードウェア構成に対してテストします。
- さまざまな画面サイズに対してテストします。 画面サイズを広くすると、より多くのコンテンツを表示できますが、そのすべての追加コンテンツを取り込むことはパフォーマンスに悪影響を与える可能性があります。
- できる限り多くのテスト変数を排除します。
- テスト デバイスでバックグラウンド アプリをオフにします。 これを行うには、Windows で、[スタート] メニューの [個人用設定]
[ロック] 画面 設定 を選択します。 アクティブなアプリをそれぞれ選択し、なしを選択します。 - アプリをテスト デバイスにデプロイする前に、リリース構成でビルドしてネイティブ コードにコンパイルします。
- 自動メンテナンスがテスト デバイスのパフォーマンスに影響しないようにするには、手動でトリガーし、完了するまで待ちます。 Windows の [スタート] メニューで、セキュリティとメンテナンスのを検索します。
メンテナンス 領域の自動メンテナンス で、[メンテナンス開始] を選択し、進行中のメンテナンス 状態が変わるのを待ちます。 - アプリを複数回実行して、ランダムなテスト変数を排除し、一貫性のある測定を実現します。
- テスト デバイスでバックグラウンド アプリをオフにします。 これを行うには、Windows で、[スタート] メニューの [個人用設定]
- 電力の可用性の低下をテストします。 ユーザーのデバイスの能力は、開発用コンピューターよりも大幅に少ない場合があります。 Windows は、モバイル デバイスなどの低電力デバイスを念頭に置いて設計されました。 プラットフォーム上で実行されるアプリは、これらのデバイスで適切に動作するようにする必要があります。 ヒューリスティックとして、低電力デバイスがデスクトップ コンピューターの約 4 分の 1 の速度で実行されることを期待し、それに応じて目標を設定します。
- Microsoft Visual Studio や Windows Performance Analyzer などのツールを組み合わせて使用して、アプリのパフォーマンスを測定します。 Visual Studio は、ソース コードのリンクなど、アプリに重点を置いた分析を提供するように設計されています。 Windows Performance Analyzer は、システム情報、タッチ操作イベントに関する情報、ディスク入出力 (I/O) とグラフィックス処理装置 (GPU) のコストに関する情報の提供など、システムに重点を置いた分析を提供するように設計されています。 どちらのツールもトレース キャプチャとエクスポートを提供し、共有トレースと事後分析トレースを再度開くことができます。
- 認定を受けるためにアプリをストアに提出する前に、Windows アプリ認定キットテスト の「パフォーマンス テスト」セクション と、UWP アプリ テスト ケース の「パフォーマンスと安定性」セクションに記載されているように、パフォーマンス関連のテスト ケースをテスト計画に確実に組み込んでください。
詳細については、これらのリソースとプロファイリング ツールを参照してください。
- Windows Performance Analyzer
- Windows Performance Toolkit
- Visual Studio 診断ツールを使用してパフォーマンスを分析する
- //build/ セッションの XAML パフォーマンス
- Visual Studio 2015 の //build/ セッションの新しい XAML ツール
パフォーマンス テストの結果に応答する
パフォーマンス テストの結果を分析した後、次に例を示す変更が必要かどうかを判断します。
- アプリの設計上の決定を変更するか、コードを最適化する必要がありますか?
- コード内のインストルメンテーションを追加、削除、または変更する必要がありますか?
- パフォーマンス目標を修正する必要がありますか?
変更が必要な場合は、変更を行い、インストルメント化またはテストに戻って繰り返します。
最適化
ほとんどの時間が費やされるアプリのパフォーマンスクリティカルなコード パスのみを最適化します。 プロファイリングによって、どちらが表示されるかがわかります。 多くの場合、適切な設計プラクティスに従うソフトウェアを作成することと、最高の最適化で実行するコードを記述することにはトレードオフがあります。 一般に、パフォーマンスが懸念されない領域では、開発者の生産性と優れたソフトウェア設計を優先することをお勧めします。