記憶體用量 (匿名 RSS + 交換空間) 是 Android Vitals 中的指標，可反映應用程式的記憶體用量。
匿名記憶體是指並非由檔案在儲存空間裡支援的記憶體，例如堆積分配和 mmap 分配的記憶體。這會擷取應用程式的動態記憶體配置，包括 Java 或 Kotlin 堆積、未受管理的原生堆積配置 (Bitmap 像素資料位於 Android 8.0 (API 級別 26) 以上版本中)，以及執行緒執行堆疊。雖然 OS 可以在壓力下捨棄檔案支援的記憶體，但無法捨棄匿名記憶體。
常駐集大小 (RSS) 是指程序使用的記憶體頁面總數 (包括共用和非共用)，這些頁面會保留在實體 RAM 中。如果多個程序 (例如存取相同程式庫的應用程式) 存取某個頁面，該頁面就會視為「共用」。
對於匿名記憶體，系統可以在記憶體不足時，將頁面寫入交換空間 (或 Android 上的 zRAM)。如有需要，系統可以從交換空間讀回這些頁面。
總而言之，記憶體用量 (匿名 RSS + 交換) 是指應用程式未由儲存空間中的檔案支援的記憶體頁面總數，包括系統在交換空間中保留的任何記憶體。追蹤匿名 RSS + 交換可確保您看到應用程式真實且無法逐出的記憶體用量。
如果應用程式的記憶體用量偏高，請進一步調查並按照本頁面的指南修正問題。
找出記憶體用量偏高的情況
Android Vitals
Android Vitals 會根據下列程序狀態，提供應用程式的記憶體用量細目：
- 前景：應用程式的程序可見。如果 P99 值偏高，通常會影響使用者感受到的效能 (卡頓或 OOM 異常終止)，且主要原因是未清除的 UI 元件或活動。
- 前景服務：應用程式正在執行前景服務。由於這些服務是為長時間執行的工作所設計，因此是累積生命週期洩漏的主要候選項目，這類洩漏會隨著時間積極膨脹 P99 尾部。
- 背景：應用程式正在執行背景服務，或最近已移至背景，但尚未快取。背景處理作業會在這裡洩漏複合資料。
- 已快取：應用程式處於快取狀態。這個狀態對系統記憶體壓力 (例如 LMK) 非常敏感。由於 OS 可以隨意逐出這個程序狀態，因此這個狀態僅供偵錯。
如要瞭解這些程序狀態與 onTrimMemory 回呼的關聯，請參閱「為回應事件釋放記憶體」指南。
Android Vitals 也會依據 RAM 儲存區細分應用程式的記憶體用量。記憶體用量指標會以每日百分位數值的時間軸顯示，並列出第 50 和第 90 個百分位數的最新每日值。
找出記憶體基準後，請按照指南診斷及改善記憶體用量過高的問題。
使用尾部偏斜找出記憶體洩漏
如要找出記憶體洩漏問題，請在 Android Vitals 中，找出一般 (第 50 個百分位數) 和尾端 (第 90 個百分位數) 使用者之間的差異。一般資源膨脹會使所有百分位數的記憶體平均增加，但記憶體洩漏會隨著時間累積，大幅扭曲尾端資料。
您應根據程序名稱，比較 P90 和 P99 指標與 P50 基準。如果 P90 與 P50 的比率超過 3.5 倍，表示長時間工作階段可能發生記憶體流失。在某些情況下，比例偏高不一定表示有記憶體洩漏問題，但您應評估特定工作流程，判斷記憶體用量偏高是否為預期行為。
資源
在本機診斷記憶體用量過高的問題
如要開始診斷記憶體用量過高的來源，可以使用開發人員選項中的「記錄記憶體快照資料」、Android Studio 或 Perfetto 擷取記憶體快照資料。建議您先測試應用程式的核心使用者歷程，然後在本機擷取堆積傾印。
我們特別建議測試下列使用者歷程：
- 網頁檢視畫面和應用程式內瀏覽器工作階段
- 媒體內容豐富的無限捲動網頁
- 建立及編輯素材資源的流程
如要調查潛在的記憶體洩漏問題，請先使用 Android Vitals 記憶體用量資訊主頁中的「程序名稱」表格，找出用量最高的程序。接著，在本機執行對應的使用者歷程，並在不同程序狀態 (可見、前景服務和已快取) 中收集堆積傾印，確認應用程式在移至背景後是否會釋出記憶體。
如果您使用 Android Studio 分析器偵錯記憶體問題，也可以整合 LeakCanary，簡化記憶體流失偵測作業，並偵測重複的點陣圖，進而最佳化圖片用量。
收集記憶體快照資料後，建議使用 Perfetto AI Skills 分析記憶體快照資料，找出可能導致記憶體用量過高的來源。
以下是 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 分配：請參閱「將第一個 ART 堆積傾印視覺化」，逐步瞭解如何分析 Android 執行階段 (ART) 堆積傾印。
- 原生配置：請參閱 Perfetto 原生分析文件，瞭解如何收集及分析原生 (C/C++) 記憶體設定檔。
- CLI 檢查：使用 adb dumpsys meminfo 快速分析裝置上應用程式的記憶體用量。
- AI 輔助分析：運用 Perfetto AI Skills 執行 LLM 輔助分析，協助偵測追蹤記錄中的記憶體洩漏和過度分配情形。
- 以 SQL 為基礎的分析：使用 Perfetto SQL 和追蹤分析技能，執行結構化查詢和專用指令碼，分析複雜的追蹤資料。
提升記憶體用量
請參閱下列各節，進一步瞭解如何改善應用程式的記憶體用量：
如需修正記憶體問題的詳細指南，請參閱「管理應用程式的記憶體」指南。