記憶體最佳化是 Android 裝置提供穩定高效能遊戲體驗的關鍵。本指南將說明記憶體效率的重要性、Android 作業系統如何管理程序記憶體限制，以及 Google Play 管理中心的新記憶體指標，協助您監控及提升遊戲的技術品質。
記憶體最佳化的重要性
為維持玩家留存率、擴大裝置相容性，以及遵守平台品質標準，請務必最佳化遊戲的記憶體：
- 避免冷啟動 (使用者體驗和留存率)：當玩家暫時切換離開遊戲 (例如接聽通知或查看訊息)，作業系統會將遊戲程序置於背景。如果遊戲的背景記憶體用量過高，系統的記憶體不足終止工具 (LMK) 會優先終止遊戲程序，以便回收 RAM 供前景工作使用。下次使用者繼續遊戲時，遊戲必須經過漫長的冷啟動程序，從儲存空間完全重新載入大量圖像資產、音訊和遊戲引擎二進位檔，而不是無縫即時的暖啟動。將背景記憶體用量維持在低點，可避免這類無聲的背景終止作業，保留使用者狀態，確保玩家能立即繼續工作階段。如要進一步瞭解系統 LMK 行為，請參閱「Android Vitals - Low memory killers」指南。
- 生態系統和裝置穩定性：記憶體用量效率不彰和記憶體流失會導致整體系統健康狀態惡化。系統記憶體不足時，系統會面臨嚴重壓力，導致影格速率下降、UI 延遲和音訊故障。如果記憶體壓力過大，系統的低記憶體終止程序 (LMK) 會積極終止背景程序，導致其他應用程式冷啟動緩慢，且玩家在工作之間切換時會遺失使用者狀態。
- 平台層級終止：從 Android 17 (API 級別 37) 開始，系統會更主動終止使用過多記憶體的程序。如果遊戲的足跡過大，OS 可能會突然終止遊戲程序，而不會產生標準堆疊追蹤記錄。
- 裝置相容性：旗艦裝置的 RAM 為 12 GB 到 16 GB，但全球有大量遊戲玩家使用 RAM 為 4 GB 或 6 GB 的裝置。妥善管理記憶體可確保遊戲在所有硬體層級都能存取及回應，無須複雜的獨立資產包。
瞭解 Android 中的記憶體
如要設計有效的記憶體預算策略，開發人員必須瞭解 Android 平台如何管理實體記憶體，以及如何測量遊戲的有效足跡。
Android 記憶體核心概念
如要瞭解平台層級記憶體管理的基本概念，請參閱官方的「記憶體管理總覽」說明文件。這項資源涵蓋四個架構領域：
- 記憶體總覽：Android 會使用分頁和記憶體對應 (mmap) 管理 RAM。ChromeOS 不支援磁碟上的傳統交換檔案，而是依賴頁面壓縮 (使用 zRAM) 和頁面回收，以釋放實體記憶體。
- 程序之間的記憶體配置：Android 會在整個系統中共用 RAM。系統會為 Dalvik 或 ART 虛擬機器執行作業指派特定堆積，同時允許原生開發環境 (例如 C++ 遊戲引擎) 從原生系統堆積要求記憶體。
- 應用程式記憶體管理：Android 採用多程序模型，因此應用程式必須動態監控生命週期狀態，並主動釋出不必要的資源 (例如未快取的圖像和點陣圖)，以維持系統健康狀態。
- 程序和執行緒總覽：系統會根據程序目前的使用者感知可見度和重要性，將程序分類到階層中，判斷在記憶體不足時要保留哪些程序，以及優先終止哪些程序。
記憶體總用量指標
平台層級的 Android 17 記憶體限制器會使用「記憶體總用量」，而非常駐記憶體總大小 (RSS) 或虛擬記憶體大小，評估程序耗用量。
記憶體總用量 = 匿名 RSS (RssAnon) + 未壓縮的交換空間 (VmSwap)
為避免遊戲超出平台限制，您必須確切瞭解這些指標在系統層級代表的意義。如要進一步瞭解這些指標、實體 RAM 分配情形，以及檔案支援頁面的處理方式，請參閱「監控記憶體用量」指南中的「瞭解 RSS 和交換指標」。
記憶體限制
為維持系統穩定，並確保應用程式不會耗用過多資源，Android 平台會管理執行中程序的記憶體限制。
Android 17 以上版本的記憶體限制器
Android 17 (API 級別 37) 以上版本會使用 Linux cgroup v2 管理嚴格的應用程式專屬記憶體限制，避免個別應用程式造成全系統不穩定。如要進一步瞭解技術實作方式，請參閱 AOSP 記憶體限制器指南和「優先提升記憶體效率：Android 17 的必要步驟」網誌。
- 機制：記憶體限制器會監控所有應用程式程序，並根據程序的生命週期狀態動態指派限制：
- 可見程序 (前景)：目前顯示 UI 的應用程式程序預期會執行較大的資源工作集，並獲得較寬裕的限制。
- 不可見的程序 (背景或服務)：應用程式程序在未顯示 UI 的情況下執行工作時，會受到更嚴格的預算限制。
- 核心屬性：這項服務主要依賴兩項屬性：
memory.high：軟性限制。如果超出上限，核心就會節流程序，並嘗試積極回收記憶體。這項回收作業可能會導致遊戲效能降低。memory.swap.max：管理程序可使用的交換空間或 zRAM 空間上限。
- 終止行為：如果程序在
memory.high後持續分配匿名記憶體，並耗盡交換容量，分配作業就會失敗，而 OS 會在不發出通知的情況下終止程序。系統會使用 Memory Limiter 結束原因 (Android 17 開始提供，26Q4) 下的ApplicationExitInfo記錄這項終止作業。
Play 管理中心 Android Vitals 的記憶體限制
為協助開發人員主動找出記憶體問題，Google Play 將在 Play 管理中心的 Android Vitals 中推出新指標。Play 管理中心會追蹤遊戲工作階段的第 90 百分位數 (P90) 匿名 RSS + 交換空間記憶體用量，找出極端離群值。
系統會根據裝置的實體 RAM 容量和程序狀態，調整警告和強制執行門檻。這兩項限制會分兩個階段套用。
如需詳細指南和記憶體限制，請參閱「Android Vitals - 不良行為門檻是什麼？」一文。
使用者感知服務
可感知服務是 Android 系統認為使用者會注意到的重要背景程序。這個狀態包含所有正在執行的程序：
- 前景服務 (FGS)
- 加急作業
- 使用者啟動的資料移轉作業
- 受系統限制的服務或受其他應用程式限制的服務
由於「可感知服務」專為背景中長時間執行的重要工作設計，因此非常容易發生累計生命週期洩漏。Android 平台記憶體限制會將此狀態視為非前景，也就是說，如果遊戲已移至背景，但仍持續執行可察覺的服務，就會受到 Play 說明中心頁面中較嚴格的背景或服務記憶體限制。遊戲從前景移至背景可察覺服務狀態時，必須積極修剪不必要的資產。
R8 需求條件
為盡量縮減位元碼大小並減少基本 Java 程序負荷，Google Play 管理中心會根據應用程式品質指南評估程式碼最佳化程度。如要進一步瞭解如何設定建構管道，請參閱「使用 R8 啟用應用程式最佳化功能」指南。
如要在專案中設定 R8，請按照「使用 R8 啟用應用程式最佳化功能」指南操作。如要啟用進階縮減和最佳化設定，請參閱「以完整模式使用 R8」。如要找出哪些規則會導致 R8 無法混淆處理類別或移除無效程式碼，請使用 R8 設定分析器。
點陣圖規定
在現代高保真遊戲中，點陣圖占據了記憶體用量的絕大部分。由於點陣圖像素資料會直接儲存在 Android 8.0 (API 級別 26) 以上版本中未受管理的原生堆積中，因此未經最佳化的圖片載入作業可能會導致程序超出平台記憶體門檻。如需圖片縮放和快取最佳做法，請參閱「最佳化圖片使用方式」。
監控記憶體用量
如要有效最佳化遊戲的記憶體，您必須先瞭解 Android 平台如何測量記憶體用量。Android 17 更新了記憶體指標，可追蹤匿名 RSS (RssAnon) 和未壓縮交換空間 (VmSwap) 的總和，但不包括檔案支援或 GPU 私有記憶體。本指南詳細說明如何運用 Perfetto 和 meminfo 等系統層級工具、實作 ProfilingManager 和 onTrimMemory 等診斷 API，以及在 Unity 和 Unreal Engine 中擷取精確的記憶體配置。瞭解如何準確分析遊戲，並避免傳統執行階段記憶體輪詢造成的效能延遲。
詳情請參閱「監控記憶體用量」。
減少記憶體用量的策略
遊戲引擎可簡化跨平台開發作業，但預設的記憶體處理方式可能會觸發 OS 層級的記憶體限制。本頁詳細說明專為 Unity 和 Unreal Engine 量身打造的實用最佳化步驟。瞭解為何依賴 Java 型 onTrimMemory 可能導致 Unity 發生死結，以及如何改用原生生命週期回呼。此外，您也會瞭解關鍵素材層級的最佳化做法，例如使用 ASTC 8x8 材質壓縮和設定素材卸載，確保遊戲在所有硬體層級都能順暢運作。
詳情請參閱「減少記憶體用量」。