ヒーロー ベンチマーク

ヒーロー ベンチマークは、アプリの起動やオープンソースの Pokedex アプリでのスクロールなど、アプリのユーザー ジャーニーの概要をカバーする一連のベンチマークです。

• 起動ヒーロー ベンチマーク: アプリを開いてからコンテンツが表示されるまでの時間をトラッキングします。
• スクロール ヒーロー ベンチマーク: 画像を含む Lazy Grid のスクロール パフォーマンスを測定します。

テストのセットアップ

• アプリの選択: これらのテストは、オープンソースの Pokedex アプリを使用して実施し、View ベースのバージョンとCompose ベースのバージョンを比較しました。このアプリは、実際のシナリオを想定して選択されたものであり、Compose チームによって開発されたものではありません。
• ハードウェアのセットアップ: CPU と GPU がロックされた Android 12（API 31）を搭載した Pixel 3a でベンチマークを実行しました。このデバイスは、ヒーロー ベンチマークの標準パフォーマンス ベースラインとして使用されます。
• ビルドのセットアップ: ベンチマークでは、R8 を有効にしてリリースモードでビルドされたアプリを使用します。アプリは完全にプリコンパイルされ、実行時（JIT）コンパイルによる不安定さを軽減しています。
• 結果の選択: 最悪のケースを分析するため、極端な外れ値と 代表的でないノイズはベンチマーク結果から除外しました。次に、上限のパフォーマンス データの中央値を選択してベースラインを確立しました。

起動ヒーロー ベンチマーク

起動を測定するために、PokedexStartupBenchmark を使用しました。PokedexStartupBenchmark は、Pokedex アプリがユーザーに表示されるまでの時間を測定します。

アプリの起動は、3 つの状態のいずれかで行われます。コールド スタート、ウォーム スタート、 ホットスタート。それぞれの状態は、アプリがユーザーに表示されるまでの時間に影響します。コールド スタートでは、アプリはゼロからスタートします。このベンチマークでは、コールド スタート状態でのアプリの起動パフォーマンスを測定します。Google では、常にコールド スタートを想定してアプリを最適化することをおすすめします。そうすれば、ウォーム スタートとホットスタートのパフォーマンスも向上させることができます。

アプリの起動時間を測定するために使用する指標は、初期表示までの 時間と完全表示までの時間です。

注: Compose 1.11 のPokedexStartupBenchmark 方法が大幅に変更されたため、以前の Compose バージョンのベンチマーク データは表示されません。

初期表示までの時間

初期表示までの時間（TTID）は、アプリが最初のフレームを生成するのにかかる時間を測定します。これには、コールド スタート中のプロセスの初期化、コールド スタートおよびウォーム スタート中のアクティビティの作成、最初のフレームの表示が含まれます。

PokedexStartupBenchmark では、Compose 1.11 はコールド スタートでの TTID で Views より 2.5% 遅くなっています。

図 1: TTID の Compose 1.11 と Views の比較。

完全表示までの時間

完全表示までの時間（TTFD）は、アプリがインタラクティブになるまでの時間を測定します。 つまり、すべてのデータが読み込まれて描画されたということです。完全表示までの時間について詳しくは、アプリの起動時間をご覧ください。

PokedexStartupBenchmark では、Compose 1.11 はコールド スタートでの TTFD で Views より 13.0% 遅くなっています。

図 2: TTFD の Compose 1.11 と Views の比較。

注: Compose チームは、起動レイテンシの改善に積極的に取り組んでいます。Compose のパフォーマンスの今後の改善について詳しくは、 Compose のロードマップをご覧ください。

スクロール ヒーロー ベンチマーク

スクロール パフォーマンスを測定するために、PokedexScrollBenchmark を使用しました。 これは、画像を含む Lazy Grid の Pokedex アプリ画面のスクロール パフォーマンスを測定します。このベンチマークでは、画面全体を複数回スクロールしてフリングし、新しいアイテムを読み込みます。スクロール パフォーマンスはジャンク率で測定されます。

ジャンク率

Android デバイスは、1 秒あたり最大 60 フレームまたは 120 フレーム（fps）でレンダリングします。つまり、システムにはフレームを生成するための厳格な締め切りがあります（60 fps の場合は 16.6 ミリ秒など）。アプリの処理に時間がかかりすぎると、ジャンクと呼ばれる目に見えるカクつきが発生する可能性があります。

PokedexScrollBenchmark では、Compose 1.9.0 以降、Compose と Views で同じパフォーマンス（0.21% のジャンク）を実現しています。絶対値では、485 フレームのうち 1 フレームがジャンクでした。

注: 慎重なレポート作成のため、UI とフレーム レンダリングの複雑さが最も高いシナリオを代表的な結果として使用しました。

これらのベンチマークは、Compose 1.9 以降では、スクロール時のジャンクの Views のパフォーマンスと一致していることを示しています。

Compose 1.9.0 以降、Compose と Views のジャンク率は同じです。

ヒーロー ベンチマークを実行する

パフォーマンスの結果を検証し、ベンチマークをローカルで実行するには:

1. AndroidX ガイドに沿ってソースコードを確認します。
2. ヒーロー ベンチマークのソースコードの手順に沿って操作します。

これらのベンチマークは、アプリの最適化対象となる特定のデバイスなど、サポートされている任意のデバイスで実行できます。ただし、公式の結果を検証するには、 同じハードウェア構成を使用してください。