建置驗證：一鍵產出多平台 JAR Build → Build All Main Project Configurations。dist/ 目錄下將產生： dis

背景：設備碎片化是 J2ME 開發最大噩夢 同一款遊戲需適配 Nokia S40/S60、Motorola、Siemens、Sony Ericsson 等數十個

工具類設計哲學：小而專、零依賴、可複用 MIDP 2.0 雖提供 Sprite、Graphics，但實戰中仍需資源載入保護、實體狀態封裝、高效文字渲染三大基建。

專案現狀：Clone 完成，但還遠未結束 遊戲跑通了，但代碼結構仍是「直來直去」：無歡迎界面、無 Loading、無幫助、無場景切換管理。Navigate 類還

J2ME 不是單一規範，而是家族 1999 年 Sun 發布 Java 2 平台，將 Java 劃分為三版本： J2SE：桌面/低端企業應用 J2EE：企業級

教程系列回顧 本文為 J2ME 101 系列第三部分，聚焦 MIDP 持久化核心——RMS。前情提要：MIDlet 生命週期、高級 UI；後續將講網絡編程。

RMS 核心概念 RecordStore：持久化存儲單元，名稱 ≤ 32 字元、大小寫敏感、套件內唯一。 Record：byte[] + 唯一 recordI

記憶體結構與監測 J2ME 堆記憶體 = 程式碼區（類字節碼、常量池）+ 資源區（Image、Player、byte[]、RMS 緩衝）+ 運行區（物件實例、棧

優化必要性：實時遊戲的生死線 回合制、益智類可容忍百毫秒延遲；但實時動作遊戲（STG、ACT、格鬥）需 ≥10 FPS、輸入響應 < 100 ms。J2ME 裝

為什麼要自己寫數字輸入？ S40 等早期裝置系統輸入法切換繁瑣（多次按鍵切換模式）、彈出遮擋畫面、無法自定義長度/格式。直接在 Canvas 攔截按鍵碼，自行維

痛點：WTK 打包無法處理廠商擴展 API 直接用 WTK 打包引用 Nokia UI、Motorola Multimedia、Siemens 等專有 API

背景：資源受限環境下的 XML 困境 MIDP 1.0 無內建 XML 支援；MIDP 2.0 (JSR 180) 僅提供可選 API。第三方庫成為唯一選擇。主

為什麼選 TimerTask 而非 Thread？ J2ME 裝置 CPU 慢、記憶體少，手動管理執行緒池、同步鎖、睡眠喚醒極易出錯。java.util.Tim

痛點：JAR 太大裝不進手機 功能機時代，許多裝置限制 JAR ≤ 64 KB 甚至 30 KB。圖片資源往往佔 60% 以上體積。與其犧牲功能，不如讓程式「有

為什麼需要專屬日誌框架？ J2ME 開發最令人抓狂的莫過於「真機無控制台」。模擬器上 System.out.println 好用得很，一上實體手機——沒輸出、無

前言 在 J2ME 開發早期，受限於 JAR 包大小與手機儲存空間，開發者常面臨動畫資源佔用過大的難題。傳統做法需將每一幀另存為 PNG 序列圖，不僅增加美術成

以 Note 記事本為例，示範 MVC 在 J2ME 專案中的完整應用：用例分析、類別發現、順序圖設計、程式碼結構。 專案描述 手機記事本功能：新增、瀏覽、修

整理 Nokia 三大機型系列音效播放差異與實作代碼。 1. Nokia S40 (7210/3300) & S60 (3650/7650) - 不支援 MM

CLDC 1.0 不支援浮點運算，MathFP 以整數模擬定點小數，提供健壯、高速、體積小的數學庫，是 J2ME 遊戲物理/軌跡計算的最佳選擇。 基本原則

針對不同平台音效 API 差異，提供三套完整實作：Nokia 專有 Sound API、MIDP 2.0 MMAPI (Player)、MID 檔案播放。 1