| 編號 | 問題描述 | 影響 | 備註 |
|---|---|---|---|
| 1 | 撞機後爆炸圖片不自動消失，佔據畫面直到場景切換 | 視覺干擾 | 主戰機暫時移除爆炸效果，飛碟保留但不理想 |
| 2 | 敵機 AI 僅實現追蹤，變化單一 | 遊戲深度不足 | 未實現巡邏、圍堵、協同等進階行為 |
| 3 | 子彈/敵機與畫面刷新執行緒不同步，偶發閃爍 | 畫面撕裂 | 雙緩衝未正確應用 |
| 4 | 每幀對所有子彈/敵機雙重迴圈檢測，KVM 運行極慢 | 幀率低 | 未使用空間分割（QuadTree/網格），物件池未應用 |
| 5 | 寶物種類單一（僅加血） | 策略深度缺失 | 可擴展：強化彈藥、護盾、加速等 |
| 6 | 畫面單調，無關卡場景切換 | 視覺疲勞 | 背景圖、音樂、敵機屬性未隨關卡動態載入 |
javax.microedition.lcdui.game 套件提供 Sprite、TiledLayer、LayerManager（雙緩衝自動管理）、GameCanvas（離屏緩衝+鍵盤輪詢）等高階組件。專案後期因時間限制未深度應用，若善用可大幅簡化渲染邏輯、解決閃爍、提升幀率。
手機遊戲屬「高頻實時系統」：每秒數萬行代碼執行（碰撞檢測、AI、渲染、輸入、音頻）。任何微小邏輯漏洞（邊界條件、競態、資源洩漏）經累積必現為 Crash、ANR 或死循環。設計階段必須窮盡所有狀態轉移與異常情況。
每幀需掃描所有物件對之間的碰撞與邊界檢測。若物件數 N，複雜度 O(N²)。優化方向：空間分割、粗略檢測（矩形）先行、物件池複用、減少物件創建/銷毀。
啟動畫面、選單、暫停、結算、排行榜、音效、美術風格一致性——這些「非核心」模組構成商業級產品的用戶留存基礎。Java 半解釋執行特性要求代碼極度精簡優化，混淆器可進一步壓縮體積、提升載入速度。
1989 年任天堂 Game Boy：24KB 二進制、12MHz CPU、8KB RAM、流暢雙人對戰、多音效。現代 J2ME 遊戲常需 200KB+ RAM、200MHz CPU 仍不夠流暢。原生機器碼 vs. 虛擬機解釋 的效能鴻溝，倒逼我們在算法、資料結構、渲染管線上追求極致優化。
