J2ME 遊戲優化全書：從 Profiler 定位到極致技巧

優化必要性：實時遊戲的生死線

回合制、益智類可容忍百毫秒延遲；但實時動作遊戲（STG、ACT、格鬥）需 ≥10 FPS、輸入響應 < 100 ms。J2ME 裝置：慢 CPU（50-200 MHz）、無 JIT、小堆（200-500 KB）、無 GPU。每一個 CPU 週期都要算在刀刃上。

何時「不」優化

• 非實時遊戲（回合制、文字冒險）
• 優化引入 Bug 風險 > 效能收益
• 代碼可讀性/可維護性大幅下降
• JAR 體積膨脹超過收益（內聯展開、查表法）
• 單一裝置優化導致其他裝置倒退（極常見）

WTK Profiler 定位熱點：90/10 法則

1. WTK → Edit → Preferences → Monitoring → Enable Profiling
2. 運行遊戲完整流程 → 退出 → Profiler 視窗自動彈出
3. 展開調用樹，尋找自耗時佔比最高的方法（非累積）
4. 典型分佈：paint() 40-60%、gameLoop() 20-30%、其餘 10%

鐵律：只優化佔比 > 10% 的熱點，其餘是微優化，收益極低。

高層優化：演算法與架構層面（跨平台收益）

低層優化：J2ME 特有技巧（謹慎使用，測試驗證）

1. 基本型別與陣列

• int[] 優於 Vector / ArrayList（無裝箱、連續記憶體）
• 避免 new 在循環內：預分配 int[] buffer = new int[MAX] 重複使用
• 位運算替代乘除：x * 2 → x << 1、x / 2 → x >> 1、x % 16 → x & 0xF

2. 方法內聯與最終化

// 差：虛擬呼叫
public void update() { move(); checkCollision(); render(); }

// 好：final 方法 + 內聯（ProGuard 會自動內聯 final 私有方法）
final void move() { ... }
final void checkCollision() { ... }
final void render() { ... }

3. 繪圖 API 選擇

• drawImage > drawRGB > fillRect + drawLine（硬體加速可能性遞減）
• 避免 drawString 在遊戲主循環（字體光柵化極慢），改用圖集字體（參考 Article 78370）
• setClip 限制繪製區域，減少像素填充量

4. 記憶體佈局優化

• 熱點類別欄位順序：int/long 在前，Object 在後（減少對齊填充）
• 大型陣列 static 宣告 → 類載入時分配，避免運行時 OOM
• System.gc() 僅在關卡切換、大量物件釋放後呼叫，平時禁用

實測案例：示例 MIDlet 優化前後

真機 Motorola i85s：原始 52 秒 → 最終 18 秒（2.9× 加速）。

避坑指南

• 模擬器 ≠ 真機：模擬器有 JIT、桌面 CPU，熱點分佈完全不同。必須真機 Profiling（用 System.currentTimeMillis() 手動埋點）。
• 過度內聯：JAR 膨脹導致類載入慢、驗證慢、甚至超過 64 KB 方法限制。
• 查表法記憶體：sin[360] 佔 1.4 KB，若堆 < 100 KB 需權衡。
• 最終版無法維護：保留「可讀版」分支，發布前自動化腳本套用優化。

結語

J2ME 遊戲優化是工程權衡藝術：Profiler 定位熱點 → 高層優化優先 → 低層優化驗證真機 → 保留可讀版。沒有銀彈，只有不斷測試、數據驅動的迭代。記住：**過早優化是萬惡之源，但不優化在 J2ME 上就是死路一條。**