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