J2ME 遊戲開發實戰筆記：IO 優化、壓縮策略、移植技巧與按鍵處理

前言

J2ME 遊戲開發面臨嚴苛的資源限制，本文分享實戰經驗：IO 讀取優化、資源壓縮決策、跨機型移植策略、按鍵事件差異處理，助開發者避開常見陷阱。

一、IO 讀取優化：簡單流勝過複雜流

初期使用 DataInputStream 包裝 InputStream 讀取地圖資料，耗時 1242ms。改用單純 InputStream 直接讀取 byte，降至 1065ms（省 ~200ms）。嘗試一次性讀入緩衝區反而變慢（1154ms），證實頻繁小量讀取在 KVM 上未必比大塊讀取慢。封裝讀取方法拆分 try 區塊雖減小 class 大小，但執行速度微增（1089ms），得不償失。結論：能用簡單流勿用複雜流，實測為準。

二、資源壓縮：JAR 內建壓縮下的誤區

嘗試對地圖檔做行程長度編碼（RLE），檔案從 2.23KB 壓至 900 bytes，但打包後 JAR 卻變大（185 → 216 bytes）。原因：JAR 本身為 ZIP 壓縮格式，預先壓縮反而降低壓縮率。同理，PNG 經優化工具處理後在 JAR 中可能變大。建議：壓縮前先觀察檔案在 JAR 內實際大小，必要時才處理。

三、移植一法：介面集中管理靜態字串

定義介面（如 StringTable）集中遊戲所有靜態字串，實作該介面的類別即可存取。移植時僅修改介面常數。座標定位採用 getWidth()、getHeight()、Font.stringWidth() 避免硬編碼，大幅降低移植工作量。

四、按鍵響應差異：Nokia S40 系列的單鍵限制

實測 Nokia 7210/3100 一次僅接受一個按鍵事件：按住 Up 不放再按 Left，精靈不會轉向；鬆開 Up 後才產生 Left 的 keyPressed。WTK 模擬器支援多鍵同時觸發，可斜向移動。開發時需針對目標機型設計輸入處理邏輯（如緩衝隊列、優先順序）。

五、多機型移植版本規劃

依平台差異建議維護 6 個版本：

1. Nokia S40 (MIDP 1.0 + Nokia UI)
2. Nokia S60 (MIDP 1.0 + Nokia UI)
3. Nokia MIDP 2.0 (6600, 7610 等)
4. Moto V 系列 (MIDP 2.0)
5. Sony Ericsson (MIDP 2.0)
6. 三星 S100/S200/C100 (MIDP 2.0)

六、關鍵開發經驗彙總

• 螢幕尺寸差異最大，遊戲必須自適應。
• 避免直接使用 MIDP 2.0 Game API，自行封裝切圖、旋轉功能利於移植；注意 S60 不支援建立可變透明圖片。
• Nokia 6600/7610 UI API 圖片旋轉有缺陷，改用 MIDP 2.0 標準 API。
• MIDP 2.0 裝置間程式碼大致通用，但細節仍存差異（如 SE 不支援全螢幕）。
• 音效：S40 放棄（容量限制、音質差）；其他支援 MIDI/WAV，但無裝置支援雙 MIDI 同播；Moto/SE 可 MIDI+WAV 同播，Nokia 僅單一音軌。