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

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

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

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

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

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

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

リソース

メモリ使用量が多すぎる問題をローカルで診断する

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

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

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

メモリリークの可能性を調査するには、対応するユーザー ジャーニーをローカルで実行し、さまざまなプロセス状態（可視、フォアグラウンド サービス、キャッシュ）でヒープダンプを収集して、アプリがバックグラウンドに移行した後にメモリを解放するかどうかを確認します。これらのプロセス状態と onTrimMemory コールバックの関連性を理解するには、イベントに応答してメモリを解放するのガイダンスをご覧ください。

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

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

android skills add 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.

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

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

• 手動分析: Perfetto ヒープダンプ エクスプローラ ガイダンスを使用して、Perfetto UI でヒープダンプの可視化を操作して解釈する方法を学びます。
• Java/Kotlin の割り当て: Android ランタイム（ART）のヒープダンプを分析する手順については、最初の ART ヒープダンプを可視化するをご覧ください。
• ネイティブ割り当て: Perfetto ネイティブ プロファイリングのドキュメントで、ネイティブ（C/C++）メモリ プロファイルを収集して分析する方法を確認してください。
• CLI 検査: adb dumpsys meminfo を使用して、デバイス上のアプリのメモリ使用量の内訳をすばやく取得します。

メモリ使用量を改善する

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

• アプリのコードとリソースのフットプリントを削減する
• 使用可能なメモリとメモリ使用量を監視する
• メモリ効率の高いコード構造を使用する

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