簡(jiǎn)介JAVA ME 經(jīng)典飛行射擊游戲《9688雷霆戰(zhàn)機(jī)》的個(gè)人移植源碼包面向希望從實(shí)戰(zhàn)代碼理解 J2ME/MIDP 移動(dòng)游戲開發(fā)的入門與進(jìn)階學(xué)習(xí)者。內(nèi)容圍繞 MIDlet 主類入口、GameLoop 游戲循環(huán)、飛機(jī)/敵機(jī)/子彈對(duì)象模型、碰撞檢測(cè)與狀態(tài)機(jī)管理展開并涉及 Canvas 繪圖、鍵盤或觸摸事件響應(yīng)、圖像預(yù)加載及音頻播放等環(huán)節(jié)可幫助讀者建立較完整的小型移動(dòng)游戲框架認(rèn)知。壓縮包約 4.4MB文件總數(shù)顯示為 0、類型明細(xì)暫未提供源碼與工具屬性較明確包體以完整工程移植內(nèi)容為主。已有 1139 人學(xué)習(xí)或下載說明其在同類 J2ME 學(xué)習(xí)材料中有一定參考熱度。通過閱讀和調(diào)試這套移植代碼讀者可揣摩幀率控制、內(nèi)存分配與資源緩存等受限設(shè)備上的優(yōu)化思路也能練習(xí)代碼閱讀、問題定位和模塊拆解方法適合作為課程設(shè)計(jì)或個(gè)人練手的對(duì)照樣本。1. 一臺(tái)舊功能機(jī)里的飛行射擊這套 J2ME 雷霆戰(zhàn)機(jī)源碼在跑什么手里那臺(tái) 240×320 的舊按鍵機(jī)還能開機(jī)但能裝進(jìn)去的游戲已經(jīng)不多了。這份個(gè)人移植的 J2ME 雷霆戰(zhàn)機(jī)源碼做的事就是讓一臺(tái) Java ME 功能機(jī)重新跑起完整的豎版飛行射擊——飛機(jī)左右穿梭、子彈成排往外噴、敵機(jī)一波接一波分?jǐn)?shù)寫進(jìn) RMS關(guān)機(jī)再開還在。整套工程不依賴任何第三方游戲引擎全靠 MIDP 自帶的 Canvas、GameAPI、RMS 和 Media API 拼起來用老式的 J2ME 開發(fā)工具包WTK導(dǎo)入就能編出 JAR。它適合三類人手里有舊機(jī)器想復(fù)刻點(diǎn)東西的、想看清 J2ME 游戲主循環(huán)到底怎么寫的、以及接手了一個(gè)老 JAR 要做二次開發(fā)的。代碼量不大但結(jié)構(gòu)完整從 MIDlet 生命周期到子彈對(duì)象池回收都留著清晰的切口改起來不用翻半天。2. 工程骨架與目錄結(jié)構(gòu)MIDlet 入口、Canvas 主循環(huán)和資源怎么擺先看骨架。J2ME 項(xiàng)目和普通 Java 工程最大的差別在于它必須有一個(gè)明確的「應(yīng)用入口」和一份聲明式的描述文件打包器靠這兩樣?xùn)|西才能把一堆 class 變成一個(gè)能裝進(jìn)手機(jī)的 JAR。2.1 一份能直接導(dǎo)入 WTK 的目錄長什么樣這套源碼的目錄是標(biāo)準(zhǔn)的老式 J2ME 布局沒有 Maven 也沒有 Gradle純靠 IDE 的工程描述和 Ant 腳本src/ com/game/midlet/GameMIDlet.java MIDlet 入口管生命周期 com/game/core/GameCanvas.java 主循環(huán)、按鍵、繪制 com/game/core/Entity.java 實(shí)體基類坐標(biāo)/速度/半徑 com/game/core/BulletPool.java 子彈對(duì)象池 com/game/core/EnemyManager.java 敵機(jī)波次調(diào)度 com/game/core/ScoreStore.java RMS 最高分 com/game/core/Res.java 圖片資源統(tǒng)一加載與緩存 res/ player.png enemy.png bullet.png bg.png bgm.mid shoot.wav META-INF/MANIFEST.MF Game.jad build.xmlsrc下面按職責(zé)分了 midlet 和 core 兩個(gè)包這個(gè)分層對(duì) J2ME 來說已經(jīng)夠用了。res里的圖片必須是 PNG這是 MIDP 規(guī)范里唯一被強(qiáng)制支持的位圖格式別指望塞 JPG 進(jìn)去。Game.jad是 Java 應(yīng)用描述文件很多機(jī)型在安裝時(shí)會(huì)先讀 JAD 再?zèng)Q定要不要下載 JAR里面的字段和 MANIFEST 必須對(duì)得上。2.2 MIDlet 生命周期startApp 里只做一件事入口類承擔(dān)的工作比想象中少。J2ME 的 MIDlet 有startApp、pauseApp、destroyApp三個(gè)狀態(tài)回調(diào)最容易踩的坑是把資源加載和線程啟動(dòng)都堆在startApp里結(jié)果用戶按了掛機(jī)鍵再切回來第二份線程就起來了畫面越跑越快。import javax.microedition.midlet.MIDlet; import javax.microedition.midlet.MIDletStateChangeException; import javax.microedition.lcdui.Display; public class GameMIDlet extends MIDlet { private GameCanvas canvas; private Display display; protected void startApp() throws MIDletStateChangeException { if (canvas null) { display Display.getDisplay(this); Res.loadAll(); // 素材只在這里加載一次全部進(jìn)靜態(tài)緩存 canvas new GameCanvas(this); canvas.startLoop(); // 主循環(huán)線程跟著 Canvas 走 } display.setCurrent(canvas); // 切回來只是重新設(shè)為當(dāng)前屏幕 } protected void pauseApp() { if (canvas ! null) canvas.pauseLoop(); // 掛機(jī)就停線程省電 } protected void destroyApp(boolean unconditional) { if (canvas ! null) canvas.stopLoop(); } public void exit() { // 游戲內(nèi)菜單調(diào)用 destroyApp(true); notifyDestroyed(); } }startApp里用canvas null做了一次性判斷這是整套代碼里最值錢的一行。J2ME 設(shè)備在來電、切換后臺(tái)、開蓋合蓋時(shí)都會(huì)反復(fù)觸發(fā)startApp和pauseApp如果不做這個(gè)判斷每次切回來就是一個(gè)新 Canvas 加一個(gè)新線程內(nèi)存和幀率一起崩。pauseLoop只是把running標(biāo)志置 false 并讓線程自然退出循環(huán)不調(diào)Thread.stop()——那個(gè)方法在 CLDC 上行為不確定屬于血淚經(jīng)驗(yàn)。參數(shù)上notifyDestroyed()是告訴運(yùn)行環(huán)境「我自己要退了」必須主動(dòng)調(diào)否則部分機(jī)型會(huì)認(rèn)為應(yīng)用異常退出并彈提示。Res.loadAll()放在 Canvas 創(chuàng)建之前保證第一幀繪制時(shí)所有Image都已經(jīng)就位避免第一幀出現(xiàn)空指針。2.3 JAD 與 MANIFEST 里的關(guān)鍵字段JAR 裝不上手機(jī)八成是這兩個(gè)文件的問題。核心字段就這幾個(gè)MIDlet-Name: ThunderShooter MIDlet-Version: 1.0.0 MIDlet-Vendor: Personal MIDlet-1: Thunder, /player.png, com.game.midlet.GameMIDlet MicroEdition-Configuration: CLDC-1.1 MicroEdition-Profile: MIDP-2.0MIDlet-1的格式是「顯示名, 圖標(biāo)路徑, 入口類全名」三段用英文逗號(hào)加空格分隔少一個(gè)空格某些機(jī)型就解析失敗。MicroEdition-Configuration和MicroEdition-Profile直接決定了這臺(tái)機(jī)器愿不愿意裝你的包寫 CLDC-1.1 意味著放棄 CLDC-1.0 的老機(jī)器寫 CLDC-1.0 則用不了浮點(diǎn)和部分集合 API。這套源碼選了 CLDC-1.1 MIDP-2.0是個(gè)務(wù)實(shí)的取舍——覆蓋不了最早那批單色機(jī)但換來了Image.createRGBImage和Manager這些必備能力。# 老式 WTK 的標(biāo)準(zhǔn)打包流程三步缺一不可 javac -bootclasspath $WTK/lib/cldcapi11.jar:$WTK/lib/midpapi20.jar \ -d classes $(find src -name *.java) $WTK/bin/preverify -classpath $WTK/lib/cldcapi11.jar:$WTK/lib/midpapi20.jar -d classes classes jar cfm ThunderShooter.jar META-INF/MANIFEST.MF -C classes . -C res .preverify這一步是 J2ME 獨(dú)有的它在每個(gè) class 里插入棧映射信息供設(shè)備上的 KVM 做字節(jié)碼校驗(yàn)。跳過它模擬器可能照跑真機(jī)上直接報(bào)校驗(yàn)錯(cuò)誤。構(gòu)建腳本里把它寫成 Ant 的一個(gè)exectarget 就行別手動(dòng)敲命令太長容易漏 classpath。3. 核心玩法拆解從主循環(huán)到子彈與敵機(jī)的碰撞判定骨架搭好之后真正決定手感的是主循環(huán)和實(shí)體管理。這部分代碼不多但每一處都能直接換成「卡不卡」和「判定準(zhǔn)不準(zhǔn)」。3.1 幀循環(huán)里的 update 與 draw 分離J2ME 沒有游戲引擎的requestAnimationFrame最穩(wěn)的做法是自建線程加固定步長。這套代碼把邏輯更新和繪制徹底分開update只改數(shù)據(jù)paint只讀數(shù)據(jù)中間不互相調(diào)用。public class GameCanvas extends Canvas implements Runnable { private static final int FRAME_MS 40; // 25 FPS功能機(jī)的舒適區(qū) private volatile boolean running false; private Thread loopThread; private long lastTick; public void startLoop() { if (running) return; running true; lastTick System.currentTimeMillis(); loopThread new Thread(this); loopThread.start(); } public void pauseLoop() { running false; } public void run() { while (running) { long now System.currentTimeMillis(); int delta (int) (now - lastTick); if (delta FRAME_MS) { try { Thread.sleep(FRAME_MS - delta); } catch (InterruptedException e) { } continue; } lastTick now; update(delta); repaint(); serviceRepaints(); // 立刻刷別讓重繪消息在事件隊(duì)列里排隊(duì) } } }FRAME_MS 40對(duì)應(yīng) 25 幀這是老機(jī)器的甜點(diǎn)值。往 30 幀調(diào)33ms不是不行但繪制一幀如果超時(shí)System.currentTimeMillis()的差值會(huì)越滾越大表現(xiàn)為「走兩步卡一下」。差值累積的處理方式是不補(bǔ)幀直接把lastTick重置到當(dāng)前時(shí)間寧可掉幀也不讓邏輯跳步。volatile修飾running是因?yàn)檫@個(gè)字段跨線程讀寫沒有它暫停指令在部分虛擬機(jī)上不會(huì)被主循環(huán)看到。repaint()加serviceRepaints()連用是 Canvas 的經(jīng)典寫法前者只是把重繪請(qǐng)求丟進(jìn)事件隊(duì)列后者強(qiáng)制同步執(zhí)行到paint完成。少寫后面那一句畫面會(huì)滯后一到兩幀彈幕密集時(shí)感覺特別明顯。3.2 實(shí)體與對(duì)象池別讓內(nèi)存在彈幕里抖射擊游戲最怕的不是算力不夠是 GC 在關(guān)鍵時(shí)刻來一下。一局下來幾千發(fā)子彈如果每發(fā)都new Bullet()CLDC 上那個(gè)小堆幾秒鐘就撐不住。這套代碼的解法是固定容量對(duì)象池一次分配永不擴(kuò)容。public class BulletPool { private final Bullet[] pool; private int liveCount; // [0, liveCount) 是活躍子彈 public BulletPool(int capacity) { pool new Bullet[capacity]; for (int i 0; i capacity; i) { pool[i] new Bullet(); // 啟動(dòng)時(shí)一次性 new 完 } } public void spawn(int x, int y, int vx, int vy, int dmg) { if (liveCount pool.length) return; // 池滿直接丟棄絕不擴(kuò)容 Bullet b pool[liveCount]; b.reset(x, y, vx, vy, dmg); } public void update(int delta) { for (int i liveCount - 1; i 0; i--) { Bullet b pool[i]; b.x b.vx * delta / 1000; b.y b.vy * delta / 1000; if (b.y -16 || b.y 400 || b.dead) { pool[i] pool[--liveCount]; // 尾元素覆蓋O(1) 回收 pool[liveCount] b; } } } }倒序遍歷是這份回收邏輯能成立的前提。pool[i] pool[--liveCount]把最后一個(gè)活躍子彈挪到當(dāng)前位置然后liveCount減一被回收的b則回到數(shù)組尾部等待復(fù)用。因?yàn)槭堑剐虮慌策^來的那個(gè)元素索引一定小于當(dāng)前的i下一輪不會(huì)重復(fù)處理。如果寫成正序挪過來的元素會(huì)被跳過子彈就「穿?！癸w過去不消失。capacity的取值我一般按「最壞情況下屏幕同屏子彈數(shù)」的 1.5 倍來定這套代碼給的是 64。滿池時(shí)丟棄而不是擴(kuò)容這個(gè)設(shè)計(jì)是刻意的——寧可少一發(fā)子彈也不能在戰(zhàn)斗中觸發(fā)一次數(shù)組復(fù)制。敵機(jī)那邊同理EnemyManager里也是固定數(shù)組加波次調(diào)度不用Vector。3.3 碰撞判定圓形距離平方比矩形更貼合彈幕判定用矩形包圍盒是最省事的但豎版射擊游戲里機(jī)身窄、彈幕斜飛矩形框會(huì)在視覺上明明沒碰到的時(shí)候判定命中玩家感受很差。這套代碼用的是圓形判定只比較距離的平方省掉開方。public class Entity { public int x, y; // 左上角坐標(biāo) public int halfW, halfH; // 半寬半高用于繪制 public int cx, cy; // 判定圓心一般略小于視覺中心 public int radius; // 判定半徑 public void syncCenter() { cx x halfW; cy y halfH; } } public class Collision { public static boolean overlap(Entity a, Entity b) { int dx a.cx - b.cx; int dy a.cy - b.cy; int r a.radius b.radius; return dx * dx dy * dy r * r; // 比較平方不做開方 } }radius通常設(shè)成視覺尺寸的 0.6 到 0.7 倍這叫「寬容判定」玩家被擦彈擦過去不算死手感會(huì)好很多。自機(jī)受傷判定要比敵機(jī)更小一圈因?yàn)樽詸C(jī)是玩家唯一在意的對(duì)象判定越寬容越舒服而敵機(jī)被打中的判定可以放大到 1.0讓射擊更有反饋感。syncCenter必須在坐標(biāo)變化后調(diào)用或者干脆把cx/cy算成x halfW的 getter避免忘了同步導(dǎo)致判定錯(cuò)位——這是個(gè)特別隱蔽的 bug畫面上全都對(duì)就是打不中。每幀的檢測(cè)順序是自機(jī)子彈 × 敵機(jī) → 敵機(jī)子彈 × 自機(jī) → 敵機(jī) × 自機(jī)。前兩組是 O(m×n) 的雙層循環(huán)靠數(shù)量控制子彈池 64、敵機(jī)池 24保證在 CLDC 上也不卡。想再省一點(diǎn)可以按屏幕縱向分三段只跟同一段內(nèi)的對(duì)象比實(shí)測(cè)能砍掉約六成計(jì)算量。3.4 敵機(jī)波次與難度曲線波次調(diào)度沒寫成狀態(tài)機(jī)用的是一個(gè)很土但好調(diào)的結(jié)構(gòu)數(shù)據(jù)表加游標(biāo)。// 每一波起始時(shí)刻(ms)、敵機(jī)數(shù)量、生成間隔(ms)、橫向起始位置、移動(dòng)模式 private static final int[][] WAVES { { 0, 5, 800, 40, 0 }, // 模式0直線下落 { 6000, 8, 600, 100, 1 }, // 模式1正弦橫移 {13000, 12, 400, 20, 2 }, // 模式2斜向俯沖 {21000, 16, 300, 60, 3 }, // 模式3追蹤自機(jī) };把難度寫成表的好處是調(diào)平衡的時(shí)候不用改代碼邏輯。想讓它更兇把間隔從 800 調(diào)到 500、數(shù)量加兩架重新編譯就行。游標(biāo)推進(jìn)的邏輯在EnemyManager.update里當(dāng)前波次的生成數(shù)量耗盡且場(chǎng)上敵機(jī)清空后才推下一波中間留一段空窗給玩家喘氣。這個(gè)「清空再推進(jìn)」的條件如果不加波次會(huì)疊在一起第三關(guān)就能直接勸退。4. 屏幕與按鍵適配跨機(jī)型移植最容易翻車的一層同一份 JAR在 128×160 的機(jī)器上正常在 240×320 的機(jī)器上飛出屏幕在 176×208 的機(jī)器上按鍵全亂——這是移植 J2ME 游戲最典型的一天。適配層不做前面寫得再好也白搭。4.1 分辨率適配邏輯坐標(biāo)系加一次性重采樣MIDP 的drawImage不支持縮放這是硬約束。想畫一張能適應(yīng)多種屏幕的圖只有兩條路運(yùn)行時(shí)自己重采樣或者按固定邏輯分辨率畫、四周留黑邊。這套代碼兩條都用了。先看繪制時(shí)的坐標(biāo)系換算private static final int LOGIC_W 240; private static final int LOGIC_H 320; protected void paint(Graphics g) { int sw getWidth(); int sh getHeight(); // 以邏輯分辨率為基準(zhǔn)計(jì)算居中偏移不做非整數(shù)縮放 int ox (sw - LOGIC_W) / 2; int oy (sh - LOGIC_H) / 2; g.setColor(0x000010); g.fillRect(0, 0, sw, sh); // 先鋪滿底色防止邊緣露出臟像素 g.translate(ox, oy); // 之后所有繪制都用邏輯坐標(biāo) g.setClip(0, 0, LOGIC_W, LOGIC_H); // 裁剪掉超出的部分別畫到屏幕外 drawBg(g); enemies.draw(g); bullets.draw(g); player.draw(g); drawHud(g); g.translate(-ox, -oy); // 還原給后續(xù)可能的全屏繪制讓路 }g.translate加setClip這個(gè)組合是整段的核心。邏輯坐標(biāo)統(tǒng)一按 240×320 算屏幕比它大的時(shí)候居中兩邊鋪深色底比它小的時(shí)候裁剪掉邊緣保證玩家不會(huì)被看不見的敵機(jī)打死。translate必須成對(duì)還原否則 HUD 和后續(xù)的全屏效果會(huì)畫到偏移位置上去這個(gè) bug 排查起來特別費(fèi)勁因?yàn)檫壿媽拥臄?shù)據(jù)全是對(duì)的。屏幕比邏輯分辨率大的時(shí)候如果就這么留黑邊會(huì)很丑。更徹底的做法是啟動(dòng)時(shí)把整套素材按比例重采樣一次// 啟動(dòng)時(shí)按目標(biāo)尺寸把素材重采樣一遍運(yùn)行時(shí)零開銷 public static Image scaleImage(Image src, int dstW, int dstH) { int sw src.getWidth(); int sh src.getHeight(); int[] srcPx new int[sw * sh]; src.getRGB(srcPx, 0, sw, 0, 0, sw, sh); // 需要 MIDP 2.0 int[] dstPx new int[dstW * dstH]; for (int y 0; y dstH; y) { int sy y * sh / dstH; for (int x 0; x dstW; x) { dstPx[y * dstW x] srcPx[sy * sw x * sw / dstW]; // 最近鄰插值 } } return Image.createRGBImage(dstPx, dstW, dstH, true); }最近鄰插值出來的圖會(huì)有鋸齒但 J2ME 上沒得選——雙線性要浮點(diǎn)運(yùn)算CLDC 1.0 直接不支持。createRGBImage的第四個(gè)參數(shù)processAlpha傳true才會(huì)保留透明通道傳false會(huì)得到一張黑底圖這個(gè)參數(shù)值錢。重采樣只發(fā)生在啟動(dòng)時(shí)算力代價(jià)可以接受千萬別放進(jìn)paint里一幀幾次重采樣能讓幀率掉到個(gè)位數(shù)。4.2 按鍵映射getGameAction 的返回值不一定靠得住Canvas.getGameAction(keyCode)理論上把物理鍵翻譯成UP/DOWN/LEFT/RIGHT/FIRE這些抽象動(dòng)作實(shí)際上部分機(jī)型對(duì)方向鍵返回 0還有一批機(jī)器把方向鍵直接映射成數(shù)字鍵 2/4/6/8。只寫 switch 不寫兜底用戶會(huì)發(fā)現(xiàn)飛機(jī)紋絲不動(dòng)。protected void keyPressed(int keyCode) { int action getGameAction(keyCode); switch (action) { case Canvas.UP: player.moveUp(); break; case Canvas.DOWN: player.moveDown(); break; case Canvas.LEFT: player.moveLeft(); break; case Canvas.RIGHT: player.moveRight(); break; case Canvas.FIRE: player.fire(); break; default: // 兜底部分機(jī)型方向鍵不映射游戲動(dòng)作只報(bào)數(shù)字鍵 if (keyCode Canvas.KEY_NUM2) player.moveUp(); else if (keyCode Canvas.KEY_NUM8) player.moveDown(); else if (keyCode Canvas.KEY_NUM4) player.moveLeft(); else if (keyCode Canvas.KEY_NUM6) player.moveRight(); else if (keyCode Canvas.KEY_NUM5) player.fire(); break; } }這套兜底覆蓋了絕大多數(shù)功能機(jī)的鍵位習(xí)慣。還有個(gè)更細(xì)的問題某些機(jī)器的左軟鍵對(duì)應(yīng)-6、右軟鍵對(duì)應(yīng)-7取值是負(fù)數(shù)用getGameAction同樣返回 0需要單獨(dú)判斷。別指望一次寫完全部機(jī)型最實(shí)際的做法是在游戲里塞一個(gè)隱藏的「按鍵調(diào)試」界面把keyCode和getGameAction的返回值直接打在屏幕上裝機(jī)實(shí)測(cè)時(shí)看一眼就知道該補(bǔ)哪一行。4.3 觸屏與鍵盤雙支持MIDP 2.0 之后不少機(jī)器有了觸摸屏。這套代碼同時(shí)實(shí)現(xiàn)了pointerPressed但它不直接和鍵盤邏輯混在一起而是把觸摸坐標(biāo)換算成邏輯坐標(biāo)后交給同一套移動(dòng)接口protected void pointerPressed(int px, int py) { int lx px - offsetX; // 屏幕坐標(biāo) - 邏輯坐標(biāo) int ly py - offsetY; if (isInsideFireButton(lx, ly)) { player.fire(); } else { player.moveTo(lx, ly - 20); // 手指上方留 20 像素別被手指擋住 } }py - 20這個(gè)偏移量是上手之后改的手指落點(diǎn)和玩家以為的位置有偏差直接moveTo會(huì)讓飛機(jī)貼著手指下沿。操作方式上鍵盤機(jī)是「按住方向鍵持續(xù)移動(dòng)」觸屏是「拖哪走哪」兩套邏輯共用player.moveTo和player.moveBy兩個(gè)方法互不干擾。5. 避坑與排查真機(jī)上那五個(gè)最想砸手機(jī)的瞬間模擬器跑通只是開始真機(jī)才是驗(yàn)收?qǐng)?。以下五條都是這套源碼在移植過程中實(shí)際遇到過的問題按「現(xiàn)象、原因、解決」的順序?qū)懹龅酵钪苯映?.1 白屏與花屏圖片和屏幕尺寸的坑現(xiàn)象一模擬器正常裝到真機(jī)啟動(dòng)后一片白幾秒后自動(dòng)退出。原因基本鎖定在圖片資源上——導(dǎo)出的 PNG 帶了 32 位 alpha 通道或者用了真機(jī)解碼器不認(rèn)的非索引色格式。CLDC 上的 PNG 解碼器實(shí)現(xiàn)差異很大越老的機(jī)器越挑。解決辦法是把所有素材重新導(dǎo)出成 8 位索引色 PNG透明部分用純色鍵比如 0xFF00FF填充繪制時(shí)用drawRegion配合色鍵摳掉同時(shí)把單張圖控制在 128×128 以內(nèi)部分機(jī)型對(duì)單圖尺寸有硬上限?，F(xiàn)象二畫面能出來但整體偏到一邊右邊一條黑。這是getWidth()返回的寬度和實(shí)際可視寬度不一致導(dǎo)致的某些滑蓋機(jī)在合蓋狀態(tài)下報(bào)的是內(nèi)屏寬度。解決方式是在sizeChanged(int w, int h)回調(diào)里重新計(jì)算偏移量而不是在構(gòu)造函數(shù)里算一次就存成常量。這個(gè)回調(diào)在屏幕旋轉(zhuǎn)和開合蓋時(shí)都會(huì)觸發(fā)是唯一可靠的時(shí)機(jī)。5.2 崩潰與內(nèi)存CLDC 的 API 紅線現(xiàn)象三玩到第三關(guān)黑屏退出日志里是OutOfMemoryError。兩個(gè)來源一是每幀new實(shí)體二是同一張圖被反復(fù)Image.createImage加載。前者的解法是第 3 章講的對(duì)象池后者更隱蔽EnemyManager里每種敵機(jī)如果各自加載一次貼圖同屏五架就是五份位圖在堆里。正確做法是建立Res類在startApp里把所有Image一次性 load 進(jìn)靜態(tài)字段之后全局共用同一份引用?，F(xiàn)象四編譯通過真機(jī)一運(yùn)行就NoSuchMethodError。說明用了 CLDC 1.0 里沒有的 API但編譯時(shí)的 classpath 指向了 CLDC 1.1 的庫。常見嫌疑人是Float.valueOf、String.format、java.util.regex和Collections.sort的部分重載。查法很簡(jiǎn)單把工程配置里的 Configuration 改成 CLDC-1.0 再完整編譯一次編譯不過的地方就是雷區(qū)。真要用浮點(diǎn)就自己用整數(shù)放大一百倍來模擬別賭目標(biāo)機(jī)型支持。5.3 交互與存檔按鍵、RMS、音效三連坑現(xiàn)象五方向鍵完全沒反應(yīng)但確認(rèn)鍵能開火。就是 4.2 節(jié)講的getGameAction返回 0加上數(shù)字鍵兜底即可。順帶一提有些機(jī)器在keyPressed里收到的是重復(fù)事件按住方向鍵會(huì)以極快頻率觸發(fā)導(dǎo)致飛機(jī)瞬移到邊界——加一個(gè)keyReleased里清標(biāo)志、keyPressed里判重的簡(jiǎn)單鎖就能壓住?，F(xiàn)象六最高分重啟后歸零。RecordStore寫完沒關(guān)是頭號(hào)原因部分機(jī)型的數(shù)據(jù)要等closeRecordStore()才落盤代碼里必須在finally里關(guān)。第二個(gè)原因是 RMS 的作用域跟 MIDlet 套件綁定改了MIDlet-Name或者換了簽名之前存的數(shù)據(jù)就等于沒了——所以名字這東西定了就別動(dòng)。穩(wěn)妥的寫法是加載失敗一律返回 0存檔失敗直接吞掉異常絕對(duì)不能讓存檔問題把整個(gè)游戲拖崩。音效是同類問題里的第三顆雷。Manager.createPlayer在缺少 MMAPI 支持的機(jī)器上會(huì)拋異常甚至直接NoClassDefFoundError。整個(gè)播放邏輯必須包在 try-catch 里并且先用Manager.isTypeSupported(audio/midi)探一下不支持就靜音降級(jí)游戲照跑。6. 二次開發(fā)改造換一套美術(shù)、加一種武器之后怎么驗(yàn)證改造這套源碼最省力的順序是「先換皮、再改數(shù)值、最后加機(jī)制」因?yàn)槿叩尿?yàn)證成本是遞增的。換皮只需要看不崩加機(jī)制要玩得爽中間隔著幾十次真機(jī)重啟。6.1 換皮改動(dòng)面其實(shí)只有三處美術(shù)替換不要?jiǎng)哟a邏輯只碰三個(gè)地方res目錄下的 PNG 文件、Res.java里的尺寸常量、Entity子類里的halfW/halfH/radius。自機(jī)的機(jī)身窄radius給 6 到 8 就夠敵機(jī)體積大可以給到 14。改完一定要把BulletPool的容量重新算一遍——新美術(shù)如果讓子彈變大同屏能容納的數(shù)量就變了池子還是 64 的話會(huì)在密集彈幕時(shí)開始丟子彈表現(xiàn)為「明明在射但打不中」。6.2 加一種武器從對(duì)象池容量到渲染順序加激光武器的最小改動(dòng)路徑是這樣的在BulletPool外面再開一個(gè)LaserPool容量小一點(diǎn)8 條足夠因?yàn)樗鼈兣卸ù?、存在時(shí)間長。渲染順序上激光要畫在普通子彈下面、背景上面否則會(huì)蓋住自機(jī)。數(shù)值上激光給「持續(xù)傷害」而不是「單次傷害」就需要在Entity上加一個(gè)dmgPerTick字段配合update(delta)按毫秒累加避免高幀率時(shí)傷害翻倍。做完這一步別忘了難度曲線也得跟著調(diào)——加了強(qiáng)力武器第四波的敵機(jī)數(shù)量不漲游戲就變成割草了。6.3 真機(jī)驗(yàn)證清單改完別急著打包按這張表過一遍能省掉大量返工驗(yàn)證項(xiàng)怎么驗(yàn)不通過先看哪里冷啟動(dòng)裝完直接開不看任何界面Res.loadAll是否在 Canvas 之前掛機(jī)切回按掛機(jī)鍵 30 秒再切回startApp的canvas null判斷滿屏彈幕打到第三波觀察是否掉幀BulletPool容量與FRAME_MS判定手感貼臉躲彈看是否被誤判radius取值與syncCenter調(diào)用存檔打出最高分退出重進(jìn)closeRecordStore是否在 finally靜音降級(jí)在不支持 MIDI 的機(jī)器上跑音效 try-catch 是否完整這套流程我從第二個(gè)移植項(xiàng)目開始就沒斷過。早期吃過虧模擬器上一切正常真機(jī)裝上去第一波敵人還沒出完就白屏了回頭查了整整兩天才發(fā)現(xiàn)是某張圖的 alpha 通道問題。從那以后我每次改完一個(gè)副本都強(qiáng)制在真機(jī)上把所有波次跑滿一輪再打包不管改的是一行數(shù)值還是一次換膚。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取