Android贪吃蛇实战：双时钟游戏循环与TileView网格绘制

简介这份面向计算机专业毕业设计阶段的贪吃蛇项目文档以Android平台手机游戏开发为主线适合正在准备毕设选题、需要参考完整论文结构与实现思路的本科或高职学生。内容从Java语言基础与Android系统特点切入延伸到Drawable、Canvas、Thread等核心类与控件的使用方法并结合游戏循环、蛇身移动、食物生成、边界与自身碰撞检测、触摸事件响应等环节说明如何实现一个可运行的单机版贪吃蛇同时涉及动画过渡与多分辨率屏幕适配等实践细节。整包仅含1个doc文档约301KB篇幅紧凑便于通读与摘取章节框架。目前已有503人学习可用作毕设写作模板与技术梳理参考帮助读者快速厘清论文摘要、关键词、技术方案与总结的组织方式并据此对照自己的开发进度查漏补缺。1. 贪吃蛇的难点从来不是规则为什么第一版总会卡成幻灯片贪吃蛇的规则两句话就说完了吃到食物变长撞墙撞自己就结束。可把它搬到 Android 上绝大多数人的第一版会出现同一个现象蛇走得一顿一顿方向键按下去要等半拍才生效玩到后期蛇变长之后更明显。问题基本不会出在规则上而是出在一个更底层的地方游戏里其实有两个互不相干的时钟。一个是你自己的逻辑时钟蛇每隔多少毫秒挪一格另一个是平台给的绘制时钟View 什么时候真正被重绘。把这两个时钟合成一个是这类作品最容易失败的地方。搞懂它们怎么拆开、又怎么对齐比背下 Canvas、Drawable、Thread 的 API 有用得多。2. 游戏循环为什么while(true)会 ANR而后台线程配postInvalidate就正常2.1 Android 的单线程 UI 模型所有绘制和触摸都在一条线程上排队Android 的 View 体系是单线程模型。触摸事件分发、onMeasure、onLayout、onDraw、Activity 的生命周期回调全部排在同一条主线程的消息队列里一个接一个执行。这意味着只要主线程里有一个不返回的函数后面所有的消息都送不进来。初学者最容易写出的版本是把这个循环直接塞进onDraw或者onCreate// 错误示范主线程里死循环推进游戏 public void startGame() { while (true) { update(); // 改坐标、判碰撞 invalidate(); // 请求重绘 // 没有任何让出 CPU 的地方 } }invalidate()在这里其实没用。它只是给 View 打了一个“脏”标记真正调用onDraw要等主线程回到消息循环、处理到那条重绘消息才会发生。而现在主线程卡在while里永远回不去重绘消息永远排不到屏幕一帧都不会更新。同时系统的输入事件也进不来超过几秒收不到输入响应就会弹出“应用无响应”。更有隐蔽的一种变体是在循环里调用Thread.sleep(100)看起来让出了 CPU屏幕是不卡死了但invalidate()依然只能在主线程执行而主线程现在正在执行你这个sleep一趟下来照样卡顿。真正的问题在于你在本该处理消息的线程上抢走了本该属于消息循环的时间片。2.2 拆成两个时钟后台线程决定“什么时候走一步”绘制系统决定“什么时候画一帧”正确的做法是把职责拆开。后台线程只负责推进逻辑改蛇的坐标、判碰撞、算分数这些都是纯数据运算跑在哪条线程都行。算完之后它不去直接画而是投递一个“请重绘”的请求然后继续按自己的节奏走下一步。绘制由平台的渲染管线在下一个 VSYNC 信号到来时统一调度往往 16.6 毫秒一帧和你的逻辑频率完全解耦。public class SnakeView extends TileView implements Runnable { private Thread mThread; // 逻辑时钟的载体 private volatile boolean mRunning; // 让后台线程能看到停止信号 private long mDelay 600; // 当前每走一格所需的毫秒数 Override public void run() { while (mRunning) { long frameStart SystemClock.uptimeMillis(); update(); // 1. 推进一帧逻辑不碰任何 UI 对象 postInvalidate(); // 2. 从任意线程投递重绘请求立即返回 long cost SystemClock.uptimeMillis() - frameStart; long sleepTime mDelay - cost; // 3. 扣掉本帧耗时保持节奏稳定 try { if (sleepTime 0) { Thread.sleep(sleepTime); } } catch (InterruptedException e) { mRunning false; // 被打断就干净退出不吃掉异常 } } } }这段代码有三处值得琢磨。第一postInvalidate()而不是invalidate()后者要求调用方必须是 UI 线程在后台线程调用会直接抛异常前者内部持有一个主线程的 Handler会把请求转发过去。第二计时用SystemClock.uptimeMillis()而不是System.currentTimeMillis()后者是墙上时钟用户手动改系统时间、或者网络对时都会让它跳变表现出来就是蛇忽然狂奔一段或者停住不动。uptimeMillis从开机算起且不含深睡时间只往前走。第三mDelay - cost这个减法很关键如果本帧逻辑算得慢比如蛇很长、碰撞检测遍历了上百节那么睡眠时间就该相应缩短否则每一帧都会累积一点误差几十帧之后节奏就漂了。当sleepTime算出来是负数时直接跳过睡眠宁可掉一帧也不让任务堆积。最后mRunning加了volatile因为它是被主线程写、后台线程读的没有这个修饰符后台线程可能永远读到缓存里的旧值退出时线程停不下来。2.3 线程还是 Handler两种刷新模型的取舍同样的效果也可以不用额外的线程改用 Handler 延迟消息自己给自己发消息private final Handler mRefreshHandler new Handler(Looper.getMainLooper()) { Override public void handleMessage(Message msg) { SnakeView.this.update(); SnakeView.this.invalidate(); sendEmptyMessageDelayed(0, mDelay); // 下一拍 } }; public void stopRefresh() { mRefreshHandler.removeCallbacksAndMessages(null); // 一句就停干净 }两种方案的差别在于一条是常驻线程逻辑跑在主线程之外主线程再忙也不影响逻辑推进另一条复用主线程好处是省一条线程、停止和重启极简单代价是逻辑耗时直接吃掉 UI 线程的时间预算一旦update()变重就会掉帧。贪吃蛇这种量级两条都能跑但如果哪天想让蛇支持几百节的超长模式或者加上寻路 AI后台线程方案会更稳。维度Thread sleep postInvalidateHandler 延迟消息自循环线程开销多一条常驻线程复用主线程无额外线程节奏稳定性可扣耗时补偿但受线程调度影响受消息队列中其他消息插队影响生命周期管理必须手动置标志位并 interruptremoveCallbacksAndMessages(null)即可逻辑耗时承受力不占主线程较重的逻辑也无所谓逻辑跑在主线程重了会掉帧适合场景逻辑较重、帧率要求稳定逻辑轻、希望代码路径简单2.4 速度曲线mDelay从 600 降到 100为什么必须有个下限难度递增的实现方式很朴素每吃到一个食物就把mDelay减一点。但这里有两层约束容易被忽略。private static final long SPEED_INIT 600; // 开局每格 600ms private static final long SPEED_MIN 100; // 速度上限再快人手跟不上 private static final long SPEED_STEP 8; // 每吃一个食物减少 8ms private void onAppleEaten() { mScore; mDelay Math.max(SPEED_MIN, SPEED_INIT - mScore * SPEED_STEP); }第一层是人的反应窗口。一帧逻辑推一格mDelay越小玩家从看到蛇头位置到按下方向键的时间就越短。低于 100 毫秒时大部分人的操作已经变成盲按了再快只会让游戏从“挑战”变成“随机”。第二层是渲染管线的节流postInvalidate()只是请求真正绘制受 VSYNC 限制一帧大约 16.6 毫秒。当mDelay逼近甚至小于这个值时逻辑推进速度会超过屏幕刷新速度出现连续几帧的逻辑变化被合并成一次绘制视觉上就是蛇在“瞬移”。所以速度下限不只是体验问题也是物理上限问题这条链路能表现出的最快移动由屏幕刷新率兜底。知道这一点就明白为什么在 120Hz 屏上调同样的参数观感会和 60Hz 屏不一样。3. 网格坐标系TileView为什么要把屏幕切成格子3.1 用行列而不是像素逻辑层和分辨率的解耦TileView干的事情很简单把整个 View 的可绘制区域切成mXTileCount列 ×mYTileCount行的等大方块所有游戏对象的位置都用整数对 (列, 行) 表示从不出现像素坐标。这个设计带来三个直接收益。逻辑与分辨率彻底解耦。同一套蛇的坐标数据在低密度屏和高密度屏上都是同一个数组不需要任何分支判断。碰撞检测退化成整数相等比较不存在浮点误差问题两节蛇的坐标要么完全一样要么完全不一样不会出现“差 0.3 像素算不算撞上”这种折磨人的边界情况。缩放和平移只在绘制那一层做一次逻辑层完全无感。坐标对象本身也要注意一个 Java 层面的老问题public class Coordinate { public final int x; public final int y; public Coordinate(int x, int y) { this.x x; this.y y; } Override public boolean equals(Object o) { if (this o) return true; if (!(o instanceof Coordinate)) return false; Coordinate c (Coordinate) o; return x c.x y c.y; } Override public int hashCode() { return x * 31 y; // 必须和 equals 保持一致 } }只重写equals不重写hashCode是 Java 里代价很高的经验教训。碰撞检测如果哪天改成用HashSetCoordinate判重缺了hashCode就会全部判不中因为默认实现基于对象地址。字段声明成final也有讲究蛇的坐标一旦创建就不应该被改需要新位置就 new 一个。否则一旦把同一节蛇的对象引用塞进集合又改了它的值集合内部的桶位置就失效了。3.2onSizeChanged格子大小、居中偏移必须在这里一次算清View 在构造函数执行时还拿不到自己的真实尺寸getWidth()返回 0。所有跟尺寸有关的量只能在onSizeChanged里算这个方法在布局流程结束、尺寸确定后被调用。Override protected void onSizeChanged(int w, int h, int oldw, int oldh) { super.onSizeChanged(w, h, oldw, oldh); // 取长宽两个方向能容纳的较小值保证格子是正方形且不越界 int tileSize Math.min(w / mXTileCount, h / mYTileCount); mTileSize Math.max(tileSize, 1); // 防止极端尺寸下算出 0后面做除数会崩 // 剩余空间均分成左右、上下两条边 mXOffset (w - mXTileCount * mTileSize) / 2; mYOffset (h - mYTileCount * mTileSize) / 2; clearTiles(); // 尺寸变了旧的瓦片状态全部作废 }取min而不是分别算宽高两个尺寸是为了让格子保持正方形。如果横向用w / cols、纵向用h / rows在宽高比不是整除关系的屏幕上会得到长方形格子蛇看起来会被拉扁。取min之后剩下的余数一半放左边一半放右边游戏区域就自动居中了。Math.max(tileSize, 1)这一句看着多余但只要有人把行列数设得比屏幕像素还大就会算出 0后面x * mTileSize全是 0所有东西叠在原点排查起来极其费劲。最后clearTiles()不能省尺寸变化意味着所有瓦片索引对应的物理位置都变了不清理会画出一堆错位的残影。3.3onDraw的三步顺序setBounds漏一次就错位绘制阶段要做的事本质上就是把“哪个格子放哪张图”翻译成像素矩形然后交给画布。public void setTile(int x, int y, int index) { if (x 0 || x mXTileCount || y 0 || y mYTileCount) return; mTiles[y * mXTileCount x] index; // 一维数组存二维坐标 } Override protected void onDraw(Canvas canvas) { super.onDraw(canvas); for (int y 0; y mYTileCount; y) { for (int x 0; x mXTileCount; x) { int index mTiles[y * mXTileCount x]; if (index 0) continue; // 空格子直接跳过 Drawable d mTileGrid[index]; int left mXOffset x * mTileSize; int top mYOffset y * mTileSize; d.setBounds(left, top, left mTileSize, top mTileSize); d.draw(canvas); } } }用一维数组加y * mXTileCount x寻址是老式瓦片地图的经典手法少一层对象引用遍历时缓存局部性更好在低端设备上能省出可观的绘制时间。Drawable和裸Bitmap的区别在于Drawable是“可绘制物”它自带bounds画在哪块矩形里、level、state三个属性同一个实例可以被画到无数个不同的位置。但这也意味着它的bounds是有状态的如果某次忘记调用setBounds它会沿用上一次的矩形表现出来的现象就是某几节蛇身忽然跑到屏幕别的地方或者大小不对。每帧重设bounds这一步看着啰嗦但是必须做。另外资源图放在不同密度的目录下时Drawable会按屏幕密度自动做缩放适配裸Bitmap不会这是优先选Drawable的实际理由。4. 蛇的数据结构为什么“移动”只需要两次操作4.1 头部插入、尾部删除一次移动的代价是 O(n) 的一次搬移新手容易把蛇的移动理解成“每一节都往前挪一格”。实际上真正的实现只需要两步在头部插入一个新坐标把尾部那个坐标删掉。中间那些节的位置完全不变它们只是“被后面的节追上了”。private static final int NORTH 0, SOUTH 1, EAST 2, WEST 3; private static final int[] DX {0, 0, 1, -1}; // 与方向常量一一对应 private static final int[] DY {-1, 1, 0, 0}; // 注意屏幕坐标系 y 向下为正 private void moveSnake() { mDirection mNextDirection; // 本帧生效的方向 Coordinate head mSnakeTrail.get(0); int nx head.x DX[mDirection]; int ny head.y DY[mDirection]; mSnakeTrail.add(0, new Coordinate(nx, ny)); // 头插 boolean eaten (nx mApple.x ny mApple.y); if (eaten) { mScore; // 不删尾长度自然 1 resetApple(); onAppleEaten(); } else { mSnakeTrail.remove(mSnakeTrail.size() - 1); // 删尾长度不变 } }方向用常量加查表而不是在switch里写四套nx/ny计算好处是后面加方向、做 AI 寻路、写单元测试都只需要操作数组下标。ArrayList.add(0, x)是 O(n) 的数组搬移蛇很长时每帧都要搬一次理论上有开销但贪吃蛇的节数通常不超过几百这个量级在现代设备上完全感知不到。真要做超长蛇换成双端队列或者环形缓冲区就行接口几乎不用改。DY里 NORTH 是 -1是因为屏幕坐标系的 y 轴向下为正。这个约定和数学坐标系相反是方向判断写反的头号原因后面排查部分还会提到。4.2mNextDirection为什么不能让按键回调直接改当前方向按键事件发生在主线程逻辑推进发生在后台线程。如果按键回调里直接写mDirection dir会撞上一个很隐蔽的时序问题玩家在一帧之内快速按了“上”又按“下”如果直接改当前方向那么这一帧的蛇头位置是按“上”算出来的但碰撞检测时读到的mDirection已经是“下”了方向常量一错整个判断逻辑全乱。正确做法是用两个变量分离“已经生效的方向”和“玩家最新的意图”private void handleDirectionKey(int keyCode) { int dir mapKeyToDirection(keyCode); if (dir 0) return; // 反向保护基于已经生效的 mDirection 判断而不是 mNextDirection if (mDirection NORTH dir SOUTH) return; if (mDirection SOUTH dir NORTH) return; if (mDirection EAST dir WEST) return; if (mDirection WEST dir EAST) return; mNextDirection dir; }反向保护必须基于mDirection。因为mNextDirection是“待生效”的值玩家在一帧内连按两个方向时它会被后一次覆盖如果拿它来判断反向会出现“按了左、又按了上程序认为当前在往左走于是允许向上”——这本身没错但如果顺序反过来判断就可能出现漏判。基于已经生效的方向能保证一个物理上连续的身体不会瞬间折返撞到自己。顺带一提mDirection和mNextDirection都是被两条线程读写的int。int的读写本身是原子的不会读到“半截值”但可见性没有保证主线程改了mNextDirection后台线程可能还在看旧值。要么加volatile要么更彻底一点把按键事件打包成消息投递到逻辑线程自己的队列里让所有状态只有一个写入者。4.3 碰撞检测三处边界和“尾巴豁免”碰撞检测看起来是最简单的部分实际上 off-by-one 错误最容易出现在这里。private boolean isDead(Coordinate newHead) { // 1. 撞墙 if (newHead.x 0 || newHead.x mXTileCount) return true; if (newHead.y 0 || newHead.y mYTileCount) return true; // 2. 撞自己从下标 1 开始跳过新蛇头本身 // 如果本帧不吃食物尾巴会在同一帧消失所以最后一节可以豁免 int limit mSnakeTrail.size() - 1; for (int i 1; i limit; i) { if (newHead.equals(mSnakeTrail.get(i))) return true; } return false; }三个细节。第一遍历从i 1开始。下标 0 是新的蛇头拿它和自己比等于开局第一步就判死。第二循环上界减一是因为这一帧如果不吃食物尾部那一节会在同一帧被删掉蛇头正好走到尾巴当前所在的格子时实际上尾巴已经让开了不该算碰撞。第三判定顺序必须是“先判墙和自身再判食物”。如果反过来先处理吃食物、蛇变长、尾巴保留再去做自身碰撞检测那么原本应该豁免的尾部位置就变成了真实障碍会出现“明明能吃到食物却莫名game over”的现象。这个顺序如果不明确写出来代码读起来是看不出问题的只有实际玩到那一步才会暴露。5. 排查清单真机上才会暴露的五个坑5.1 蛇走得一顿一顿滑动越久越明显现象模拟器上还凑合装到真机上玩到蛇变长之后能明显感到卡顿偶尔整帧停一下。原因onDraw里每帧都在new Paint()、new Rect()、拼字符串调drawText一秒钟几十次分配累积起来触发垃圾回收。早些年设备上的回收是整段暂停的一次能有几十毫秒表现出来就是一帧卡死。另一个常见原因是mDelay用了固定值但没扣本帧耗时节奏逐渐漂移。解决所有Paint、Rect、Paint相关的对象全部提到成员变量里只创建一次onDraw里禁止任何形式的对象分配和字符串拼接用SystemClock.uptimeMillis()做耗时补偿。判断依据不要靠感觉用性能分析工具看一眼onDraw的耗时占比比猜快得多。5.2 旋转屏幕或者切后台回来分数清零、蛇重新开始现象横竖屏切换一下游戏从头开始按 Home 键回来蛇的位置重置了。原因屏幕配置变化时Activity 默认会被销毁重建View 里的mSnakeTrail、mScore、mApple这些成员变量全部随之消失。游戏状态存在 View 对象里就等于把状态存在了随时会被丢弃的地方。解决轻度做法是在清单文件里声明configChanges让旋转不重建但这只解决旋转切后台被系统回收依然会丢。稳妥做法是把游戏状态抽到一个独立的数据对象里通过 ViewModel 或者onSaveInstanceState保存Activity 重建后再把它注回新的 View。这个改动同时也是走向“引擎与视图分离”的第一步。5.3 手指滑动方向判反或者要滑很长一段才转向现象往上滑蛇往下走或者小幅度滑动没反应必须滑过大半个屏幕。原因屏幕坐标系 y 轴向下为正dy 0代表向下滑对应的是 SOUTH很多人习惯性当成向上。另一个原因是判断逻辑先比 X 再比 Y斜着滑动时被判成水平方向也可能是没有最小滑动阈值手指按下去的轻微位移就被当成一次转向。private float mDownX, mDownY; Override public boolean onTouchEvent(MotionEvent e) { if (e.getAction() MotionEvent.ACTION_DOWN) { mDownX e.getX(); mDownY e.getY(); return true; } if (e.getAction() ! MotionEvent.ACTION_UP) return true; float dx e.getX() - mDownX; float dy e.getY() - mDownY; float threshold 20 * getResources().getDisplayMetrics().density; if (Math.abs(dx) threshold Math.abs(dy) threshold) return true; // 抖动忽略 if (Math.abs(dx) Math.abs(dy)) { handleDirectionKey(dx 0 ? EAST : WEST); // 右滑为东 } else { handleDirectionKey(dy 0 ? SOUTH : NORTH); // y 向下为正dy0 是南 } return true; }阈值用 dp 换算而不是写死像素否则高密度屏上 20 像素还不到一个指甲盖低密度屏上又宽得离谱。5.4 换一台手机格子就错位或者边缘被切掉一半现象在一台设备上跑得好好的换到另一台后发现四周黑边一大片或者最右一列蛇身只画出一半。原因格子尺寸写成了固定像素或者onMeasure没有处理测量模式为“不约束”的情况此时父容器给的期望尺寸不可用算出来的宽高是 0再或者onSizeChanged里先算了居中偏移、后用新的格子尺寸顺序反了就会得到负数偏移。解决格子尺寸一律用min(w / cols, h / rows)动态算余数对称分成两条边onMeasure里当尺寸不受约束时给一个默认值兜底onSizeChanged里严格按“先算格子大小、再算偏移、最后清空瓦片”的顺序执行。5.5 退出游戏后设备发热后台线程还在跑现象按返回键退出过一阵看电量掉得很快或者重新进游戏发现蛇的速度变成原来的两倍。原因Thread里的while (mRunning)没有在任何生命周期回调里被置为 falseView 已经不可见了线程还在每 600 毫秒醒来算一次、投递一次重绘白白耗电。更麻烦的是重进游戏又起了一条新线程两条线程同时改同一个蛇的数组出现“速度快一倍”甚至数据结构错乱。解决在onPause里停、onResume里起在onDetachedFromWindow里把运行标志置 false 并调用interrupt()catch (InterruptedException)里一定要退出循环不能吞掉异常继续跑。用 Handler 方案的退出时调用removeCallbacksAndMessages(null)一句就能清理干净。启动线程前先判一下mThread null || !mThread.isAlive()避免重复创建。6. 设计取舍把游戏逻辑塞进 View 里这笔账怎么算这份作品里最值得回头看的一个决定是把整个游戏逻辑都写进了SnakeView。写的时候确实快线程、绘制、数据都在一个类里改一个变量不用跨文件找。但代价在验收阶段会一并到来——想单测一下碰撞检测发现必须 new 一个 View而它又依赖 Context想在屏幕旋转后恢复状态发现状态散落在七八个成员变量里没有任何一处能整体取出。常见的实现思路是把SnakeEngine抽成纯数据类只持有蛇的坐标数组、食物位置、分数、方向只暴露tick()和几个查询方法不导入任何android.view下的类。这样一来一局游戏可以用纯 JVM 单元测试跑完喂 1000 组随机方向输入断言蛇的长度始终等于初始长度加分数、任意两节坐标不重合、蛇头坐标永远在规定范围内。这套断言能在几秒内跑完比在真机上手动点一百局有效得多。第二个取舍是全屏重绘还是局部重绘。网格游戏理论上可以只重画变化的那两三个格子蛇尾离开的、蛇头进入的、食物所在的那块。但瓦片之间是有层叠关系的蛇头可能盖在食物上尾巴离开的位置下面可能还有别的图层局部重绘要把这些关系理清楚代码复杂度直接翻倍。在格子数量只有几百个的规模下全屏重绘的实际开销完全够用这时候选简单方案是对的。真到了需要优化的规模正确的方向也不是改局部重绘而是把整个棋盘预渲染成一张位图每帧只贴这一张。第三个取舍是“定长跳动”还是“帧间插值”。贪吃蛇是网格游戏一帧跳一格视觉上那种一顿一顿的节奏反而是它该有的手感。如果要做平滑移动就得把逻辑坐标和渲染坐标分开存逻辑上蛇头还在第 3 格渲染时按本帧进度百分比画在第 3 格和第 4 格之间。这个改动会让绘制层多一层插值计算也会让碰撞判定必须基于逻辑坐标而非渲染坐标稍不注意就会出现“看着没撞上却死了”的争议。我的习惯是先确认这个手感是不是玩法的一部分再决定要不要动它。从那以后我每次写这类带循环的界面都强制自己先画一遍“谁在什么线程、以什么频率、改哪几个变量”的时序草图再动键盘退出路径和启动路径成对写先写停止再写启动。吃过一次后台线程没停、两份逻辑同时改同一个数组的亏之后这个习惯就再没丢过。希望帮到你。本文还有配套的精品资源点击获取