J2ME 記憶體優化實戰：OutOfMemoryError 根治指南

痛點回顧

早期功能機 (Nokia 7210, 6600, S40 系列) Heap 僅 200~500 KB。OutOfMemoryError 是遊戲開發頭號殺手，尤其「老 40」(Nokia 3410/7210 等 4096 色機型) 更是移植噩夢。

記憶體分析工具

• Runtime 監控：System.out.println("Free: " + Runtime.getRuntime().freeMemory()); 關鍵節點埋點 (啟動後、載入資源前後、幀循環)。
• WTK Memory Monitor：KToolbar → Tools → Memory Monitor，圖形化觀察分配/回收曲線 (但會大幅降低模擬器幀率)。
• Nokia 7210/3220 模擬器內建監視器：較準確反映真機 Heap 佔用。

程序碼佔用優化

1. 類數量與大小平衡：過少類 → 單類過大 → 載入慢、驗證久、違反「Logo 6 秒」限制；過多類 → 類元數據開銷大。建議 **6~10 個核心類** (Main, Engine, Renderer, ResourceManager, GameLogic, Network, Persistence, Util 等)。
2. 發布前精簡：移除 try-catch (保留關鍵)、刪除調試日誌、縮短標識符 (ProGuard 自動處理)、合併常量字串。
3. 數據外部化：關卡地圖、怪物屬性、文本對話 → 資源文件 (二進制/屬性文件)，getResourceAsStream() 按需載入，用完 null 掉。

資源佔用優化 (大戶)

圖片 — 佔用公式

Heap Bytes = Width × Height × BytesPerPixel

• 4096 色 (12-bit) → 1.5 B/px (Nokia 7210, 3410 等)。
• 65536 色 (16-bit) → 2 B/px (S60 v2, Siemens SL45 等)。
• 例：128×128 圖 → 7210 佔 24 KB，S60 佔 32 KB。

誤區：PNG 壓縮只減小 JAR，**不減少解碼後 Heap 佔用**。

圖片優化策略

1. 靜態縮減：裁剪透明邊框、合併動畫幀為精靈圖、重用身體部位 (如《波斯王子》分割肢體)、緊湊排版每像素利用。
2. 動態載入：關卡制遊戲 — 僅載入本關敵人/場景圖；切關時 oldImg = null; System.gc(); loadNew();。
3. 調色盤複用：4096 色機型統一 12-bit 調色盤，減少色彩轉換開銷。

音頻優化

• MIDI 事件數據較小，但 Manager.createPlayer() 瞬間分配大量緩衝區。
• 轉為 OTT (Nokia 專有) 或 AMR 降低解碼峰值。
• 音效短小優先 Player.prefetch() 預載，播放完 close() 釋放。
• 背景音樂單例循環，避免重複創建 Player。

峰值記憶體管理 (關鍵)

以下操作會產生**短時巨大峰值**，若剩餘 Heap 不足直接 OOM：

• Image.createImage(stream/name) — 解碼緩衝 + 位圖。
• Manager.createPlayer(stream) — 解碼器緩衝。
• RecordStore.openRecordStore() — 索引構建、快照。
• Class.forName() / new Class() — 類載入、驗證。

對策：

1. 錯峰調用：載入圖片 → System.gc() → 載入音頻 → System.gc() → 打開 RMS。
2. 分批載入：大量資源分幀載入 (每幀 1~2 張圖)，配合載入進度條。
3. 顯式 System.gc()：在確定臨時對象不可達後調用，**不可濫用** (會觸發 Full GC 卡頓)。

實戰案例：《火影武士》老 40 移植

• 6 種怪物圖片同時載入 → OOM。
• 分析：每關僅出現 2~3 種怪物。
• 重構：LevelResourcePack 每關專屬資源清單，進關載入、出關釋放。
• 結果：Heap 峰值從 420 KB 降至 280 KB，完美通過老 40 驗證。

現代啟示

雖然 J2ME 年代已遠，但受限環境下的記憶體工程思維 完全適用於：IoT 設備 (FreeRTOS/Zephyr + Java ME Embedded)、Android 低端機優化、GraalVM Native Image 體積控制、WebAssembly 模組大小優化。