企业官网建设流程全解析

简介：一份以经典9688雷霆战机个人移植版为例的JAVA ME游戏源码学习包，面向移动开发学习者和J2ME爱好者，帮助其从零理解手机游戏的构建过程。资源包大小4.4MB，压缩包内源码文件与说明材料配套齐全，便于按模块逐段阅读。已有1127人学习下载。内容覆盖MIDlet入口、游戏循环、对象模型与碰撞检测，并延伸讲解Canvas绘图、触摸事件响应以及图像和音频资源的加载播放；同时结合JAVA ME有限内存环境，分析了帧率控制、内存管理与缓存策略等性能优化手段。通过对gameLogic、ui、sound、resource等包结构的深入剖析，读者能够系统掌握JAVA ME游戏开发的核心框架、生命周期管理及调试技巧，为独立开发或继续深造打下扎实基础。

1. JAVA ME游戏的个人移植到底在移什么：以9688雷霆战机为例

标题里的9688雷霆战机，看起来像是一个资源站发放的编号，本质是一个JAVA ME（也就是J2ME）时代的手机游戏包。那个年代的手机游戏最终产物往往就是单一JAR包配一个同名JAD描述文件，能跑在诺基亚、摩托罗拉这些功能机上。个人移植要做的事，是把这样一个老JAR从原本的屏幕分辨率、按键体系和运行时环境里搬出来，让它在新设备或模拟器上还能打开、能存档、能正常通关。

这项工作对怀旧玩家来说是救活一个老游戏，对开发者来说则是一次完整的J2ME应用逆向与适配练习。你不需要有原作者的源码，只要手上有JAR包，就能按下面这条路径走：拆包看结构、反编译找入口、适配分辨率、重映射输入，最后处理存档和计费这些附加模块。这篇笔记适合手上有老游戏包的人、想看J2ME代码结构的开发者，也适合接J2ME老项目维护的工程师。

2. 拆开9688雷霆战机的JAR包：结构、工具与反编译

2.1 JAR包内三个关键层：JAD、MANIFEST与class目录

拿到"9688雷霆战机.jar"之后，第一件事不是急着反编译，而是先把它当普通ZIP解开看结构。J2ME的JAR包在格式上就是标准ZIP，但里面内容比桌面Java程序更收敛：class文件、PNG图片、MID音效，偶尔有几个.dat资源，整体体积通常不超过几百KB。

解开后先看META-INF/MANIFEST.MF，这相当于J2ME世界的启动配置。JAD是外部描述文件，给下载器和商店用的；MANIFEST是内部描述文件，给JVM用的。设备最终以MANIFEST为准。

mkdir -p thunder9688 && cd thunder9688 cp /path/to/9688雷霆战机.jar . unzip -q 9688雷霆战机.jar -d jar cat jar/META-INF/MANIFEST.MF

逻辑说明：unzip -q是安静模式，-d jar指定解压目录，避免资源散落到当前目录。cat之后最需要关注MIDlet-1这一行，它的格式是"显示名, 图标路径, 入口类名"。例如MIDlet-1: ThunderFighter, icon.png, thunder.GameMidlet，其中thunder.GameMidlet就是后面启动游戏用的类名。

参数说明：/path/to/替换成你的JAR实际路径。如果路径含中文，终端里最好给文件名加引号，或者用*通配符。MANIFEST里的MicroEdition-Profile: MIDP-2.0说明支持setFullScreenMode(true)，如果是MIDP-1.0就要换一套布局思路。

2.2 反编译工具：javap单点追、jadx整包看

MANIFEST里如果标着CLDC-1.1/MIDP-2.0，class文件整体可信度很高，普通javap就能直接解析。真正要面对的是混淆：当年很多游戏用ProGuard做体积优化，类名和方法名变成a、b、c。遇到这种包，我一般先用jadx把整包倒一遍，看有没有未混淆的资源和字符串，再用javap对着关键类核对流程。

# 用javap查看入口类的字节码 javap -c -p -classpath 9688雷霆战机.jar thunder.GameMidlet # 用jadx导出Java源码，错误信息丢弃 jadx -d src 9688雷霆战机.jar 2>/dev/null find src -name "*.java" | head -30

逻辑说明：javap -c显示方法字节码，-p保住private成员不丢，-classpath指定JAR路径。javap是JDK自带工具，没有任何外部依赖；jadx适合看整体逻辑，但对CLDC库解析经常有"找不到symbol"的警告，2>/dev/null只是让输出干净，不影响生成源码。如果jadx在你这台机器上因为JDK版本跑不起来，回退到javap逐类看完全可行，只是慢一点。

参数说明：thunder.GameMidlet要换成你自己的入口类名。看字节码时重点找MIDlet子类的startApp()方法，它是一切初始化入口；再找Thread的run()方法，游戏主循环通常藏在这里。

2.3 资源定位：图片、MIDI音效与关卡表

J2ME游戏资源目录命名很随意，常见的有/img、/res、/data。PNG几乎都是8位索引色，MIDI文件承担背景音乐，而.dat或.map这类文件通常是自定义关卡数据，没法直接改，只能在代码里找到解析它的循环逻辑。

find jar -type f | grep -E "\.(png|mid|wav|dat|lay|map)$" | head -30 file jar/img/boss*.png

逻辑说明：find加grep是为了快速列出资源清单；file命令能读PNG位深，遇到"16-bit/color"的图要转成8位，否则部分模拟器和移植环境不显示。遇到自定义二进制资源，先不改内容，记录它的文件名和代码里对应的读取位置。

在移植前把资源清单截图或存成文本，后面分辨率适配时会反复对照：哪个背景图是240x320整屏，哪个精灵图是散帧，都需要这张清单提供依据。

3. 分辨率适配：从240x320到任意屏幕的Canvas改造

3.1 锁定全屏并读真实尺寸：Display与Canvas的配合

J2ME设备的屏幕尺寸五花八门，128x160、176x208、240x320、320x240都出现过。9688这类纵版射击游戏老包原始设计分辨率大概率在240x320附近，但目标环境可能是4:3、16:9甚至全面屏。移植第一步是拿到真实屏幕宽高，并隐藏手机标题栏。

import javax.microedition.lcdui.Canvas; import javax.microedition.lcdui.Graphics; public class ThunderCanvas extends Canvas { private final int DESIGN_W = 240; // 原始设计宽度 private final int DESIGN_H = 320; // 原始设计高度 private final int screenW; private final int screenH; private final float scaleX; private final float scaleY; public ThunderCanvas() { setFullScreenMode(true); // 隐藏标题栏，MIDP 2.0才可用 this.screenW = getWidth(); this.screenH = getHeight(); this.scaleX = (float) screenW / DESIGN_W; this.scaleY = (float) screenH / DESIGN_H; } protected void paint(Graphics g) { g.setColor(0xFF000000); g.fillRect(0, 0, screenW, screenH); // 背景和精灵全部按比例换算 g.drawImage(bg, mapX(bgX), mapY(bgY), Graphics.LEFT | Graphics.TOP); } private int mapX(int x) { return (int) (x * scaleX); } private int mapY(int y) { return (int) (y * scaleY); } }

逻辑说明：setFullScreenMode(true)在MIDP 2.0中把Canvas扩展满屏，否则上方会有一条系统标题栏。scaleX和scaleY分开计算，因为目标屏幕宽高比未必是四比三，共用同一个缩放值会导致画面横纵比例失衡。paint第一句用黑色铺底，作用是清掉上一帧的残影。

参数说明：DESIGN_W/H要改成你实际JAR里背景图的像素尺寸，如果没有原始资源对照，可以在PC模拟器里设定几种常见分辨率，观察哪一组下背景能铺满不变形，反推设计尺寸。

3.2 三种适配方案：拉伸、等比缩放与裁剪的取舍

分辨率适配不是只能拉伸一条路，具体选哪种要看的游戏类型。我用下面这套取舍逻辑：

直接拉伸的问题在射击游戏里最明显：圆形子弹变成椭圆，玩家对"危险区域"的判断会出错。等比缩放虽然留黑边，但游戏逻辑的碰撞判定不用额外处理，我建议默认选它。裁剪看起来好看，但纵版射击的弹幕本来就密，再裁掉左右视野等于增加难度。

3.3 坐标换算与碰撞盒修正：让弹幕落在正确的位置

光改绘制坐标不够，所有碰撞检测也要搬上缩放坐标系。J2ME时代常见的是2x2像素碰撞盒，缩放后可能不足1像素，导致子弹穿过飞机却判不到碰撞。这个坑我踩过几次，解决方法是给缩放后的碰撞盒加一个最小尺寸。

public boolean hitTest(Sprite bullet, Player plane) { int hx = bullet.getX(); int hy = bullet.getY(); // 缩放后的碰撞盒最小保留2像素，避免缩太小漏判 int hw = Math.max(mapW(bullet.getWidth()), 2); int hh = Math.max(mapH(bullet.getHeight()), 2); int px = plane.getX(); int py = plane.getY(); int pw = mapW(plane.getWidth()); int ph = mapH(plane.getHeight()); if (hx + hw < px || px + pw < hx) { return false; } if (hy + hh < py || py + ph < hy) { return false; } return true; }

逻辑说明：Math.max把缩放后小于2像素的子弹碰撞盒强制放大到2像素。矩形相交检测是弹幕游戏最经济的模型，子弹数量上百时比圆形检测省计算量。mapW和mapH对宽高使用独立缩放，避免子弹绘制和碰撞不匹配。

参数说明：2这个最小像素值不是绝对的。如果你的目标屏幕分辨率很高，缩放比例大于2，那碰撞盒本身就会偏大，不需要这层保护；只有往低分辨率缩时才需要。调整时观察"子弹擦边是否判命中"，手感偏大就改成1，偏小就保持2。

坐标换算还有一个细节：不要在更新逻辑里用int反复取整。每一帧都做(int)(x * scaleX)是可以的，但不要把换算结果再存回去参与下一帧运算，误差会累积成肉眼可见的漂移。正确做法是逻辑坐标全程用float，只在paint和碰撞时换算成int。

4. 输入层改造：按键、软键与触屏共存的映射方案

4.1 从keyPressed到getGameAction：读懂J2ME的按键抽象

J2ME的Canvas提供keyPressed、keyReleased和keyRepeated三个回调。物理键码在不同手机上完全不同，所以MIDP设计了getGameAction()把键码映射成逻辑动作：LEFT、RIGHT、UP、DOWN、FIRE、GAME_A到GAME_F。老游戏代码通常写死了一套逻辑动作，移植时一般不动这个抽象层，只改物理键码到逻辑动作的适配表。

protected void keyPressed(int keyCode) { int gameAction = getGameAction(keyCode); switch (gameAction) { case Canvas.LEFT: case Canvas.RIGHT: player.setHMove(gameAction); break; case Canvas.UP: case Canvas.DOWN: break; // 纵版射击，上下不改变速度 case Canvas.FIRE: player.fire(); break; default: handleNumKey(keyCode); } } private void handleNumKey(int keyCode) { switch (keyCode) { case KEY_NUM0: // 原包0键通常是炸弹或暂停，保留原语义 game.pauseOrBomb(); break; case KEY_NUM5: player.fire(); break; } }

逻辑说明：getGameAction()把物理键转换成逻辑动作，移植时保留这个逻辑层，就能在不同设备上复用同一套判断。UP和DOWN在纵版射击里通常用于微调速度或切换武器，如果原游戏没有对应功能，直接留空即可。数字键的处理要放在default分支，因为getGameAction()对数字键返回0。

参数说明：KEY_NUM0和KEY_NUM5是Canvas定义的常量，在所有MIDP实现里一致。如果你的目标设备没有数字键盘，这些分支不会触发，可以保留不删，后续触屏映射时再复用。

4.2 触屏设备的补位：半屏摇杆与半屏开火

现代运行J2ME的环境大多是触屏手机或PC模拟器，没有物理方向键。这时要用pointerPressed、pointerDragged、pointerReleased来模拟按键。纵版射击最自然的映射是左半屏控制移动、右半屏开火。

private boolean startDrag; protected void pointerPressed(int x, int y) { if (x < getWidth() / 2) { startDrag = true; player.moveTo(x, y); } else { player.fire(); } } protected void pointerDragged(int x, int y) { if (startDrag) { player.moveTo(x, y); } } protected void pointerReleased(int x, int y) { startDrag = false; }

逻辑说明：以屏幕中线为界，左半屏按下进入拖拽模式，手指移动时飞机跟着走；右半屏按下直接开火。纵版射击不需要精确的方向键八向判定，直接把手指坐标当作飞机坐标，手感比模拟按键更直接。

参数说明：getWidth()在触屏事件里返回的是像素值，半屏判断用<而不是<=，避免中线上按下时两个分支都不触发。如果原游戏有"按住右半屏连发"的设定，可以再加一个firing标志位，在游戏循环里检查。

4.3 组合键与长按处理：弹幕射击的按帧输入细节

J2ME游戏里很多弹幕射击逻辑是按帧数来设计连发节奏的：每3帧发一颗子弹。原始逻辑基于固定的屏幕刷新率，移植到新设备后，如果刷新率从50fps变成90fps，连发速度会明显变快，游戏难度失控。这个问题在触屏上更突出，因为触屏没有keyRepeated事件，连发必须自己计时。

private boolean firing; private long fireStartTime; protected void pointerPressed(int x, int y) { if (x >= getWidth() / 2) { firing = true; fireStartTime = System.currentTimeMillis(); } } // 在游戏主循环的 update 里调用 private void updateFiring() { if (!firing) { return; } long held = System.currentTimeMillis() - fireStartTime; // 原游戏大约每3帧一发，按60fps折算为50ms间隔 if (held % 120 < 30) { player.fire(); } }

逻辑说明：held % 120 < 30的意思是把每120ms分成一个周期，其中前30ms触发一次开火。这样即使主循环帧率波动，连发间隔也稳定。原始3帧间隔对应50ms左右，给30ms窗口是容忍线程调度误差。

参数说明：120和30这两个值都来自原始帧节奏的折算。如果原始代码是"每5帧一发"，就改成200ms周期、50ms窗口。先在PC模拟器里用原始按键玩一局，用手机秒表估算实际连发速度，再回来调参数。手感这个事没有公式，只能靠对比原版逐帧调。

5. JAVA ME移植避坑指南：RMS存档、线程同步与SMS计费

5.1 RMS存档读不到：RecordStore在不同运行时差异

现象：移植后游戏能进，但每次重启都从头开始，存档全丢。这是J2ME移植里最典型的翻车点。

原因：J2ME的存档接口是RMS（Record Management Store），RecordStore.openRecordStore("storeName", true)会把数据写到运行时私有目录。不同模拟器或移植框架对这个storeName的落盘路径处理不一样，有的按JAR名建目录，有的按入口类名建目录，换运行环境后storeName对应不上了。

解决：先写一个导出工具，把原运行环境里的RMS记录dump成文件，再让移植后的代码优先从这个文件恢复存档。

import javax.microedition.rms.RecordStore; public class SaveManager { private static final String STORE = "thunder9688_save"; public static byte[] loadSave() { try { RecordStore rs = RecordStore.openRecordStore(STORE, false); byte[] data = rs.getRecord(1); rs.closeRecordStore(); return data; } catch (Exception e) { return null; // 读不到就返回null，上层开新档 } } }

逻辑说明：openRecordStore(STORE, false)第二个参数为false表示不存在时不创建，避免误写一个空存档覆盖正常逻辑。getRecord(1)读第一条记录，J2ME的RMS记录从序号1开始。返回null后游戏逻辑走"新建存档"流程，这样至少不会崩溃。

参数说明：STORE字符串必须与原包源代码里的storeName完全一致。如果反编译代码里显示openRecordStore("Thunder9688", true)，这里的常量要改成Thunder9688，大小写敏感。找storeName最简单的方法是jadx搜索openRecordStore调用点。

5.2 画面闪烁与花屏：GameCanvas双缓冲与线程同步

现象：移植后画面闪得厉害，或者快速移动时出现残影、花屏。

原因：老游戏有两种渲染写法。一种是Canvas.repaint()配合paint()，本身依赖系统派发重绘事件，异步时序在移植运行时里容易抖动；另一种用GameCanvas.getGraphics()直接画，但没调用flushGraphics()，缓冲区不完整提交。两者混用时花屏概率很高。

解决：统一收敛到GameCanvas双缓冲，渲染只走一条链路。

import javax.microedition.lcdui.game.GameCanvas; public class GameLoop extends GameCanvas implements Runnable { private volatile boolean running = true; private final Graphics g; public GameLoop() { super(true); // true表示内部双缓冲 g = getGraphics(); } public void run() { while (running) { update(); // 游戏逻辑 drawFrame(g); // 绘制所有精灵 flushGraphics(); // 提交缓冲 try { Thread.sleep(16); } catch (InterruptedException e) { stop(); } } } }

逻辑说明：super(true)开启GameCanvas内置双缓冲，drawFrame里把所有drawImage和fillRect都画到后台缓冲，最后一次性flushGraphics()提交。这样画面不会出现中间状态。volatile修饰running是为了避免多线程可见性问题，stop时能及时退出循环。

参数说明：Thread.sleep(16)对应约60fps。如果移植目标设备性能弱，改成20或30，但要重新检查连发节奏，因为update和draw的频率都跟着线程走。把sleep值放到常量里，标注原始帧率，方便后续统一调。

5.3 声音消失或爆音：MMAPI的降级路径

现象：背景音乐无声、音效只响一次、或者播放时爆音。

原因：J2ME的声音标准是MMAPI（JSR 135），Manager.createPlayer支持的类型由运行环境决定。MIDI在不少现代模拟器里支持不全，WAV和WMA格式更是痛苦。翻译一下就是：原包在诺基亚上能响的音乐，移植后很可能黑匣子一样无声。

解决：做一个播放器封装，支持则播放MIDI，不支持则降级为Manager.playTone提示音。

import javax.microedition.media.Manager; import javax.microedition.media.Player; public class SoundManager { public static void playBgm() { try { Player p = Manager.createPlayer( SoundManager.class.getResourceAsStream("/sound/boss.mid"), "audio/midi"); p.setLoopCount(-1); // -1 表示无限循环 p.start(); } catch (Exception e) { // 降级为单音提示，至少让玩家知道音效模块还活着 Manager.playTone(60, 150, 100); } } }

逻辑说明：createPlayer的第二个参数audio/midi是MIME type，运行时按它寻找解码器。抛出异常说明当前环境不支持MIDI，降级到playTone。数字60对应中央C，150毫秒时长，音量100。虽然难听，但至少比完全无声让玩家以为程序死掉好。

参数说明：/sound/boss.mid要换成你资源实际路径，路径错误时也会抛异常走降级；但注意区分"资源不存在"和"解码器不支持"，我建议先看e.getMessage()再决定是否值得修路径。如果你在移植层做的，直接把整个声音模块编译开关关掉也是一种策略。

5.4 老游戏的SMS计费模块必须摘除

现象：移植版点击"开始游戏"后卡住、闪退，或者弹出一个黑屏的假对话框。

原因：那个年代很多游戏内置短信计费（WMA/JSR 120），向指定号码发一条短信来解锁完整版。移植到新环境后，Connector.open("sms://xxxx")调用会抛异常，但很多老代码没有捕获，直接中断了游戏流程。

解决：在入口处做一次能力探测，不支持WMA的运行时直接跳过计费分支，进入主菜单。

private boolean smsBillingAvailable() { try { Class.forName("javax.wireless.messaging.MessageConnection"); return true; } catch (ClassNotFoundException e) { return false; } }

逻辑说明：Class.forName探测运行时是否包含WMA类库。现代模拟器实现JSR 120的很少，多数情况会返回false。拿到结果后，在startApp()里判断，如果不支持计费就直接调用showMainMenu()。

参数说明：这段代码只做能力探测，不做任何短信发送操作。如果你的反编译源码里看到Connector.open("sms://")之类的调用，直接注释掉或改成空方法，不要保留真实号码字符串。这个模块对今天的使用者只有风险没有价值，彻底移除最干净。

6. 移植完怎么验证：模拟器试用、真机手感与存档回归

在PC上先用模拟器把原始JAR跑通，这是整个移植的基准。我会记录三件事：原始分辨率下的背景滚动速度、每发子弹的连发间隔、进入第二关所需的击杀数。这三个数值在移植后必须能对齐，否则说明某个环节改过头了。

移植版的验证我列成一张回归清单：

如果某一项不过，我习惯从改动的代码入手排查，而不是整体推翻。比如触屏漂移，先查pointerPressed里是否用了getWidth()但忘记在sizeChanged里更新；比如帧率不稳，先看子弹对象是否在复用，J2ME环境下GC一触发就容易掉帧。

分享一个多年来的个人习惯：每次只改一个变量。先只改分辨率，跑通；再只加触屏事件，跑通；最后才动存档和声音。因为J2ME代码经过反编译之后可读性差，一次改两处以上出问题，很难判断是谁导致的。我曾经在一次移植里同时改了缩放系数和线程sleep值，结果飞机轨迹变成锯齿状，找了两小时才发现是缩放系数用了int取整，把scaleX从float赋值给int直接丢了小数位。这类问题肉眼很难看出来，最后是靠把系数打印到日志才定位的。

操作上建议保留原始JAR不动，每次改动都另存副本，并记录改了哪个类。反编译再编译这条路本身就有一点玄学成分，保留备份就是后悔药。移植完成后，把原始JAR和移植版JAR放同一台模拟器里跑同一关卡，一只手玩原版一只手玩移植版，手感差异比任何帧率数据都直观。希望这篇笔记里的拆包路径和排错清单能帮到你，少走几趟我走过的弯路。

本文还有配套的精品资源，点击获取