J2ME 遊戲記憶體優化實戰：從 String 陷阱到 Enumeration 替代方案

為什麼 64KB 堆上 GC 會成為噩夢

桌面 Java 有 GC 托底，但早期 J2ME 手機僅 64KB 堆，若不慎重分配，GC 每 10 秒介入一次，幀率直接崩盤。兩個經典「隱形分配」殺手：

殺手一：字符串拼接在 paint 迴路

// 看似無害，實則每幀創建新 String 對象
g.drawString("score=" + score, 50, 50, Graphics.TOP | Graphics.LEFT);

等價於：

String scoreStr = "score=" + score; // 新對象
g.drawString(scoreStr, 50, 50, ...);

對策：預分配 char[] 或 StringBuffer 復用，或將數字轉字符串移出渲染迴路。

殺手二：Enumeration 遍歷容器

Enumeration 無 reset()，每次遍歷必須 v.elements() 產生新實例：

for (Enumeration e = v.elements(); e.hasMoreElements(); ) {
    System.out.println(e.nextElement()); // 每幀新 Enumeration
}

對策：回歸下標遍歷，零分配：

for (int i = 0, n = vector.size(); i < n; i++) {
    System.out.println(vector.elementAt(i));
}

實戰檢測：WTK Memory Monitor

善用 WTK 監視器實時觀察堆變化，定位分配熱點，將 Lag 消滅於無形。核心原則：熱路徑零分配，對象池復用，引用置 null 釋放。