パフォーマンス テスト
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
アプリのランタイム パフォーマンスは、ローカルテストとフィールドテストに分けられます。これらの両方の領域で得られる結果と指標は異なります。結果自体が決定的である限り、その差異は許容されます。
フィールドテスト
フィールド テストは、実際のユーザーが実際の環境でアプリを使用する際のパフォーマンスを把握するのに役立ちます。これは重要な領域であり、フィールドでのアプリのパフォーマンスを理解するうえで役立ちます。Google Play Vitals や Firebase Performance Monitoring などのツールを使用して、ユーザーからフィールド指標を取得できます。
AndroidX Tracing ライブラリを使用してトレース ポイントを追加できます。これにより、フィールド指標により多くのコンテキストと分析情報を得ることができます。
ApplicationStartInfo と ApplicationExitInfo を使用して、アプリの起動と終了に関する詳細情報をユーザーから取得することもできます。
AndroidX JankStats ライブラリを使用すると、遅いフレームとドロップされたフレームの集計とレポートが可能になり、詳細な分析が可能になります。
ローカルテスト
アプリのランタイム パフォーマンスをローカルでテストするために、ベンチマーク ライブラリが用意されています。ユーザーフロー全体のパフォーマンスをテストするために使用できる macrobenchmark ライブラリと、アプリまたはライブラリのホットループ パフォーマンスを分析するために使用できる microbenchmark ライブラリに分かれています。
すべてのパフォーマンス テストは物理デバイスで実行する必要があります。これは、測定するパフォーマンスがデバイスで発生している実際のパフォーマンスであることを確認する唯一の方法です。ランタイム パフォーマンス テストの結果は、実行するデバイスとデバイスの負荷によって異なります。
アプリケーションのパフォーマンスが低下する可能性があります。回帰を回避するには、パフォーマンス テストを頻繁に実行することが重要です。理想的なシナリオでは、新しい機能が追加されるたびに、またはコードがメインブランチにマージされるたびに、アプリのベンチマークが行われます。パフォーマンス モニタリングの最低限の要件は、リリース候補版をベンチマークし、主要なユーザー ジャーニーで起動時間とフレーム タイミングが低下していないことを確認することです。可能な限りベンチマークを実行することをおすすめします。たとえば、機能をメインブランチに統合する前や、ナイトリー ビルドでベンチマークを実行します。
結果を使用する
パフォーマンス テストは継続的なプロセスです。パフォーマンス テストの結果を、経時的に比較できるように保存することをおすすめします。
パフォーマンス テストの結果は、いくつかの方法で使用できます。
- パフォーマンスの改善 - 測定結果を使用してパフォーマンスの改善に優先順位を付ける
- 回帰の回避 - 新しいリリースでパフォーマンスの低下が発生しないようにする
- 本番環境のモニタリング - 開発中に確認できなかった問題があるかどうかを把握する
Android ランタイム パフォーマンス テストの詳細については、アプリのパフォーマンスに関するガイドをご覧ください。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-07-27 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-07-27 UTC。"],[],[],null,["# Performance tests\n\nApp runtime performance can be divided into local testing and field testing.\nKeep in mind that both of these areas provide different results and\nmetrics. As long as the results are in itself conclusive, that divergence is\nacceptable.\n\nField testing\n-------------\n\nField testing helps you to understand how an app performs with real users under\nreal world conditions. It is an important area and helps to understand how an\napp performs in the field. You can use tools such as [Google Play Vitals](/topic/performance/vitals) and\n[Firebase Performance Monitoring](https://firebase.google.com/docs/perf-mon) to get field metrics from\nusers.\n\nYou can use the [AndroidX Tracing](/jetpack/androidx/releases/tracing) library to add trace points which\nprovides more context and insights to field metrics.\n\nYou can also use [`ApplicationStartInfo`](/reference/android/app/ApplicationStartInfo) and [`ApplicationExitInfo`](/reference/android/app/ApplicationExitInfo) to\nget more detailed information on application start and exit from users.\n\nThe [AndroidX JankStats](/topic/performance/jankstats) library enables aggregating and reporting of slow\nand dropped frames for further analysis.\n\nLocal testing\n-------------\n\nTo locally test the runtime performance of an app we provide the benchmarking\nlibrary. It is divided into the [macrobenchmark](/topic/performance/benchmarking/macrobenchmark-overview) library, which can be used\nto test the performance of entire user flows and the [microbenchmark](/topic/performance/benchmarking/microbenchmark-overview)\nlibrary, which is used to analyze hot loop performance of an application or\nlibrary.\n\nAll performance tests should run on a physical device. This is the only way to\nensure that the performance you're measuring is the actual performance\noccurring on a device. Runtime performance tests will produce different results\ndepending on the device they run on and how busy the device is.\n\nApplication performance can regress. To avoid regressions it's important to run\nperformance tests frequently. In an ideal scenario an app is benchmarked every\ntime a new feature is added or code is merged into the main branch. The bare\nminimum of performance monitoring is to benchmark release candidates and verify\nthat startup time and frame timing does not regress for major user journeys.\nWe recommend you run benchmarks whenever possible, such as before merging a\nfeature to the main branch or for nightly builds.\n\nUse the results\n---------------\n\nPerformance testing is an ongoing process. We recommend that you store results\nof performance tests in a way that they can be compared over time.\n\nYou can use results of performance tests in several ways.\n\n- Performance improvement - Use measurement results to prioritize performance improvement\n- Regression avoidance - Ensure there are no performance regressions with new releases\n- Production monitoring - Understand whether there are issues you're not seeing during development\n\nTo learn more about Android runtime performance testing, see the\n[guide to app performance](/performance)."]]
