パフォーマンス ジャーニーのレベルアップ ガイド

パフォーマンス スポットライト ウィークの 4 日目へようこそ。R8 オプティマイザー、ベースライン プロファイルと起動プロファイルによるプロファイルに基づく最適化など、最近導入された優れたツールと効果的な手法について説明しました。パフォーマンス改善の取り組みをどこから始めればよいか、疑問に思われるかもしれません。

Google は、モバイル開発チームのレベルに合わせたパフォーマンス レベリング ガイドをステップごとに作成しました。このガイドは、パフォーマンスの改善を始めようとしている 1 人のデベロッパーが開発したアプリにも、Android のパフォーマンス改善に専念しているチーム全体にも対応しています。

パフォーマンス レベリング ガイドには 5 つのレベルがあります。レベル 1 では、導入の労力が最小限で済むパフォーマンス ツールを紹介します。レベル 5 は、カスタム パフォーマンス フレームワークを維持するためのリソースがあるアプリに最適です。

 
ご自身のレベルに合ったセクションに移動してください。

• レベル 1: Google Play Console で提供されるフィールド モニタリングを使用する
• レベル 2: アプリのパフォーマンス スコアのアクション アイテムに沿って対応する
• レベル 3: ローカル パフォーマンス テスト フレームワークを活用する
• レベル 4: Perfetto などのトレース分析ツールを使用する
• レベル 5: 独自のパフォーマンス トラッキング フレームワークを構築する

レベル 1:  Google Play Console で提供されるフィールド モニタリングを使用する

まず、Google Play Console で Android Vitals を活用して、自動的に収集されたフィールド モニタリング データを表示することをおすすめします。これにより、最小限の労力でアプリに関する分析情報を得ることができます。

Android Vitals は、このフィールドのデータを自動的に収集して表示する Google の取り組みです。

このデータの配信方法について説明します。

1. データを収集する: ユーザーがオプトインすると、Android デバイスは、アプリを含むすべてのアプリの主要なパフォーマンスと安定性に関するイベントを自動的に記録します。
2. 集計データ: Google Play は、アプリのユーザーからこのデータを収集し、匿名化します。
3. 分析情報を表示する: データは、Google Play Console の Android Vitals ダッシュボードに表示されます。

Android Vitals のダッシュボードでは多くの指標がトラッキングされますが、そのうちのいくつかは主なバイタルとして指定されています。これらは、Google Play ストアでのアプリの視認性やランキングに影響する可能性があるため、特に重要です。

ウェブに関するコア バイタル

主な指標には、ユーザーが認識したクラッシュ発生率、ANR 発生率、過度のバッテリー使用量、新たに導入された過度の部分的な wake lock の指標が含まれます。

ユーザーが認識した ANR 発生率

Android Vitals の ANR ダッシュボードを使用すると、フィールドで発生した問題のスタック トレースを確認し、問題を解決するための分析情報と推奨事項を取得できます。

発生した特定の ANR をドリルダウンして、スタック トレースと、問題の原因に関する分析情報を確認できます。

また、ANR ガイダンスもご覧ください。ANR が発生する可能性のある一般的なシナリオを診断して修正するのに役立ちます。

ユーザーが認識したクラッシュ発生率

Android Vitals のクラッシュ ダッシュボードを使用して、クラッシュをさらにデバッグし、アプリ内で発生したスタック トレースのサンプルを表示します。

また、特定のクラッシュのトラブルシューティングに関するガイダンスもドキュメントに記載されています。たとえば、フォアグラウンド サービスのトラブルシューティング ガイドでは、クラッシュが発生する一般的なシナリオを特定して修正する方法について説明しています。

バッテリー使用量が多すぎる

Wear OS でバッテリー使用量が過剰なウォッチフェイス セッションを減らすには、バッテリーを改善して節約する方法に関する Wear ガイドをご覧ください。

[新規] 過度の部分的な wake lock

先日、部分的な wake lock の過剰使用のしきい値を超えているアプリは、2026 年 3 月 1 日より追加の措置の対象となる可能性があることをお知らせしました。

モバイル デバイスの場合、Android Vitals 指標は、画面がオフでアプリがバックグラウンドで実行されているかフォアグラウンド サービスを実行している間に取得された、除外されていない wake lock に適用されます。Android Vitals は、24 時間以内に 2 時間以上 wake lock が保持され、それがアプリのセッションの 5% 以上に影響している場合（28 日間の平均）に、部分的な wake lock の使用が過度であると判断します。

過剰なウェイクロックの問題をデバッグして修正するには、技術ブログの投稿をご覧ください。

Android Vitals のドキュメントを参照して、Android Vitals をより有効に活用するための取り組みを続けてください。

レベル 2: アプリのパフォーマンス スコアのアクション アイテムに沿って対応する

次に、アプリのパフォーマンス スコアを使用して、アプリのパフォーマンスをレベルアップするための効果的なアクション アイテムを見つけます。

Android アプリのパフォーマンス スコアは、アプリの技術的パフォーマンスを測定するための標準化されたフレームワークです。スコアは 0 ～ 100 の範囲で表示され、数値が低いほど改善の余地が大きいことを示します。

簡単に成果を上げるには、まず 静的パフォーマンス スコアから始める必要があります。多くの場合、構成の変更やツールの更新により、パフォーマンスが大幅に向上します。

ステップ 1: 静的評価を実施する

静的評価では、プロジェクトの構成とツールの導入状況が評価されます。多くの場合、これらはパフォーマンスを改善する最も迅速な方法です。

スコアボード ページの [静的スコア] セクションに移動して、次の操作を行います。

1. Android Gradle プラグイン（AGP）のバージョンを評価します。
2. R8 の縮小を段階的に採用するか、理想的には R8 をフルモードで使用して、アプリコードを縮小して最適化します。
3. ベースライン プロファイルを採用します。これにより、初回起動からコード実行速度が向上し、すべての新規アプリ インストールとすべてのアプリ アップデートでパフォーマンスが向上します。
4. 起動プロファイルを採用して Dex レイアウトを改善します。起動プロファイルは、ビルドシステムによって使用され、APK の DEX ファイル内のコードのレイアウトを改善することで、クラスとメソッドをさらに最適化します。
5. Jetpack Compose の最新バージョンにアップグレードする

ステップ 2: 動的評価を実施する

静的な簡単な改善を適用したら、動的な評価を使用して実際のデバイスで改善を検証します。まず、実機とストップウォッチを使って手動で測定します。

スコアボード ページの [Dynamic Score] セクションに移動して、次の操作を行います。

1. 実機でテスト環境をセットアップします。パフォーマンスの問題を誇張して見つけやすくするために、ローエンドのデバイスの使用を検討してください。
2. ランチャーから起動時間を測定します。ランチャー アイコンからアプリをコールド スタートし、操作可能になるまでの時間を測定します。
3. 通知からのアプリ起動時間を測定し、通知からの起動時間を数秒未満に短縮することを目標とします。
4. コア画面とアニメーションをスクロールして、レンダリング パフォーマンスを測定します。

これらの手順を完了すると、静的スコアと動的スコアの 1 ～ 100 のスコアが表示され、アプリのパフォーマンスと注力すべき分野を把握できます。

レベル 3: ローカル パフォーマンス テスト フレームワークを活用する

動的パフォーマンスの評価を開始すると、手動でパフォーマンスを測定するのが面倒になることがあります。Macrobenchmark や UiAutomator などのパフォーマンス テスト フレームワークを使用して、パフォーマンス テストの自動化を検討してください。

Macrobenchmark 💚 UiAutomator

Macrobenchmark と UiAutomator は連携して動作する 2 つのツールと考えることができます。Macrobenchmark は測定ツールです。これは、アプリの外部で実行されるストップウォッチとフレームレート カウンタのようなものです。アプリの起動、指標（起動時間やドロップしたフレームなど）の記録、アプリの停止を行います。UiAutomator はロボット ユーザーです。このライブラリを使用すると、デバイスの画面を操作するコードを記述できます。アイコンの検索、ボタンのタップ、リストのスクロールなどを行うことができます。

テストの作成方法

テストを作成するときは、UiAutomator コードを Macrobenchmark ブロック内にラップします。

1. テストを定義する: @MacrobenchmarkRule を使用します。
2. 測定を開始する: benchmarkRule.measureRepeated を呼び出します。
3. UI を操作する: そのブロック内で、UiAutomator コードを使用してアプリを起動し、UI 要素を見つけて操作します。

スクロール ジャンクのコンポーズ リストをテストするコード スニペットの例を次に示します。

benchmarkRule.measureRepeated(

    // ...

    metrics = listOf(

        FrameTimingMetric(),

    ),

    startupMode = StartupMode.COLD,

    iterations = 10,

) {

    // 1. Launch the app's main activity

    startApp()

    // 2. Find the list using its resource ID and scroll down

    onElement { viewIdResourceName == "$packageName.my_list" }

        .fling(Direction.DOWN)

}

4. 結果を確認する: 各テスト実行では、アプリのパフォーマンスに関する最適なデータを得るために、正確に測定された情報が提供されます。

timeToInitialDisplayMs  min  1894.4,   median 2847.4,   max  3355.6


frameOverrunMs          P50 -3.2,  P90  6.2, P95  10.4, P99  119.5

一般的なユースケース

Macrobenchmark には、すぐに使用できるコア指標がいくつか用意されています。StartupTimingMetric を使用すると、アプリの起動を正確に測定できます。FrameTimingMetric を使用すると、テスト中のアプリのレンダリング パフォーマンスを把握できます。

Macrobenchmark と UiAutomator を コードサンプルとともに使用するための詳細な完全ガイドが用意されています。

レベル 4: Perfetto などのトレース分析ツールを使用する 

Perfetto などのトレース分析ツールは、独自のアプリケーション コード以外を確認する必要がある場合に使用します。プロセスのみを対象とする標準のデバッガやプロファイラとは異なり、Perfetto はデバイスの状態全体（カーネル スケジューリング、CPU 周波数、その他のプロセス、システム サービスなど）をキャプチャするため、パフォーマンスの問題に関する完全なコンテキストが得られます。

システム トレース、Android Studio Profiler、Perfetto を使用したパフォーマンス デバッグの動画による手順については、パフォーマンス デバッグの YouTube 再生リストをご覧ください。

Perfetto を使用してパフォーマンスをデバッグする方法

トレース分析ツールを使用してパフォーマンスをデバッグする一般的なワークフローは、トレースを記録、読み込み、分析することです。

ステップ 1: トレースを記録する

システム トレースは、いくつかの方法で記録できます。

• デバイスで開発者向けオプションから直接トレースを手動で記録します。
• Android Studio CPU Profiler を使用する
• Perfetto UI を使用する

ステップ 2: トレースを読み込む

トレース ファイルを取得したら、分析ツールに読み込む必要があります。

1. Chrome を開き、ui.perfetto.dev に移動します。
2. .perfetto-trace（または .pftrace）ファイルをブラウザ ウィンドウに直接ドラッグ＆ドロップします。
3. UI でファイルが処理され、タイムラインが表示されます。

ステップ 3: トレースを分析する

パフォーマンスの問題を調査するには、Perfetto UI または Android Studio Profiler を使用できます。パフォーマンスに関する MAD スキルシリーズのこのエピソードでは、パフォーマンス エンジニアの Carmen Jackson が Perfetto トレースビューアについて説明しています。

Perfetto を使用してシステム トレースを検査するシナリオ

Perfetto はエキスパート向けのツールで、トレースのキャプチャ中に Android デバイスで発生したすべての情報を提供できます。これは、標準ログや基本的なプロファイラを使用して速度低下の根本原因を特定できない場合に特に役立ちます。

ジャンク（フレーム落ち）のデバッグ

スクロール中にアプリがカクカクする場合は、Perfetto を使用して、特定のフレームが期限に間に合わなかった理由を正確に確認できます。

アプリが原因の場合は、メインスレッドが長時間実行されていて、重い解析を行っていることがわかります。これは、作業を非同期処理に移動する必要があるシナリオを示しています。

システムが原因の場合、メインスレッドが実行準備完了状態になっているにもかかわらず、CPU カーネル スケジューラが別のシステム サービスを優先したため、アプリが待機状態になっている（CPU 競合）可能性があります。これは、プラットフォーム API の使用を最適化する必要があるシナリオを示しています。

アプリの起動が遅い場合の分析

起動は複雑で、システム init、プロセス フォーク、リソース読み込みが含まれます。Perfetto はこのタイムラインを正確に可視化します。

バインダー呼び出し（プロセス間通信）を待機しているかどうかを確認できます。onCreate がシステム PackageManager からのレスポンスを長時間待機している場合、Perfetto はそのブロック状態を明確に示します。

アプリの起動時にアプリが必要以上の処理を行っているかどうかも確認できます。たとえば、アプリで表示する必要があるよりも多くのビューを作成してレイアウトしている場合、これらのオペレーションがトレースに表示されます。

バッテリーの消耗と CPU 使用率の調査

Perfetto はシステム全体を把握しているため、目に見えない電力消費を見つけるのに最適です。

[デバイスの状態] トラックで、wake lock を保持してデバイスがスリープ状態になるのを妨げているプロセスを特定できます。詳しくは、ウェイクロックに関するブログ投稿をご覧ください。また、Perfetto を使用して、バックグラウンド ジョブが頻繁に実行されているか、CPU を不必要に起動しているかを確認します。

レベル 5: 独自のパフォーマンス トラッキング フレームワークを構築する

最終レベルは、パフォーマンス トラッキング フレームワークを維持するためのリソースを備えたチームがあるアプリを対象としています。

Android でカスタム パフォーマンス トラッキング フレームワークを構築するには、いくつかのシステム API を活用して、アプリのライフサイクル全体（起動から終了まで）と、特定の高負荷シナリオでデータをキャプチャする必要があります。

ApplicationStartInfo、ProfilingManager、ApplicationExitInfo を使用すると、アプリの起動方法、実行中の動作の詳細情報、終了理由をレポートする堅牢なテレメトリー システムを作成できます。

ApplicationStartInfo: アプリの起動方法をトラッキングする

Android 15（API 35）以降で利用可能な ApplicationStartInfo は、アプリの起動に関する詳細な指標をフィールドで提供します。データには、コールド スタート、ウォーム スタート、ホット スタートのいずれであったか、およびさまざまな起動フェーズの期間が含まれます。

これにより、本番環境データを使用して、ローカルで再現することが難しい可能性があるベースラインのスタートアップ指標を開発し、さらに最適化できます。これらの指標を使用して、起動フローを最適化する A/B テストを実行できます。

目標は、すべての初期化フェーズを手動で計測することなく、起動指標を正確に記録することです。

このデータは、アプリの起動後しばらくしてから遅延的にクエリできます。

ProfilingManager: 処理が遅かった理由をキャプチャ

ProfilingManager（API 35）を使用すると、アプリでユーザーのデバイスのシステム トレースをプログラムでトリガーできます。これは、ローカルで再現できない一時的なパフォーマンスの問題を検出するのに役立ちます。

目標は、特定のクリティカル ユーザー ジャーニーが遅く実行されているか、パフォーマンスの問題が発生していることが検出されたときに、トレースを自動的に記録することです。

特定の条件が満たされたときにトリガーされるリスナーを登録するか、ジャンク、過剰なメモリ、バッテリーの消耗などのパフォーマンスの問題を検出したときに手動でトリガーできます。

プロファイルをキャプチャする方法、プロファイリング データを取得して分析する方法、デバッグ コマンドを使用する方法に関するドキュメントをご覧ください。

ApplicationExitInfo: アプリが終了した理由をトラッキング

ApplicationExitInfo（API 30）は、以前のプロセスが終了した理由を示します。これは、メモリ使用量の過剰（OOM）によるネイティブ クラッシュ、ANR、システム強制終了を見つけるうえで重要です。また、API getTraceInputStream を使用して、詳細な墓石トレースを取得することもできます。

この API の目的は、標準の Java クラッシュ レポーター（ローメモリ キルなど）をトリガーしない安定性の問題を把握することです。

この API は、 次回のアプリ起動時にトリガーする必要があります。

対処方法

Android のパフォーマンスの向上は、段階的な取り組みです。これらのツールを活用してパフォーマンスを向上させることを楽しみにしています。

明日の Ask Android をお楽しみに

R8 でアプリを圧縮し、プロファイルに基づく最適化でランタイムを最適化しました。アプリのパフォーマンスを測定します。

明日の Ask Android ライブ セッションにご参加ください。「#AskAndroid」を付けて質問をお寄せください。エキスパートが回答します。