痛點分析 RMS 雖提供持久化能力，但原生 API 存在三大短板： 唯一鍵值限於整數 Record ID，無法直接使用 String 等業務鍵值查詢。 枚舉遍

前言 Record Management System (RMS) 是 MIDP 提供的持久化儲存子系統。本文不再贅述基礎 API，而是聚焦於實戰效能優化：如何

背景動機 在 Nokia 6108 開發個人通訊錄時，發現 RecordStore.getSizeAvailable() 回傳值幾乎等於手機剩餘總記憶體，顯然該

核心介面概覽 在 Record Management System (RMS) 中，RecordFilter 與 RecordEnumeration 是實現條件

前言 在「RMS 從入門到精通」系列第一篇中，我們已奠定 Record Management System (RMS) 的基礎觀念。本文將深入探討在 J2ME

前言：為什麼 RMS 是 J2ME 持久化的唯一選擇？ 功能機時代，文件系統（JSR 75）支援極有限，Record Management System (RM

前言：場景是遊戲的靈魂 在《Death Flight》中，場景不是預製地圖，而是程序化生成、無限捲動、即時碰撞檢測的動態系統。作者擴展 TiledLayer 打

前言：原生 Sprite 好用嗎？「不夠方便」 J2ME javax.microedition.game.Sprite 提供基本幀動畫、位置、可見性，但實戰中缺

前言：RecordStore 直接用太痛苦，封裝才是王道 J2ME RecordStore 僅提供位元組陣列 byte[] 的增刪改查，開發者需自行處理： 物

前言：從零構建遊戲骨架 作者分享《Death Flight》開發過程中「編碼比預想快」的關鍵：學習階段預先搭好框架。本文詳細拆解主 MIDlet 類別 Flig

前言：一人專案同樣需要工程化思維 作者採用瀑布模型進行單人開發，雖規模小但完整經歷了「需求→設計→編碼→測試」流程。本文整理其設計文檔，展示一個商業級 J2ME

前言：經典消除遊戲的 J2ME 移植精髓 「連連看」規則簡單卻極具深度：在 10×10 棋盤上成對消除相同圖案，連線不可超過兩個轉彎且不穿越其他方塊。本文完整拆

前言：為什麼 RPG 是 J2ME 開發的「終極考驗」 角色扮演遊戲（RPG）在功能機時代是手機遊戲的皇冠，也是技術難度最高的類型之一：巨大的地圖、複雜的狀態（

前言：移植難題與 NetBeans 的解決之道 在 J2ME 遊戲開發中，將遊戲移植到不同手機型號向來是開發者的痛點。螢幕解析度、色深、支援的 JSR 擴展包、

遊戲基本結構：時間驅動模型 專業遊戲採用時間驅動，而非事件驅動。無論有無輸入，遊戲持續循環：檢查輸入 → 運行邏輯 → 渲染畫面。核心結構： 初始化遊

遊戲本質：時間驅動的三模塊迴路 遊戲 ≠ 事件驅動 GUI。專業遊戲採用**時間驅動主迴路**，每幀固定順序： 初始化 檢查退出條件 採集輸入

一、尺寸問題：將變數視為變量 1. 螢幕尺寸不一？視為變數！ 不同手機螢幕尺寸各異，渲染時必須以變數 ScreenWidth、ScreenHeight 參與座

一、尺寸變量化：虛擬座標系統 1. 螢幕尺寸為變量 所有渲染座標公式化：x = (screenW - imgW)/2 居中、tilesX = screenW /

DOJA 平台專屬結構 .java 源碼 Scratchpad：類持久化記憶體/虛擬磁盤，多 .scr 文件存放聲音/圖片/數據，**不打入 JAR**，下發

移植本質：五大不可逃避的工程任務 屏幕適配：雙緩衝尺寸、UI 座標、虛擬座標系統全局化。 按鍵映射：Nokia -6/-7 vs Moto -21/-