J2ME 核心知識體系
必備 Java 基礎
- 語法基礎：基本數據類型、關鍵字、運算符、流程控制
- 面向對象：類/對象、封裝/繼承/多態、接口與抽象類
- 異常處理：try-catch-finally、throws、自定義異常
- 多線程：Thread/Runnable、同步機制、生產者消費者模式
J2ME 不包含的標準 Java 特性
- 無 javac/java 命令行工具鏈（依賴 WTK/IDE 編譯打包）
- 大量 J2SE 類庫缺失或精簡：Collections 框架縮減、無反射 API、I/O 流簡化
- 完全無 AWT/Swing/Applet 圖形庫，改用 LCDUI (javax.microedition.lcdui)
J2ME 當前技術邊界（臨時無法實現）
- 免適配移植：螢幕尺寸、按鍵映射、API 差異導致遊戲需機型適配
- 靜態修改軟鍵文本：系統保留鍵不可動態修改標籤
- Canvas 直接輸入中文：需自行實現輸入法引擎或調用系統輸入法（機型相關）
- 訪問本地資源：通訊錄、短信、通話記錄等受沙箱隔離，需簽名權限或 JSR-75/PIM API 支持
- 破壞性病毒：沙箱模型限制文件系統/網絡訪問，無法實現傳統病毒行為
跨平台性現狀分析
理想與現實的差距
雖然基於 JVM 理論上「一次編寫，到處運行」，但移動設備碎片化極嚴重：
- 螢幕分辨率：96×65 到 320×240 甚至更高，高級 UI (Form/List) 自適應較好，低級 UI (Canvas/GameCanvas) 需手動適配座標與資源圖
- 鍵盤佈局：數字鍵、方向鍵、軟鍵映射差異大，遊戲按鍵處理需抽象適配層
- API 實現差異：廠商對 MIDP/CLDC 規範實現不一，甚至擴展專有 API (Nokia UI, Siemens API, Motorola SDK 等)
- 性能基線：CPU 主頻 20-200MHz，堆內存 100KB-2MB，GC 行為差異大
高級 UI vs 低級 UI 選型
| 場景 | 推薦 UI | 適配成本 |
|---|
| 表單輸入、列表展示、登錄註冊 | 高級 UI (Form, List, TextBox, ChoiceGroup) | 低，系統自適應佈局 |
| 遊戲、繪圖、自定義動畫、複雜交互 | 低級 UI (Canvas, GameCanvas) + 精靈/圖層管理 | 高，需多套資源圖、座標計算、按鍵映射 |
實戰避坑清單
- 資源文件管理：將圖片/音頻放入 /res 目錄，用
getClass().getResourceAsStream() 載入，打包進 JAR
- RecordStore 持久化：唯一本地存儲機制，注意同步鎖、記錄枚舉關閉、存儲配額限制
- 網絡編程：HttpConnection 採用非阻塞或獨立線程，處理重定向、超時、斷點續傳，適配 GPRS/EDGE/3G 切換
- 內存優化：對象池復用、圖片及時釋放 (
Image.createImage 後用完 dispose())、避免頻繁 GC 導致卡頓
- 簽名與權限：訪問敏感 API (JSR-75, JSR-179, JSR-120) 需廠商/運營商簽名，未簽名僅能測試模擬器
技術演進與歷史定位
J2ME (Java ME) 曾是功能機時代統治級平台，支援 MIDP 2.0/CLDC 1.1 規範。隨著 Android/iOS 智能機普及，J2ME 逐步退出主流舞臺。現代嵌入式 Java 開發轉向 Java ME Embedded 8+、Android NDK 或輕量級 JVM (如 Excelsior JET, Avian)。學習 J2ME 核心價值在於理解受限環境下的資源管理、狀態機設計、協議適配等工程思維。
