アプリのベンチマークを行う
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
ベンチマークは、アプリのパフォーマンスを検査およびモニタリングするための手段です。ベンチマークを定期的に実施すると、パフォーマンスに関する問題の分析とデバッグを行い、最新の変更で回帰が発生していないことを確認できます。
Android には、アプリの異なる状況を分析およびテストできるように 2 つのベンチマーク ライブラリ（Macrobenchmark と Microbenchmark）が用意されており、それぞれに応じたアプローチがあります。
Macrobenchmark
Macrobenchmark ライブラリは、起動、UI の操作、アニメーションのような上位レベルのエンドユーザー インタラクションを測定します。このライブラリでは、テスト対象のパフォーマンス環境を直接制御できます。そのため、アプリのコンパイル、起動、停止を制御することにより、実際のアプリの起動やスクロールを直接測定できます。
Macrobenchmark ライブラリは、テストでビルドされたテストアプリを通じて外部からイベントを注入して、結果をモニタリングします。したがって、ベンチマークを作成する際には、アプリコードを直接呼び出すのではなく、ユーザーとしてアプリ内で操作します。
Microbenchmark
Microbenchmark ライブラリを使用すると、アプリコードをループ内で直接ベンチマークできます。このライブラリは、内部ループや特定のホットな関数で見られるケース（ウォームアップ処理による JIT、キャッシュされたディスク アクセスなど）のベストのパフォーマンスを評価するといった、CPU 処理を測定するために設計されています。このライブラリでは、独立して直接呼び出せるコードのみを測定できます。
たとえば、アプリが複雑なデータ構造を処理する必要がある場合や、アプリの実行中に計算負荷の高い特定のアルゴリズムが何度も呼び出される場合は、ベンチマークが必要です。UI の一部を測定することもできます。たとえば、RecyclerView アイテムのバインディングのコストはどれくらいか、レイアウトをインフレートするのにどれくらいの時間がかかるか、パフォーマンスの観点から View クラスの layout-and-measure パスの要求がどれくらい厳しいかを測定できます。
ただし、ベンチマーク対象のケースが全体的なユーザー エクスペリエンスにどのように影響するかを測定することはできません。状況によっては、ジャンクやアプリの起動時間などのボトルネックが改善されているかどうかは、ベンチマークでは確認できない場合があります。したがって、最初に Android Profiler を使用して、そうしたボトルネックを特定することが重要です。調査と最適化を行うコードが見つかったら、ベンチマーク対象のループを迅速かつ簡単に繰り返し実行することにより、ノイズが少ない結果を生成して改善が必要な領域に集中できます。
Microbenchmark ライブラリは、アプリに関する情報のみをレポートし、システム全体に関する情報はレポートしません。したがって、システム全体の問題に関連するパフォーマンスではなく、アプリに固有の状況のパフォーマンスを分析するのに適しています。
ベンチマーク ライブラリの比較
|
Macrobenchmark |
Microbenchmark |
| API バージョン |
23 以降 |
14 以降 |
| 機能
|
アクティビティの起動やリストのスクロールなどの上位レベルのエントリ ポイントやインタラクションを測定する |
個々の関数を測定する
|
| 範囲
|
アプリ全体をプロセス外でテストする |
CPU 処理をプロセス内でテストする
|
| 速度
|
反復処理の速度は中程度（1 分を超える場合もある） |
反復処理は高速（ほとんどの場合は 10 秒未満） |
| トレース
|
結果にプロファイリング トレースが含まれる |
オプションでメソッド サンプリングとトレースを利用可能 |
あなたへのおすすめ
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-08-27 UTC。
[null,null,["最終更新日 2025-08-27 UTC。"],[],[],null,["Benchmarking is a way to inspect and monitor the performance of your app. You\ncan regularly run benchmarks to analyze and debug performance problems and help\nensure that you don't introduce regressions in recent changes.\n\nAndroid offers two benchmarking libraries and approaches for analyzing and\ntesting different kinds of situations in your app: Macrobenchmark and\nMicrobenchmark.\n\nMacrobenchmark\n\nThe [Macrobenchmark](/studio/profile/macrobenchmark) library measures larger end-user interactions, such as\nstartup, interacting with the UI, and animations. The library provides direct\ncontrol over the performance environment you're testing. It lets you control\ncompiling and lets you start and stop your app to directly measure actual app\nstartup or scrolling.\n\nThe Macrobenchmark library injects events and monitors results externally from a\ntest app that is built with your tests. Therefore, when writing the benchmarks,\nyou don't call your app code directly and instead navigate within your app as a\nuser.\n\nMicrobenchmark\n\nThe [Microbenchmark](/studio/profile/benchmark) library lets you benchmark app code directly in a loop.\nThis is designed for measuring CPU work that assesses best-case performance---such\nas warmed up Just in Time (JIT) and disk accesses cached---that you might see with\nan inner-loop or a specific hot function. The library can only measure the\ncode that you can call directly in isolation.\n\nIf your app needs to process a complex data structure, or have some specific\ncomputation-heavy algorithm that is called multiple times during the app run,\nthese might be good cases for benchmarking. You can also measure parts of your\nUI. For example, you can measure the cost of the `RecyclerView` item binding,\nhow long it takes to inflate a layout, or how demanding the layout-and-measure\npass of your `View` class is from a performance perspective.\n\nHowever, you aren't able to measure how the benchmarked cases contribute to the\noverall user experience. In some scenarios, benchmarking doesn't tell you if\nyou're improving a bottleneck like jank or app startup time. For this reason,\nit's crucial to identify those bottlenecks first with the [Android Profiler](/studio/profile).\nAfter you find the code you want to investigate and optimize, the benchmarked\nloop can run repeatedly in a quick and easier fashion to create less noisy\nresults, which lets you focus on one area of improvement.\n\nThe Microbenchmark library only reports information about your app, not about\nthe system overall. Therefore, it's best at analyzing performance of situations\nspecific to the app, not ones that might relate to overall system issues.\n\nBenchmark library comparison\n\n| | Macrobenchmark | Microbenchmark |\n|-------------|-----------------------------------------------------------------------------------------------|---------------------------------------------------|\n| API version | 23 and later | 14 and later |\n| Function | Measure high-level entry points or interactions, such as activity launch or scrolling a list. | Measure individual functions. |\n| Scope | Out-of-process test of full app. | In-process test of CPU work. |\n| Speed | Medium iteration speed. It can exceed a minute. | Fast iteration speed. Often less than 10 seconds. |\n| Tracing | Results come with profiling traces. | Optional method sampling and tracing. |\n\nRecommended for you\n\n- Note: link text is displayed when JavaScript is off\n- [Create Baseline Profiles {:#creating-profile-rules}](/topic/performance/baselineprofiles/create-baselineprofile)\n- [JankStats Library](/topic/performance/jankstats)\n- [Overview of measuring app performance](/topic/performance/measuring-performance)"]]
