前言
J2ME 開發最大的挑戰非語言本身，而是海量設備的差異性 Bug。本文彙總 Nokia、Motorola、Sony Ericsson 經典機型的高頻問題及規避方案，供維護舊專案或研究設備適配層參考。
Nokia 系列
| 機型/平台 | 典型 Bug | 規避方案 |
|---|
| S40 | 按鍵響應延遲；中斷後原線程持續運行至 repaint()；內存管理不當導致死機 | 按鍵去抖動；pauseApp 明確停止線程；嚴控對象創建、及時置 null |
| 6600/3650 (S60 v1) | readFully() 無法按指定字節讀取；setClip()+drawRegion() 裁剪失效（歐版 6600/3650） | 改用 readByte() 循環；自行計算裁剪區用 clipRect+drawImage 繪製子區 |
| 3650 | 頻繁 I/O 導致死機 | 啟動時一次性讀取所有資源入內存 |
| NG (N-Gage) | 離屏緩衝上 setClip+drawRegion 完全失效；聲音播放在 I/O 後易卡頓 | 改用 Nokia UI API drawImage；聲音播放前插入 Thread.yield() 或延後觸發 |
| 7610 | drawRegion 極慢；PNG-24 繪製撕裂；繪圖調用不當死機 | 優先用 Nokia UI drawImage；圖片轉 PNG-8/16；規範繪圖調用順序 |
| 6681 | 同 S60 v2 通用問題 | 參考 S60 v2 適配層 |
Motorola 系列
| 機型 | 典型 Bug | 規避方案 |
|---|
| V300 | 屏幕非標準 176×208，頂部佔用狀態欄 | 動態獲取 Canvas.getWidth/Height()，勿硬編碼 |
| C650 | 系統字體極大；setMediaTime 不支援；playerUpdate 回傳 Player 副本 | 自繪字體；時間控制改用 Player.getMediaTime() 輪詢；比較 Player 用 equals() 而非 == |
Sony Ericsson 系列
| 機型 | 典型 Bug | 規避方案 |
|---|
| K700 | 220×176 大屏；其餘表現良好 | 適配 220 寬度，資源提供多套分辨率 |
| S700 | getGameAction() 無法映射軟鍵 -6/-7 | 直接在 keyPressed 判斷原生碼 -6/-7 |
通用適配原則
- 能力檢測優於機型檢測：用
System.getProperty()、Class.forName() 檢測 API 存在性，而非硬編碼機型列表。
- 抽象繪圖/聲音/存儲層：定義統一介面，具體實現按平台注入（Strategy Pattern）。
- 資源多備份：同一圖片準備 128×128、176×208、220×176、240×320 等多套。
- 真機測試金字塔：模擬器 → 核心機型 3-5 台 → 邊緣機型抽樣 → 自動化壓力測試。
結語
雖然 J2ME 時代已逝，但「碎片化適配」的經驗直通 Android 早期、IoT 嵌入式開發：建立設備特性庫、編寫自適配層、持續真機回歸，始終是跨平台交付的核心功課。
