J2ME 遊戲 Loading 界面設計：雙執行緒協作解決 Heap 內存不足難題

前言

為什麼遊戲需要 Loading 進度條？不是為了好看，而是生存必要。典型 S40 手機 Heap 僅 200KB，幾張 128x128 圖片加聲音、地圖就逼近崩潰邊緣。本文揭示 Loading 界面背後的內存管理邏輯，並給出雙執行緒實現方案。

內存困境：Heap vs 存儲

• Heap (運行時堆)： 極小 (如 200KB)，存放對象實例、解碼後的圖片像素數據、聲音緩衝。
• 存儲 (Flash/RMS)： 較大，存放 JAR 資源、原始圖片數據、地圖文件。
• 核心矛盾： 所有資源一次性載入 Heap → 必然 OOM。必須「用時加載、不用釋放」。

雙執行緒 Loading 架構

// 資源加載執行緒
class LoadingThread implements Runnable {
    private volatile boolean isLoaded = false;
    private int counter = 100; // 模擬進度

    public void run() {
        while (counter > 0) {
            // 真實項目：解碼圖片、載入聲音、解析地圖、初始化對象池
            loadNextResource(); 
            counter--;
            try { Thread.sleep(20); } catch (Exception e) {}
        }
        isLoaded = true;
    }
    public boolean isLoaded() { return isLoaded; }
}

// 主遊戲畫布 (繼承 Canvas/GameCanvas)
class MainCanvas extends Canvas implements Runnable {
    private LoadingThread loader;
    private Thread renderThread;
    private int state = LOADING;
    private int loadingCounter = 0;

    public MainCanvas() {
        loader = new LoadingThread();
        new Thread(loader).start(); // 啟動加載執行緒
        renderThread = new Thread(this);
        renderThread.start(); // 啟動渲染執行緒
    }

    public void run() { // 渲染迴路
        while (true) {
            try { Thread.sleep(100); } catch (Exception e) {}
            if (loader.isLoaded()) {
                loader = null; // 釋放加載器引用
                state = GAMING;
            }
            repaint();
            serviceRepaints();
        }
    }

    protected void paint(Graphics g) {
        g.setColor(0);
        g.fillRect(0, 0, getWidth(), getHeight());
        switch (state) {
            case LOADING:
                g.setColor(0xFFFFFF);
                // 動態進度條動畫
                g.drawString("LOADING" + ">>>>>".substring(0, loadingCounter), 
                    getWidth() >> 1, getHeight() >> 1, Graphics.HCENTER | Graphics.TOP);
                loadingCounter = (loadingCounter + 1) % 5;
                break;
            case GAMING:
                g.setColor(0xFFFFFF);
                g.drawString("GAME", getWidth() >> 1, getHeight() >> 1, Graphics.HCENTER | Graphics.TOP);
                // 正式遊戲渲染邏輯
                break;
        }
    }
}

關鍵設計要點

1. 職責分離： 加載執行緒只管 I/O 與解碼，渲染執行緒只管畫面刷新，互不阻塞。
2. volatile 標誌： isLoaded 保證跨執行緒可見性，無需額外同步開銷。
3. 及時釋放： 進入遊戲狀態後 loader = null，幫助 GC 回收加載期臨時對象。
4. 分批加載： 真實項目中 loadNextResource() 每幀只處理 1-2 個資源，避免單幀耗時過長導致畫面卡頓。
5. 進度反饋： 共享 progress 變量 (0-100)，渲染執行緒讀取繪製進度條。

進階優化：資源池與按需加載

• 對象池： 精靈、粒子、子彈等高頻創建對象預先池化，Loading 階段預熱。
• 場景分級： 主菜單資源常駐，關卡資源進場加載/退場釋放。
• 圖片壓縮： 索引色 PNG、裁剪透明邊、合並圖集 (Texture Atlas) 減少 drawImage 調用。
• 聲音策略： 短音效預載入 Heap，長背景音流式播放 (MMAPI) 不佔 Heap。

總結

Loading 界面是 J2ME 遊戲內存管理的「護城河」。雙執行緒協作 + 分批加載 + 及時釋放 + 資源池，四板斧打穿 200KB Heap 限制，讓大型遊戲在功能機上流暢跑起來。