ハウツー

パフォーマンス改善のステップアップ ガイド

所要時間: 9 分
Alice Yuan
デベロッパー リレーション エンジニア

パフォーマンス改善のステップアップ ガイド

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

モバイル デベロッパー チームの現状に合わせて、パフォーマンス改善のステップアップ ガイドを作成しました。パフォーマンス改善を始めたい 1 人のデベロッパーが開発するアプリでも、Android のパフォーマンス改善に専念するチームが開発するアプリでも、このガイドをご活用いただけます。

パフォーマンス改善のステップアップ ガイドは 5 つのレベルで構成されています。レベル 1 では、導入に手間がかからないパフォーマンス ツールを紹介します。レベル 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 ストアでのアプリの視認性とランキングに影響する可能性があるため、最も重要です。

コアバイタル

GOOGLE PLAY の技術的な品質に関する主な指標

Google Play での視認性を最大化するには、これらの指標の不正な動作のしきい値を超えないようにアプリを維持してください。

ユーザーが認識したクラッシュ発生率クラッシュが少なくとも 1 回発生した可能性がある 1 日のアクティブ ユーザーの割合です。
ユーザーが認識した ANR 発生率ANR が少なくとも 1 回発生した可能性がある 1 日のアクティブ ユーザーの割合です。
過度のバッテリー使用1 時間あたりのバッテリー使用量が 4.44% を超えたウォッチフェイス セッションの割合です。
新規: 過度の部分的な wake lock累積の免除対象外の wake lock の使用時間が 2 時間を超えるユーザー セッションの割合です。

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

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

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

crashesAnrs.png

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

insights.png

また、ANR が発生する可能性がある一般的なシナリオの診断と修正に役立つANR ガイドもご覧ください。

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

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

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

過度のバッテリー使用

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

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

 

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

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

過度の 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: 動的評価を行う

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

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

  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 要素を見つけて操作します。

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

  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 を使用すると、テスト中のアプリのレンダリング パフォーマンスを把握できます。

MacrobenchmarkUiAutomator の使用に関する詳細なガイドと コードサンプル が用意されています。引き続き学習にご活用ください。

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

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

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

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

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

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

システム トレースは、次の方法で記録できます。

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

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

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

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

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

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

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

ジャンク(フレーム落ち)のデバッグ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ProfilingManager: 低速化の原因をキャプチャする

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

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

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

プロファイルのキャプチャ方法 (how to capture a profile)、プロファイリング データの取得と分析 (retrieve and analyze profiling data)、デバッグ コマンドの使用方法 (debug commands.) については、ドキュメントをご覧ください。

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

ApplicationExitInfo(API 30)は、以前のプロセスが終了した理由を示します。これは、ネイティブ クラッシュ、ANR、メモリ使用量が多すぎる(OOM)ことが原因でシステムが強制終了した場合を見つけるために重要です。また、API getTraceInputStream を使用して、詳細な tombstone トレースを取得することもできます。

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

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

対処方法

Android のパフォーマンス改善は段階的な取り組みです。これらのツールを使用してパフォーマンスを向上させる方法をぜひお試しください。

明日の Ask Android をお楽しみに

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

明日の Ask Android のライブセッションにご参加ください。#AskAndroid を使用して今すぐ質問を送信すると、エキスパートが回答します。

作成者:

続きを読む