J2ME 程式碼優化實戰：高階架構與低階細節雙管齊下

優化的兩大維度

J2ME 程式碼優化分為高階優化（演算法、架構、整體策略）與低階優化（孤立程式碼片段、單一方法內部）。遊戲主迴圈是優化核心戰場，應優先審視能否減少或消除該區域內的呼叫。

一、高階優化：戰略層面的取捨

1. 「感覺即真實」—— 只做玩家能感知的事

電影布景可用木頭泡沫，只要鏡頭前真實即可。遊戲同理：集中資源在「好玩」與「流暢」上，捨棄玩家無感知的細節運算與渲染。

2. 極致減少物件創建

物件創建頻率直接決定 GC 壓力與幀率穩定性。隱形殺手：g.drawString("Score:" + score, x, y); 每幀產生新 String。對策：僅分數變動時構建字串，或用 StringBuffer 複用。

3. 減少螢幕繪製呼叫

繪圖通常佔用遊戲 60%+ CPU 時間。策略：
• 髒矩形檢測：僅重繪實際變化區域。
• 合併繪製：將多次小圖繪製合併為單次大圖繪製，減少 API 呼叫開銷。
• 預渲染複雜場景：靜態背景、UI 面板預先生成 Image，運行時直接 drawImage。

4. 演算法優化：最高杠桿率的槓桿

選擇正確的資料結構（如空間分割用 QuadTree）、剪枝不必要的碰撞檢測、採用定點運算替代浮點、預計算查找表（三角函數、距離表）等，往往能帶來數量級提升。

二、低階優化：細節決定成敗

1. 預渲染複雜圖像

LCDUI 繪圖極慢。將遊戲狀態資訊（分數、生命、能量）整合至單一面板 Image，一次性更新繪製。

2. 類數量與記憶體的平衡

新增類會增加 JAR 體積，但若能換取顯著的運行期記憶體節省（如飛行權模式替代大量條件判斷），則值得。

3. 複雜數值預計算與快取

例：canvas.getWidth()/getHeight() 每幀呼叫代價不小。啟動時快取至 final int W = getWidth();，後續直接使用。

4. 陣列優於 Vector，一維優於二維

• 陣列存取速度遠快於 Vector。
• 二維陣列 world[y][x] 存取速度僅為一維陣列 world[y * width + x] 的一半。
• 擴容陣列時使用 System.arraycopy 手動複製，避免頻繁重建。

5. 能不用陣列就不用

陣列存取仍慢於直接變數。熱點路徑上若能用標量變數替代陣列索引，果斷替換。

6. 方法聲明的效能階層

static 方法 > final 方法 > 普通方法 > 介面方法 / synchronized 方法
熱點邏輯盡量封裝為 static final 方法；避免在效能敏感處使用介面呼叫或同步鎖。

7. 其他微優化清單

• 異常僅用於真錯誤，不用於流程控制（極慢）
• switch 快於 if-else 鏈
• 字串操作用 StringBuffer，勿用 +
• 避免內部類（隱含外部引用、存取較慢）
• 用畢引用立即 null
• 勿手動初始化為 null/0，VM 會自動完成
• 能 static 就 static（方法與欄位皆適用）
• 避免類型轉換

結語

J2ME 優化無銀彈，唯有「高階定方向，低階抓細節」的系統性工程。將這些準則內化為編碼肌肉記憶，才能在 KB 級記憶體與 MHz 級 CPU 上跑出流暢體驗。