關於記憶體管理

記憶體最佳化是 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。它不支援磁碟上的傳統交換檔案，而是依賴頁面壓縮 (使用 zRAM) 和頁面回收，釋放實體記憶體。
  • 程序之間的記憶體配置：Android 會在整個系統中共用 RAM。系統會為 Dalvik 或 ART 虛擬機器執行作業指派特定堆積，同時允許原生開發環境 (例如 C++ 遊戲引擎) 從原生系統堆積要求記憶體。
  • 應用程式記憶體管理：Android 採用多程序模型，因此應用程式必須動態監控生命週期狀態，並主動釋出不必要的資源 (例如未快取的圖像和點陣圖)，以維持系統健康狀態。
  • 程序和執行緒總覽：系統會根據程序目前的使用者感知可見度和重要性，將程序分類到階層中，判斷在記憶體不足的情況下，要保留哪些程序，以及優先終止哪些程序。

記憶體總用量指標

平台層級的 Android 17 記憶體限制器會使用「記憶體總用量」，而非常駐記憶體總大小 (RSS) 或虛擬記憶體大小，評估程序耗用量。

記憶體足跡總計 = 匿名 RSS (RssAnon) + 未壓縮的交換空間 (VmSwap)

為避免遊戲超出平台強制執行的限制，開發人員必須瞭解這些指標在系統層級的確切意義。如要進一步瞭解這些指標、實體 RAM 分配情形，以及檔案支援頁面的處理方式，請參閱「監控記憶體用量」指南中的「瞭解 RSS 和交換指標」。

記憶體限制

為維持系統穩定，並確保應用程式不會耗用過多資源，Android 平台會對執行中的程序強制執行記憶體限制。

Android 17 以上版本的記憶體限制器

Android 17 以上版本會使用 Linux cgroup v2 嚴格限制每個應用程式的記憶體用量，避免個別應用程式導致系統不穩定。如要進一步瞭解技術實作方式，請參閱 AOSP 記憶體限制器指南和「優先提升記憶體效率：Android 17 的必要步驟」網誌。

  • 機制：記憶體限制器會監控所有應用程式程序，並根據程序的生命週期狀態動態指派限制：
    • 可見程序 (前景)：目前顯示 UI 的應用程式程序預期會執行較大的資源工作集，因此可享有較寬裕的限制。
    • 非可見程序 (背景或服務)：應用程式程序在未顯示 UI 的情況下執行工作時，會受到更嚴格的預算限制。
  • 核心屬性：這項服務依賴兩項主要屬性：
    • memory.high：軟性限制。如果超出上限，核心會限制程序，並嘗試積極回收記憶體。這項回收作業可能會導致遊戲效能降低。
    • memory.swap.max：強制對程序可使用的交換或 zRAM 空間設定硬性上限。
  • 終止行為：如果程序在 memory.high 後持續分配匿名記憶體，並耗盡交換容量，分配作業就會失敗，而 OS 會無聲無息地終止程序。系統會使用 ApplicationExitInfo，在「Memory Limiter」結束原因下記錄這項終止作業 (適用於 Android 17，26Q4)。

監控記憶體用量

如要有效最佳化遊戲的記憶體，您必須先瞭解 Android 平台如何測量記憶體用量。Android 17 會更新記憶體強制執行指標，追蹤匿名 RSS (RssAnon) 和未壓縮的 Swap (VmSwap) 總和，但不包括檔案支援或 GPU 私有記憶體。本指南詳細說明如何運用 Perfetto 和 meminfo 等系統層級工具、實作 ProfilingManager 和 onTrimMemory 等診斷 API，以及在 Unity 和 Unreal Engine 中擷取精確的記憶體配置。瞭解如何準確分析遊戲，並避免傳統執行階段記憶體輪詢造成的效能延遲。

詳情請參閱「監控記憶體用量」。

減少記憶體用量的策略

遊戲引擎可簡化跨平台開發作業，但預設的記憶體處理方式可能會觸發 OS 層級的記憶體限制。本頁面詳細說明專為 Unity 和 Unreal Engine 量身打造的實用最佳化步驟。瞭解為何依賴 Java 型 onTrimMemory 可能導致 Unity 發生死結，以及如何改用原生生命週期回呼。您也會瞭解關鍵素材層級的最佳化做法，例如使用 ASTC 8x8 材質壓縮和設定素材卸載，確保遊戲在所有硬體層級都能順暢運作。