基礎知識疏忽導致的 J2ME Tab 異常顯示 Bug 根因與修復

現場還原

應用頂部多 Tab 橫向切換，各 Tab 數據源不同：有的讀 RMS 本地，有的請求服務端。切換 Tab 時偶現「異常提示語錯位」——上一個 Tab 的錯誤訊息殘留顯示在下一個正常 Tab 界面。

問題代碼（原版）

try {
    // 網絡請求 / RMS 讀取 / UI 渲染
} catch (XXXException e) {
    // 直接在螢幕彈出提示
    showAlert(e.getMessage());
}

根因分析

1. 異步執行與 UI 線程競態：網絡請求在工作線程，RMS 讀取可能在事件線程；異常捕獲後直接操作 UI，無同步機制。
2. 無上下文標識：catch 塊不知「當前可見 Tab 是誰」，導致異常來自 Tab A 卻在 Tab B 顯示時彈出。
3. 資源釋放不及時：內存緊張時舊線程/請求未正確取消，殘留回調執行。

修復方案：攜帶 Tab 標識的守衛判斷

// 為每個 Tab 分配唯一 ID
private static final int TAB_HOME = 0, TAB_NEWS = 1, TAB_SETTING = 2;
private int currentTabId = TAB_HOME; // 切換時同步更新

// 異步任務內部
try {
    // 業務邏輯
} catch (XXXException e) {
    // 關鍵：只有異常來源 Tab 仍為當前可見 Tab 才提示
    if (this.tabId == currentTabId) {
        showAlert(e.getMessage());
    }
    // 否則靜默丟棄或記錄日誌
}

進階最佳實踐

• 取消令牌模式：切換 Tab 時設置 cancelled = true，任務內部定期檢查並提前返回。
• 統一異常處理器：封裝 SafeTask<T> 抽象類，內建 tabId、cancelled、onError() 模板方法，業務只需實現 doInBackground()。
• UI 狀態機：Tab 切換觸發 onPause() / onResume()，自動取消進行中請求、清理臨時 UI。
• 內存壓力下的優雅降級：捕獲 OutOfMemoryError，釋放圖片緩存、提示「內存不足，請重啟」而非 Crash。

總結

「基礎知識」非指語法，而是併發模型、生命周期、上下文隔離等工程基本功。多線程 UI 編程中，**每個異步回調都必須驗證「當前上下文是否仍有效」** 是鐵律。補上這一行 if (tabId == currentTabId)，Bug 即刻消失，系統健壯度大幅提升。