J2ME 低級界面三種按鍵事件處理機制深度對比

背景

Canvas/GameCanvas 低級界面編程中，按鍵處理是核心邏輯。本文對比三種機制的原理、代碼模式、優缺點與適用場景。

機制一：覆蓋 keyPressed(int keyCode)

1.1 基本模式

protected void keyPressed(int keyCode) {
    // 直接判斷 keyCode
    if (keyCode == Canvas.KEY_NUM4) { ... }
    // 或轉換為遊戲動作
    int action = getGameAction(keyCode);
    switch (action) {
        case Canvas.LEFT: ... break;
        case Canvas.RIGHT: ... break;
    }
}

1.2 關鍵點

• 系統事件線程回調，必須快速返回，不可阻塞
• 功能鍵（軟鍵、導航鍵）keyCode 跨機型差異極大
• 數字鍵 0-9、*、# 的 keyCode 標準化一致
• getGameAction() 將物理鍵映射為邏輯動作（UP/DOWN/LEFT/RIGHT/FIRE/GAME_A-D），屏蔽硬件差異

1.3 缺陷

• 邏輯與渲染耦合在事件線程，長耗時操作導致界面凍結
• 無法處理「長按/持續按住」狀態，僅響應按下瞬間
• 複雜遊戲邏輯（延時、AI、物理）難以在事件回調中實現

機制二：MIDP 2.0 GameCanvas 按鍵狀態

2.1 啟用方式

public MyGameCanvas() {
    super(true); // true = 支援按鍵狀態機制
}

2.2 核心 API

• int getKeyStates()：返回位掩碼，對應位為 1 表示該遊戲鍵當前按下
• 常量：LEFT_PRESSED、RIGHT_PRESSED、UP_PRESSED、DOWN_PRESSED、FIRE_PRESSED、GAME_A_PRESSED...
• 調用後自動清零狀態，確保下一幀獲取最新狀態

2.3 遊戲主循環中使用

public void run() {
    while (running) {
        int states = getKeyStates();
        if ((states & LEFT_PRESSED) != 0) { /* 向左邏輯 */ }
        if ((states & RIGHT_PRESSED) != 0) { /* 向右邏輯 */ }
        // 更新遊戲狀態
        // 渲染幀
        flushGraphics();
        Thread.sleep(frameDelay);
    }
}

2.4 優勢

• 脫離事件線程：邏輯/渲染在獨立線程，可控制幀率、執行耗時計算
• 狀態保持：長按鍵在整個幀週期內持續為真，天然支援連續移動
• 傳統遊戲循環模式：輸入→更新→渲染，架構清晰

2.5 限制

• 僅限 GameCanvas 子類且構造參數 true
• 僅處理遊戲鍵（方向、FIRE、GAME_A-D），功能鍵仍需靠 keyPressed
• 啟用後 keyPressed 不再接收遊戲鍵事件

機制三：鍵盤輪詢

（原文未詳細展開，補充說明）

• 自定義線程循環調用 getKeyStates() 或直接輪詢硬件（部分廠商擴展 API）
• 靈活性最高，但需自行處理去抖、重複觸發等細節
• 非標準 API，移植性差，一般不推薦

對比總結表

選型建議

• 簡單應用/表單/菜單：直接用 keyPressed + getGameAction
• 動作/射擊/競速等實時遊戲：必須用 GameCanvas + getKeyStates 遊戲循環
• 混合場景：遊戲鍵用 getKeyStates，功能鍵（暫停/菜單）用 keyPressed

掌握三種機制的邊界與組合，是 J2ME 遊戲開發者的必修課。