簡介這套Java Swing植物大戰(zhàn)僵尸項目附帶完整代碼注釋和說明文檔適合正在學(xué)習(xí)Java SE、希望深入理解Swing桌面游戲開發(fā)的初學(xué)者及進(jìn)階者。項目通過JFrame、JPanel、Graphics2D等核心組件完整呈現(xiàn)事件監(jiān)聽、多線程動畫、界面繪制以及MVC設(shè)計模式在真實游戲中的落地方式注釋逐行解釋關(guān)鍵邏輯能幫助讀者快速理清游戲循環(huán)、碰撞檢測與資源加載的協(xié)作關(guān)系。壓縮包共155個文件包含20個java源碼、39個class編譯文件以及大量png、gif、jpg圖片素材和2個wav音效另附docx文檔說明整體設(shè)計與模塊功能整體包體約19.15MB。目前已有438人學(xué)習(xí)內(nèi)容覆蓋從主窗口搭建到圖形繪制、音效播放等完整流程既可作為課程設(shè)計參考也適合按注釋逐步拆解模仿是學(xué)習(xí)Java Swing游戲開發(fā)的實用資料。1. Swing 寫植物大戰(zhàn)僵尸不是玩具是 Java 面向?qū)ο蟮淖罴丫毷猪椖亢芏?Java 從業(yè)者把 Swing 當(dāng)成寫管理系統(tǒng)的代名詞一提起 Swing 做游戲就下意識覺得性能不行、效果太丑。但實際上用 Swing 手寫一個帶全注釋的《植物大戰(zhàn)僵尸》復(fù)刻版正好能把 Java 面向?qū)ο?、容器線程、事件分發(fā)模型和定時任務(wù)這些最常見的八股考點一次性全部落到真實代碼里。這個項目不像 Spring Boot 那邊復(fù)雜也不像算法題那樣抽象它能讓你看到一個 JLabel 怎么變成一顆會攻擊的豌豆一個 ArrayList 里成千上萬顆子彈如何優(yōu)雅地消失。這篇文章不打算講那些虛頭巴腦的游戲引擎設(shè)計而是直接圍繞一份帶全注釋和文檔的 Swing 項目源碼把它拆成可復(fù)現(xiàn)的落地路徑從類架構(gòu)、Timer 主循環(huán)到碰撞檢測和存檔序列化。無論你是剛學(xué)完 Java 基礎(chǔ)想做點像樣的東西包裝簡歷還是在學(xué) Swing 布局和事件監(jiān)聽的在校生只要照著本文的步驟完全可以在本地跑通一個邏輯完整、注釋豐富、能拿得出手講清楚的植物大戰(zhàn)僵尸工程。2. 架構(gòu)先行從 class 注釋到 JPanel 網(wǎng)格為什么這種設(shè)計最適合新手2.1 注釋不是寫作文Javadoc 注釋規(guī)范與文檔生成全注釋和文檔解釋是這個項目的核心賣點。很多開源項目源碼讀了像天書原因就是注釋寫了等于沒寫。一個好的類注釋應(yīng)該包含這個類是什么、解決什么問題、和誰協(xié)作、怎么實例化、以及限制條件。比如一個豌豆射手類優(yōu)質(zhì)注釋是這樣寫的/** * 豌豆射手Peashooter。 * * p職責(zé)每隔 1.4 秒發(fā)射一顆豌豆子彈攻擊正前方第一個僵尸。 * 豌豆射手自身不檢測僵尸只負(fù)責(zé)發(fā)射子彈碰撞邏輯統(tǒng)一交給 GamePanel。 * * p使用場景玩家在草坪上放置植物時通過 PlantFactory 創(chuàng)建實例。 * 該實例會被加入 {namelink GamePanel#plants} 列表并在 EDT 線程中 * 被主循環(huán)每幀調(diào)用 {namelink #onFrame()} 進(jìn)行邏輯推進(jìn)。/p * * p注意豌豆子彈的初始坐標(biāo)由植物 X 坐標(biāo)決定不能跨行攻擊。/p * * author YourName * version 1.0 * see Zombie * see GamePanel */ public class Peashooter extends Plant { // ... }寫注釋最容易犯的毛病是解釋代碼本身比如i; // i 加一這種注釋刪了反而更清爽。注釋應(yīng)該寫為什么和邊界條件。我剛帶實習(xí)生時就立過規(guī)矩每個人提交代碼前必須把類注釋補(bǔ)齊否則不做 Code Review。文檔解釋怎么生成不需要額外工具。JDK 自帶的 javadoc 命令就能把這些帶 Javadoc 標(biāo)記的注釋提取成一套 HTML 文檔像官方 API 一樣可以點著看。命令如下javadoc -d docs -encoding UTF-8 -charset UTF-8 -windowtitle 植物大戰(zhàn)僵尸項目API src/main/java/**/*.java執(zhí)行完會在 docs 目錄下生成 index.html。這里有個小坑如果類注釋里用了{(lán)link}引用了不存在的類javadoc 會報錯或者標(biāo)紅所以寫完注釋后建議跑一次這條命令權(quán)當(dāng)注釋檢查器。文檔解釋到位了看代碼的人就不用一行行反推你當(dāng)時怎么設(shè)計的。2.2 從 JPanel 到網(wǎng)格拋棄 GridLayout用 null 布局手動鋪草坪《植物大戰(zhàn)僵尸》的核心是 5 行 9 列的戰(zhàn)場草坪。很多人第一反應(yīng)是用GridLayout(5, 9)但在實際實施中你會發(fā)現(xiàn) Swing 的 GridLayout 并不會幫你把背景圖、卡片欄、割草機(jī)這些額外控件排得整齊。它只知道平均分配沒法做出左邊是卡片欄右下角是鏟子這種復(fù)雜界面。常見做法是對主窗口JFrame使用BorderLayout。北邊放一個JPanel作為卡片選擇欄中央放一個GamePanel自繪面板。而GamePanel內(nèi)部為了像素級精確控制每一個植物、僵尸的位置直接setLayout(null)用絕對坐標(biāo)。GamePanel panel new GamePanel(); panel.setLayout(null); // 關(guān)閉布局管理器所有控件手動 setBounds // 設(shè)置背景草地與網(wǎng)格原點左上角坐標(biāo) panel.setBounds(0, 0, 900, 600); // 在地圖網(wǎng)格 (row0, col2) 放置一個豌豆射手 JLabel JLabel plantLabel new JLabel(); plantLabel.setBounds(200 30, 50 80, 60, 70); plantLabel.setIcon(plantImage); panel.add(plantLabel);這段代碼是復(fù)刻項目里最核心的視覺落地邏輯。絕對定位雖然看起來硬編碼但對于固定分辨率的小游戲來說反而比布局管理器更可控。你會發(fā)現(xiàn)它不參與窗口拉伸所以你最好把窗口大小setResizable(false)鎖死。如果想讓它在不同分辨率下縮放你得在繪制時手動乘以縮放系數(shù)那屬于中期優(yōu)化。2.3 主循環(huán)與定時任務(wù)java.swing.Timer 是唯一正統(tǒng)解游戲的心臟是每幀去做兩件事更新邏輯、重繪畫布。這個循環(huán)在 Swing 里必須用javax.swing.Timer而不是java.util.Timer。因為java.util.Timer的回調(diào)運行在獨立線程它不能直接操作 UI 組件必須手動SwingUtilities.invokeLater切回事件分發(fā)線程EDT稍微沒處理好就翻車。javax.swing.Timer天生就在 EDT 上執(zhí)行回調(diào)不需要考慮線程切換做簡單游戲完全夠用。怎么讓植物攻擊節(jié)奏、僵尸移動速度和子彈飛行速度互不干擾答案是全局一個Timer驅(qū)動 30 FPS然后每個對象體記錄自己的累計時間。// 全局主循環(huán)約 33ms tick 一次30FPS Timer gameLoop new Timer(33, e - { GamePanel panel (GamePanel) this.getComponent(0); // 1. 更新植物邏輯判斷是否需要發(fā)射子彈 for (Plant p : panel.plants) { p.onFrame(); // 植物內(nèi)部自己數(shù)幀夠了就 produceBullet() } // 2. 更新僵尸邏輯移動與攻擊 panel.updateZombies(); // 3. 更新子彈邏輯子彈飛檢測命中 panel.updateBullets(); // 4. 統(tǒng)一觸發(fā) Swing 重繪 panel.repaint(); }); gameLoop.start();javax.swing.Timer的一個特點是倒計時精度受 EDT 阻塞影響。如果某個回調(diào)里做了耗時超過 33ms 的操作比如ImageIO.read(new File(大圖.jpg))你的游戲就會肉眼可見地卡頓一下。所以按 FPS 跑起來后最關(guān)鍵的一條軍規(guī)是IO 操作絕對不能進(jìn)主循環(huán)。圖片在啟動時一次性全部讀進(jìn)HashMap緩存運行時只做內(nèi)存替換與位置計算。這里也順帶解決了java定時任務(wù)框架相關(guān)的困惑游戲項目里的定時任務(wù)不是用來做秒殺下單那種延遲隊列的它就是個基礎(chǔ)的刷新鉤子。核心邏輯把控好Timer這個引子所有周期性動作都能由它派生。3. 把植物與僵尸映射為 Java 對象繼承、多態(tài)與狀態(tài)機(jī)3.1 植物類族譜抽象類 Plant 與三個必寫的抽象方法你把游戲里所有植物列一遍向日葵、豌豆射手、堅果墻、櫻桃炸彈……它們既有共性有血量、有價格、有冷卻時間、會播放動畫又有完全不同的行為。這種一堆東西長得像但動作完全不同的場景越早提取抽象類越好可以省下一堆 if-else 黑匣子。我一般這樣設(shè)計Plant抽象類public abstract class Plant { protected int gridRow; protected int gridCol; protected int hp; protected int sunCost; // 陽光費用 protected int coolingFrames; // 種植后的冷卻幀數(shù)剩余 protected int attackInterval; // 攻擊間隔幀數(shù) 毫秒 / 33ms protected int currentFrame; // 當(dāng)前累計幀 /** * 每幀被 GamePanel 調(diào)用用于執(zhí)行植物行為。 * 子類必須實現(xiàn)具體效果例如豌豆射手在此發(fā)射子彈。 */ public abstract void onFrame(Scene scene); /** * 被子彈或僵尸攻擊時扣血 * 返回 true 表示本植物已死亡需從場景中移除。 */ public abstract boolean onDamaged(int damage); /** * 植物被“鏟子”移除時釋放資源如停止內(nèi)部動畫。 */ public abstract void onDestroy(); }子類Peashooter只需要把攻擊間隔設(shè)成42幀1428ms 約等于原版的 1.4 秒在onFrame里累計幀數(shù)到點就調(diào)scene.addBullet(new Bullet(...))即可。向日葵類似只是把子彈換成陽光。堅果墻甚至可以直接onFrame里什么都不做把邏輯填在onDamaged里。這個方案的直接好處是你要加一個新植物比如寒冰射手只需要新建一個類繼承Plant重寫這三個方法并在PlantFactory一個簡單的 switch-case 工廠里注冊一下。游戲主邏輯完全不用改。這比在GamePanel里寫一大堆if (plantType 0)要優(yōu)雅得多也是面試官最愛聽的面向?qū)ο笤O(shè)計。3.2 僵尸類族譜移動、咬合與受擊狀態(tài)機(jī)僵尸和植物的方向相反它是從屏幕右側(cè)向左移動的。這里的核心考點是狀態(tài)機(jī)僵尸不能永遠(yuǎn)只會走它碰到堅果墻時必須停下來張嘴咬血量低于 50% 時要不要掉頭原版不掉頭。每個僵尸至少需要三個狀態(tài)WALKING、EATING、DEAD?？梢杂妹杜e或者整數(shù)常量去標(biāo)識然后在onFrame里 switch 判斷public enum ZombieState { WALKING, // 向左走 EATING, // 正在啃植物不移動 DYING, // 播放死亡動畫不移動不再被碰撞 REMOVED // 已移除出列表 } public class NormalZombie extends Zombie { private ZombieState state ZombieState.WALKING; Override public void onFrame(Scene scene) { // 先移動再檢測碰撞——保證「碰撞邊界」屬實 if (state ZombieState.WALKING) { this.x - speedPerFrame; // speedPerFrame 約 0.3 像素/幀10像素/秒 // 檢測目標(biāo)植物是否在正前方 Plant target scene.getPlantAt(this.gridRow, this.x); if (target ! null) { this.state ZombieState.EATING; } } else if (state ZombieState.EATING) { // 啃咬間隔每 0.5 秒造成 100 傷害 if (gameFrame % 15 0) { target.onDamaged(100); } } } }這里有用地上的實際參數(shù)原版“普通僵尸”移動速度大約是 4.7 秒走完一格約 80 像素折合每幀 17 像素不對我剛說的 0.3 像素是對的。你可以調(diào)節(jié)這個速度來改變游戲難度。全注釋的項目里每個魔法數(shù)字旁邊都得寫清楚這是幾秒的移動速度換算否則后人根本不敢動參數(shù)這就是注釋真正的價值所在。3.3 子彈碰撞檢測用 CopyOnWriteArrayList 還是迭代器刪除碰撞檢測如果寫成兩兩遍歷也就是ListBullet * ListZombie只要同屏超過 50 個單位每幀 2500 次計算Swing 雖然不至于崩但也會掉幀。更聰明的做法是按行來分組邏輯。我的做法是構(gòu)造一個HashMapInteger, ListZombiekey 是行號0-4value 是那一行存活的僵尸列表。子彈發(fā)射時帶一個屬性targetRow也是 0-4。碰撞檢測時只需要拿子彈和它對應(yīng)行的僵尸進(jìn)行矩形相交判斷這樣立刻省掉 80% 的無效計算。代碼實現(xiàn)如下這段代碼同時是最容易踩坑的地方IteratorBullet it bullets.iterator(); while (it.hasNext()) { Bullet b it.next(); if (b.isOutOfBound()) { it.remove(); // 邊界外子彈直接移除并發(fā)安全由單線程 EDT 保證 continue; } ListZombie rowZombies zombieByRow.get(b.getTargetRow()); for (Zombie z : rowZombies) { // 矩形碰撞子彈左邊 僵尸右邊且子彈 X 軸重合 if (b.x BULLET_WIDTH z.x b.x z.x ZOMBIE_WIDTH) { z.onDamaged(b.attack); it.remove(); // 命中后穿透停止 break; } // 如果子彈的 X 已經(jīng)比僵尸還大說明穿過去了本行后續(xù)僵尸也不看了。 } }這段代碼的底層坑是如果rowZombies是普通的ArrayList你在遍歷第二個循環(huán)時執(zhí)行remove會拋ConcurrentModificationException。所以這里要么外層僵尸集合用CopyOnWriteArrayList以空間換時間要么在僵尸刪除時只打標(biāo)記state REMOVED等整輪遍歷結(jié)束后再統(tǒng)一清除尸體。4. 避坑與排查Swing 復(fù)刻項目的 5 個高頻常見問題4.1 雷區(qū) 1EDT 阻塞導(dǎo)致界面卡死、UI 無響應(yīng)現(xiàn)象游戲運行 1 分鐘或玩到某關(guān)后整個窗口變成未響應(yīng)白屏鼠標(biāo)點哪都沒用。原因絕大多數(shù)情況是在Timer回調(diào)里用了Thread.sleep()模擬某個延遲或者在游戲邏輯里同步加載了本地文件。EDT 被 sleep 阻塞后它沒法處理鼠標(biāo)事件和重繪事件。解決移除所有Thread.sleep()。需要延遲生效的邏輯改用幀計數(shù)器比如設(shè)置plant.coolingFrames 50每幀在onFrame里執(zhí)行if (coolingFrames 0) coolingFrames--;當(dāng)它等于 0 時才允許種植。IO 讀取全部拿到構(gòu)造函數(shù)或啟動場景里預(yù)加載。4.2 雷區(qū) 2遍歷 ArrayList 時刪除元素ConcurrentModificationException現(xiàn)象子彈擊中僵尸那一瞬間控制臺爆出java.util.ConcurrentModificationException然后動物停止刷新。原因使用for (Bullet b : bullets)增強(qiáng) for 循環(huán)時循環(huán)體內(nèi)部直接調(diào)用bullets.remove(b)。迭代器已經(jīng)檢測到結(jié)構(gòu)修改直接拋異常。解決統(tǒng)一使用Iterator的remove()方法或者先遍歷收集toRemove列表循環(huán)結(jié)束后再執(zhí)行removeAll(toRemove)。前者更直接后者適合需要先判完再批量刪的場景。記住一個原則循環(huán)刪除只用迭代器。4.3 雷區(qū) 3Jar 包雙擊無法運行圖片不顯示路徑與編碼現(xiàn)象在 IDEA 里運行好好的導(dǎo)出Runnable JAR后背景圖變成空白日志報FileNotFoundException。原因用了new File(src/main/resources/images/...)這種相對路徑。IDEA 工作時根目錄是項目根而 jar 在/target目錄運行時這個相對路徑不存在了。解決只能用類路徑資源讀取不能當(dāng)成文件。同時注意不要用中文做文件名避免跨平臺打包時的亂碼編碼問題。// 正確姿勢從 classpath 讀取資源 InputStream imgStream Peashooter.class.getResourceAsStream(/images/peashooter.png); BufferedImage img ImageIO.read(imgStream); ImageIcon icon new ImageIcon(img);4.4 雷區(qū) 4高 DPI 屏幕下游戲窗口大而模糊文字發(fā)虛現(xiàn)象自己的 1080p 屏幕下很清楚拿到 2K/4K 高分屏上窗口小得像螞蟻強(qiáng)行拉伸后所有植物邊緣發(fā)虛。原因高分屏可能存在縮放比例而 Java 的AWTUtilities沒有開 HiDPI。直接設(shè)置絕對坐標(biāo)會因為系統(tǒng)縮放而變得像素顆粒感很明顯。解決跟布局無關(guān)要設(shè)置System.setProperty(sun.java2d.uiScale.enabled, false)或者setUndecorated的擴(kuò)展視口。但更穩(wěn)的是在main方法第一行強(qiáng)制關(guān)閉 HiDPI 縮放會造成高分屏也模糊。實際經(jīng)驗是讓畫面自適應(yīng)更難不如用可縮放矢量SVG或者直接鎖死 1280x720 并用JFrame縮放全屏適配。4.5 雷區(qū) 5全注釋項目卻沒人維護(hù)的深層原因——注釋與代碼腐敗不同步現(xiàn)象注釋里寫著每 1.4 秒發(fā)射一顆子彈但代碼里的攻擊間隔常量被某次平衡性調(diào)整改成了 0.9 秒或者把MILLISECONDS 1400改成了140。注釋變得不可信后人只能逐行反查最后選擇刪掉注釋。原因注釋設(shè)計里沒有唯一來源原則。常量除了在注釋里說明還要在代碼中直接引用比如private static final int SHOOT_DELAY_MS 1400;然后在onFrame里計算幀數(shù)時用它做除法。解決把魔法數(shù)字全部命名成不可變常量。只有類注釋負(fù)責(zé)描述行為方法注釋負(fù)責(zé)描述邊界條件不做任何數(shù)值復(fù)讀。這才符合全注釋項目該有的樣子。5. 驗證與壓榨讓 Swing 游戲更絲滑的 3 個細(xì)節(jié)技巧做完以上核心功能后項目能跑但這還不夠。全注釋的源碼只是讓你讀得懂真正決定你愿不愿意把它放上簡歷的是它跑起來是否順暢以及存檔邏輯是否清晰。先聊重繪優(yōu)化。默認(rèn)情況下panel.repaint()會讓整塊GamePanel重新繪制。如果你的畫布是 900x600里面有 80 個植物和 50 個僵尸每幀完整重繪會有明顯開銷。正確做法是panel.repaint(rect)只刷新發(fā)生變化的小矩形區(qū)域。比如只有一個豌豆射手吐出了子彈就只更新子彈所在的那個行區(qū)域?qū)挾葞资袼馗叨?80 像素。Swing 內(nèi)部會合并臟矩形這樣 CPU 占用能掉下來一半。唯一的坑是你必須確保植物或者僵尸移動時新舊兩個位置都要標(biāo)記為 dirty否則會留下殘影。然后是存檔。直接用 Java 序列化是最簡單的定義一個SaveData類里面放當(dāng)前關(guān)卡、陽光數(shù)量、植物冷卻集合等等。然后把ListPlant里的必要字段復(fù)制到一個Serializable的 DTO 里避免整個 JComponent 序列化導(dǎo)致的NotSerializableException。public class SaveData implements Serializable { private static final long serialVersionUID 1L; public int level; public int sunCount; public int[] plantGrid; // 例如 grid[col]plantTypeId public int totalWave; // 構(gòu)造函數(shù)與普通 getter/setter 省略 }寫文件用ObjectOutputStream輸出到.pvz文件讀檔就是ObjectInputStream反序列化。注意serialVersionUID如果你改了SaveData的字段舊存檔會報InvalidClassException俗稱版本不兼容。這是合理的它能提醒你舊存檔不可用如果你不想讓玩家犧牲進(jìn)度就要設(shè)計獨立的版本號字段并做遷移升級邏輯。最后一個技巧是動畫幀。Swing 不像游戲引擎有現(xiàn)成的Animation組件常見做法是給植物或僵尸塞一個BufferedImage[] frames然后在onFrame里每隔 6 幀切換一次setIcon(new ImageIcon(frames[index]))。這里有個內(nèi)存陷阱new ImageIcon(frame[i])如果每幀都新建對象會創(chuàng)建大量短期對象頻繁觸發(fā) GC。緩存做法是提前把動畫幀數(shù)組轉(zhuǎn)成ImageIcon[]切換時只改 label 引用。// 提前將 4 幀動畫圖全部裝載成 ImageIcon private ImageIcon[] walkFrames { new ImageIcon(zombieWalk1), new ImageIcon(zombieWalk2), new ImageIcon(zombieWalk3), new ImageIcon(zombieWalk4) }; // 每幀調(diào)用切換圖片 if (frameCount % 8 0) { label.setIcon(walkFrames[(frameCount / 8) % walkFrames.length]); }至于全注釋文檔在把代碼調(diào)整好后用mvn javadoc:javadoc生成一份 HTML 文檔放到工程docs文件夾里。很多人在 README 里放架構(gòu)圖都是畫 PPT但 javadoc 生成的類協(xié)作關(guān)系{link}指向是真實可跳轉(zhuǎn)的。寫完這套你的項目基本就具備了注釋詳盡、結(jié)構(gòu)清晰、能跑能存盤的特征。如果你正在準(zhǔn)備 Java 實習(xí)或者校招把這樣的項目講深兩個問題比如 EDT 阻塞你怎么查的、遍歷刪除的異常你怎么解的遠(yuǎn)比背一百道八股文更有效。我自己的血淚經(jīng)驗是分支管理和注釋一樣重要每完成一個植物功能就單獨打一個 tag改壞了還有后悔藥吃。希望幫到你。本文還有配套的精品資源點擊獲取