パフォーマンス テスト用の環境をセットアップする
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
短期間のデバイスのアクティビティを記録し、アプリの起動期間のトレースを収集することで、潜在的なボトルネックを特定し、アプリの全体的なパフォーマンスを改善できます。このページでは、パフォーマンス テスト用の環境の設定方法について説明します。
Macrobenchmark ライブラリを使用する
Macrobenchmark ライブラリは、起動、UI の操作、アニメーションなど、上位レベルのエンドユーザー インタラクションを測定します。このライブラリでは、テスト対象のパフォーマンス環境を直接制御できます。そのため、アプリのコンパイル、起動、停止を制御することにより、アプリの正確な起動時間を直接測定できます。また、ノイズとテスト実行間の差を最小限に抑えることもできます。
ミッドレンジのデバイスを使用して潜在的なパフォーマンスの問題を特定する
対象の各デバイスタイプでパフォーマンスをテストします。高速なコンポーネントを搭載したハイエンド デバイスでは、以前のデバイス、低速のデバイス、低 RAM デバイスに関するパフォーマンスの問題が隠れてしまう可能性があります。ローエンド デバイスでは、データの読み込みやコードの実行に時間がかかるため、ボトルネックを特定しやすくなります。通常、ローエンド デバイスでパフォーマンスを最適化することは、ハイエンド デバイスの最適化にもメリットがあります。
ノイズを低減する
- ネットワーク: 高速で安定したインターネット Wi-Fi でアプリ(またはプロセス)をテストします。アプリの起動中にネットワーク リクエストが行われる場合、そこでばらつきが出る可能性があります。
- RAM 使用量: アプリの起動パフォーマンスのテスト中に、デバイスのバックグラウンドで他のアプリを実行しないでください。
- バッテリー: ハードウェア独自の低電力パフォーマンス スロットリングが行われないように、必ず十分に充電された状態にします。
リリースビルドでテストする
パフォーマンスのテストにはリリースビルドを使用します。デバッグビルドではコンパイル時の最適化が行われず、パフォーマンスに大きな影響があるため、パフォーマンス デバッグには適していません。
クラスとオペレーション名が識別できるように難読化されていないリリースビルドを使用することは問題ありません。具体的には、proguard ファイルで -dontobfuscate
を使用し、minify(R8)を有効にして難読化を無効にすることをおすすめします。ビルドの難読化を無効にすると、レイアウト、アセット、リソースを識別しやすくなります。
必ず、デバッグ可能ビルド以外のビルドからカスタム イベントを識別できるように、マニフェストに profileable フラグを追加します。このフラグは Android 10(API レベル 29)以降で使用できます。
アプリのオペレーションにカスタム トレースを追加する
アプリ内にカスタム トレースを追加すると、そのアプリによって実行されるオペレーションが他のライブラリと比較して識別しやすくなります。こうすることで、そのアプリが何を行っているかについての状況を常により詳しく把握できます。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。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,["# Set up your environment for performance testing\n\nYou can identify potential bottlenecks and improve overall app performance by\nrecording device activity over a short period of time and [collecting traces of\nyour app's startup period](/topic/performance/tracing). This page shows how to\nset up your environment for performance testing.\n\nUse the Macrobenchmark library\n------------------------------\n\nThe [Macrobenchmark\nlibrary](/topic/performance/benchmarking/macrobenchmark-overview) measures\nlarger end-user interactions, such as startup, interacting with the UI, and\nanimations. The library provides direct control over the performance environment\nyou're testing. It lets you control compiling, starting, and stopping your app\nto directly measure precise app startup time. It also works to minimize the\nnoise and differences between test runs.\n\nUse mid-range devices to identify potential performance issues\n--------------------------------------------------------------\n\nTest performance on each device type you care about. High-end devices with fast\ncomponents can hide performance problems on earlier, slower, or low RAM devices.\nLower-end devices can take longer to load data or run code, making it easier to\nidentify bottlenecks. Optimizing performance for low-end devices usually also\nbenefits optimization for high-end devices.\n\nReduce noise\n------------\n\n- Network: test your apps or processes with strong and stable internet Wi-Fi speeds. If the app startup time includes a network request, note this as a place where variability might occur.\n- RAM usage: don't have any other apps running in the background of your device while testing app startup performance.\n- Battery: ensure your device is charged to avoid any hardware-specific low power performance throttling.\n\nTest on release builds\n----------------------\n\nUse release builds to test performance. Debug builds are [unsuitable for\nperformance\ndebugging](/studio/profile/measuring-performance#apk-considerations), as they\ndon't provide compilation optimization and significantly impact performance.\n\nHowever, it's okay to use an unobfuscated release build to identify classes and\noperation names. Specifically, we recommend enabling [minify\n(R8)](/studio/build/shrink-code) and disabling obfuscation, with\n[`-dontobfuscate`](/studio/build/shrink-code#obfuscate) in the proguard file.\nIt's easier to identify layouts, assets, and resources if the build is\nunobfuscated.\n\nMake sure you include the\n[profileable](/guide/topics/manifest/profileable-element) flag in the manifest\nso that your custom events are visible in non-debuggable builds. This flag is\navailable on Android 10 (API level 29) and later.\n\nAdd custom traces to your app operations\n----------------------------------------\n\nAdd [custom traces](/topic/performance/tracing/custom-events) within your app to\nmake it easier to identify what operations are performed by your app compared to\nother libraries. This helps give you more context about what the app is doing at\nall times."]]