メモリ使用量（匿名 RSS + スワップ）

メモリ使用量（匿名 RSS + スワップ）は、アプリのメモリ使用量を反映する Android Vitals の指標です。

匿名メモリとは、ストレージ上のファイルに基づくことのないメモリです（ ヒープ割り当てや mmap で割り当てられたメモリなど）。これには、Java または Kotlin ヒープ、管理されていないネイティブ ヒープ割り当て（Android 8.0（API レベル 26）以降ではビットマップ ピクセルデータがここに格納されます）、スレッド実行スタックなど、アプリの動的メモリ割り当てが含まれます。OS は、負荷がかかっているときにファイルに基づくメモリを削除できますが、匿名メモリは削除できません。

Resident Set Size（RSS）は、物理 RAM に保持されている、プロセスで使用されるメモリページの合計数（共有 ページと非共有ページの両方）です。複数のプロセス（同じライブラリにアクセスするアプリなど）がアクセスする場合、ページは「共有」と見なされます。

匿名メモリの場合、メモリに負荷がかかっているときに、システムはページを スワップ領域（Android では zRAM）に書き込むことができます。 必要に応じて、システムはこれらのページをスワップから読み戻すことができます。

メモリ使用量（匿名 RSS + スワップ）は、ストレージ上のファイルに基づくことのないアプリのメモリページの合計数を測定したものです。これには、システムによってスワップに保持されているメモリも含まれます。匿名 RSS + スワップをトラッキングすることで、アプリの削除できない実際のメモリ使用量を確認できます。

アプリのメモリ使用量が多い場合は、このページのガイダンスに沿ってさらに調査し、問題を修正してください。

高いメモリ使用量を特定する

Android Vitals

Android Vitals では、アプリのメモリ使用量が次の プロセス状態別に分類されます。

  • フォアグラウンド: アプリのプロセスが表示されています。この状態での P99 が高いと、ユーザーが認識するパフォーマンス（ジャンクや OOM クラッシュ）に影響することが多く、不要になった UI コンポーネントやアクティビティを保持することが主な原因です。
  • ユーザーが認識しているサービス: アプリのプロセスが 認識可能な状態で実行されています。これには、フォアグラウンド サービス、緊急 ジョブ、ユーザーが開始するデータ転送ジョブが含まれます。システム バウンド サービスや他のアプリによってバインドされたサービスにも及ぶ可能性があります。これらのサービスは長時間実行されるタスク向けに設計されているため、リークによってメモリを保持したり、リソースを解放できなかったりすると、P99 の末尾が時間とともに膨らむ可能性があります。
  • バックグラウンド: アプリがバックグラウンド サービスを実行しているか、最近 バックグラウンドに移行したものの、まだキャッシュに保存されていません。バックグラウンド処理のリークや解放されていないリソースが複合化される可能性があります。このプロセス状態はフォアグラウンド プロセスや認識可能なプロセスよりも重要度が低いため、この状態で大量のメモリを保持しないようにしてください。
  • キャッシュ済み: アプリがキャッシュされた状態です。この状態は、LMK などのシステムメモリの負荷に非常に敏感です。OS はこのプロセス状態を自由に削除できるため、この状態はデバッグ目的でのみ提供されます。

これらのプロセス状態と onTrimMemory コールバックの関連性を理解するには、 イベントに応答してメモリを解放するのガイダンスをご覧ください。

Android Vitals では、アプリのメモリ使用量が RAM バケット別に分類されます。 メモリ使用量の指標は、50 パーセンタイルと 90 パーセンタイルの最新の日次値とともに、日次パーセンタイル値のタイムラインとして表示されます。

メモリのベースラインを特定したら、ガイダンスに沿って 過剰なメモリ使用量を診断して改善してください。

末尾の歪みを使用してメモリリークを特定する

メモリリークを特定するには、Android Vitals で、一般的なユーザー（P50）と末尾のユーザー（P90）の間に差異がないか確認します。一般的なアセットの肥大化はすべてのパーセンタイルでメモリを均一に膨張させますが、メモリリークは時間とともに複合化され、末尾のデータが大きく歪みます。

プロセス名で P90 指標と P99 指標を P50 ベースラインと比較する必要があります。P90 と P50 の比率が 3.5 倍を超える場合は、セッションの延長中にメモリリークが発生している可能性があります。特定のユースケースでは、比率が高くても必ずしもリークを示すとは限りませんが、特定のワークフローを評価して、メモリ使用量の増加が想定される動作かどうかを判断する必要があります。

リソース

過剰なメモリ使用量をローカルで診断する

過剰なメモリ使用量の原因の診断を開始するには、デベロッパー設定、[Android Studio]、または [Perfetto]の [ヒープダンプを記録]を使用してヒープダンプをキャプチャできます。アプリのコアユーザー ジャーニーをテストしたら、まずローカルでヒープダンプをキャプチャすることをおすすめします。

特に、次のユーザー ジャーニーをテストすることをおすすめします。

  • WebView とアプリ内ブラウザ セッション
  • メディアを多用する無限スクロール
  • アセットの作成と編集のフロー

メモリリークの可能性を調査するには、まず Android Vitals のメモリ使用量ダッシュボードの [プロセス名] テーブルを使用して、最も消費量の多いプロセスを特定します。次に、対応するユーザー ジャーニーをローカルで実行し、さまざまなプロセス状態（表示、フォアグラウンド サービス、キャッシュ）でヒープダンプを収集して、アプリがバックグラウンドに移行した後にメモリを解放するかどうかを確認します。

Android Studio Profiler を使用してメモリの問題をデバッグする場合は、 LeakCanary インテグレーションを使用して、リークと重複する ビットマップの検出を効率化し、画像の使用量を最適化することもできます。

ヒープダンプを収集したら、Android Profiler スキルを使用してヒープダンプを分析し、メモリ使用量が多い原因を特定することをおすすめします。

AI スキルが応答する可能性のある例を次に示します。

I have completed the analysis of memory leaks and bitmap issues for [app] using the provided Perfetto trace.
  Summary of Findings
  The investigation identified a critical memory pressure issue caused by massive bitmap retention within the app process.
...
Recommendations for [app]
   1. [Library] Image Cache Optimization:
       * Review the [Library] caching strategy. Ensure that bitmaps
         loaded for animations are released or downsampled when the animation is
         not in the foreground.
   2. Asset Resolution Audit:
       * The 14.7 MB average size suggests full-screen or extremely high-density assets. Audit the [library] files in the native_home component to ensure they are not using unnecessarily large source images.
   3. View Lifecycle Management:
       * Investigate why 21 [LibraryImage] instances are alive simultaneously. Ensure that views in the bottom
      tab are properly detached or their animations are cleared when switching between tabs.
   4. Fix Surface Leaks:
       * Address the Surface.release failures observed in the logs, as these can lead to both memory leaks and
         native resource exhaustion.

ヒープダンプの解釈に関する追加リソース

ヒープダンプの解釈とメモリ使用量のデバッグの詳細については、次のリソースをご覧ください。

メモリ使用量を改善する

アプリのメモリ使用量を改善する方法について詳しくは、次のセクションをご覧ください。

メモリの問題の修正に関する詳細なガイダンスについては、アプリの メモリを管理するガイドをご覧ください。

前へ
ローメモリ キラー（LMK）
次へ
ビットマップのメモリ使用量