尧图网页设计 
简介基于Android Studio实现的2048小游戏完整项目是一份定位明确的安卓大作业/课程设计源码面向正在学习安卓开发或需要完成期末项目的初学者提供了可下载后快速运行的参考范例。压缩包共141个文件整体仅约394KB结构紧凑其中50个xml文件负责界面布局、菜单与颜色等资源配置30个webp文件存放数字方块和背景图片21个java文件实现棋盘生成、滑动监听、数字合并、计分及胜负判断等核心逻辑gradle、properties及jar等文件共同支撑项目构建与依赖配置目录划分清楚便于按模块查阅和修改。当前已有269人学习下载适合作为安卓入门练手素材。代码注释详实关键算法和事件处理均配有说明新手也能看懂每一步实现思路作为个人手打并获导师认可的98分项目下载后简单部署即可运行对需要期末大作业或课程设计高分参考的同学有直接借鉴价值。1. 为什么 Android Studio 2048 小游戏项目是大作业里的最优解如果你正在为安卓大作业发愁网上搜「android studio 2048小游戏代码」的结论大概率是同一个这个项目代码量不大、演示效果直观、答辩时能讲的东西又多从手势识别到自定义 View 再到状态管理一个 2048 能把安卓课的核心考点全串起来。但真去下载你会发现能直接跑完的完整工程其实很少——多数是贴出来的半截代码Activity 缺这少那算法类更是黑匣子。这份基于 Android Studio 的 2048 小游戏源代码是一个完整可运行的安卓工程从 Gradle 配置、MainActivity 到核心算法类全部齐整适合期末大作业、课程设计想拿去做面试作品集也不掉价。下面按「结构—算法—渲染—踩坑—进阶」的顺序拆读完你能照着复现也能给它改出自己的功能。2. 源码结构拆解Activity、View 与算法类各管一摊拿到一份源代码我建议你先别急着点 Run先把目录结构打开看一遍。这个 2048 小游戏项目的代码量不算大但分层做得比较清楚核心就三个 Java 类加一个布局文件。先把它们的分工讲明白后面改起来你才知道动哪里。2.1 工程目录这几个文件才是你答辩时要讲的重点下面这张表是这份源码里最值得关注的文件也是你答辩时能展开讲的核心文件职责答辩讲解要点MainActivity.java应用入口设置全屏、加载布局、初始化 View、接收分数回调Activity 生命周期、setContentViewGame2048View.java自定义 View负责手势监听、棋盘绘制、动画刷新onTouchEvent、onMeasure、onDrawGame2048Algorithm.java核心算法类持有棋盘二维数组处理合并、生成、游戏状态二维数组操作、状态机设计activity_main.xml页面布局放置 TextView 与自定义 View布局层级与自定义控件引入很多网上下载的同类源码把算法逻辑写在 View 内部表面上省事实际上答辩时很难把「逻辑」和「显示」分开讲。这份源码把算法单独抽成一个类是更接近真实项目的写法。你在讲解时可以直接说棋盘状态是数据层View 只负责把数据画出来手势识别是交互层三层各管一摊互相解耦。这句话一说出口比背十页概念都有说服力。MainActivity 的初始化部分大致是这样的public class MainActivity extends AppCompatActivity { private Game2048View gameView; private TextView tvScore; private TextView tvHighScore; Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); // 隐藏系统状态栏让游戏区域完整铺满屏幕 getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN); setContentView(R.layout.activity_main); gameView findViewById(R.id.game_view); tvScore findViewById(R.id.tv_score); tvHighScore findViewById(R.id.tv_high_score); // 分数回调接口分数变化时由 View 层向外抛出 gameView.setOnScoreChangedListener(new Game2048View.OnScoreChangedListener() { Override public void onScoreChanged(int score, int highScore) { tvScore.setText(分数 score); tvHighScore.setText(最高 highScore); } }); } }这里的关键点是用接口回调而不是让 Activity 去轮询分数。自定义 View 内部维护算法对象当滑动导致分数变化时主动通过 listener 把分数抛给 ActivityActivity 只负责更新界面。这样做的好处是 Activity 和 View 之间的耦合降到最低你后续想把分数同步到通知栏、微信分享之类的只要加一个 listener 实现就行。我一般习惯让 View 在 onAttachedToWindow 里完成算法对象和 SharedPreferences 的初始化这样 View 被创建时数据就有了不会出现界面已经显示但最高分还是 0 的空窗期。源码里也是这个思路只是把初始化的位置放在构造函数里效果差不多。2.2 数据流一次滑动背后发生了什么很多人看不懂源码是因为脑子里没有一条完整的数据流。这个 2048 项目里一次手指滑动要经过 6 步手指按下屏幕onTouchEvent 收到 ACTION_DOWN记录按下坐标。手指抬起onTouchEvent 收到 ACTION_UP计算横向和纵向偏移量判断滑动方向。View 调用算法对象的 move(direction) 方法把方向传进去。算法层遍历棋盘二维数组压缩、合并、再压缩累加分数返回本次滑动是否让棋盘发生了变化。如果棋盘发生了变化算法对象随机在空位生成一个 2 或 4并检查游戏是否结束。View 调用 invalidate() 触发 onDraw 重绘把最新的棋盘状态画到屏幕上。这条链路里最容易出问题的是第 4 步和第 5 步的顺序必须先判断「棋盘有没有变」变了才生成新数字如果没变还硬生成就会出现「往左滑没反应但棋盘多了个数字」的玄学 bug。这个坑我后面专门讲。算法对象的核心数据结构也很简单// Game2048Algorithm.java 核心字段 public class Game2048Algorithm { private int[][] board; // 棋盘二维数组0 表示空格 private int score; // 当前分数 private int highScore; // 历史最高分已持久化 private boolean isGameOver; // 游戏是否结束 private boolean isWin; // 是否达成 2048 public static final int GRID_SIZE 4; // 棋盘行列数 public static final int WIN_TARGET 2048; // 胜利目标 private static final float SPAWN_2_PROB 0.9f; // 生成 2 的概率 }board 是一个 4×4 的 int 数组值 0 代表空格非 0 代表该位置上的数字。为什么不直接用 List 或者 Map因为 2048 的核心操作是「按行/按列压缩合并」二维数组配合行列遍历是最好写的而且数组访问效率高一个滑动操作要在 16 个格子里做多次遍历用数组不会有任何性能压力。GRID_SIZE 和 WIN_TARGET 被设计成常量意味着你把它改成 5 或者 6棋盘的规模就跟着扩容这也是后来做棋盘扩展最容易动的地方。源码里把「生成 2 的概率」也做成了常量这是很细节的处理答辩时可以说「随机生成时 90% 概率出 2、10% 概率出 4符合原版游戏手感」。3. 滑动合并核心算法用一次矩阵变换解决四个方向2048 最核心的玩法是滑动方块、相同数字合并。当你把代码拆开看会发现真正难的不是合并逻辑而是「怎么优雅地处理四个方向」。很多新手写法是写四个方向各写一套循环四套代码长得几乎一样还各自有一堆边界条件。这份源码的做法聪明得多只实现向左合并其他方向通过矩阵翻转、转置转换成向左。3.1 手势识别onTouchEvent 里的方向判定手势识别是自定义 View 的基本功。2048 不需要支持多点触控只需要捕获单指按下和抬起两个事件因此代码很简洁private float startX; private float startY; private static final int SLOP 50; // 滑动触发阈值单位 px Override public boolean onTouchEvent(MotionEvent event) { switch (event.getActionMasked()) { case MotionEvent.ACTION_DOWN: startX event.getX(); startY event.getY(); break; case MotionEvent.ACTION_UP: float deltaX event.getX() - startX; float deltaY event.getY() - startY; int dir -1; // 横向位移大于纵向判为左右滑动 if (Math.abs(deltaX) Math.abs(deltaY) Math.abs(deltaX) SLOP) { dir deltaX 0 ? DIR_RIGHT : DIR_LEFT; } else if (Math.abs(deltaY) SLOP) { dir deltaY 0 ? DIR_DOWN : DIR_UP; } if (dir ! -1) { boolean changed algorithm.move(dir); if (changed) { algorithm.spawnTile(); invalidate(); } } break; } return true; }这段代码的逻辑很直白手指按下时记录起点坐标抬起时计算水平和竖直方向的位移差谁的绝对位移大就判定为哪个方向的滑动。SLOP 的作用是过滤掉那些手指轻微抖动产生的「伪滑动」我把阈值设在 50px 是为了避免在窄屏设备上手指稍微偏移就触发方向切换这个值你可以按自己的手感调整一般范围在 40 到 80px 之间比较合适。这里有两个细节值得注意。第一getActionMasked() 是处理多点触控时的标准写法虽然 2048 只需要单指但用这个方法可以避免以后加双指操作时踩坑。第二方法返回 true 代表消费了触摸事件如果你返回 false事件会被交给父布局处理棋盘就没反应——很多移植过来的源码在嵌套滚动布局里手势失灵就是这个返回值写错了。3.2 合并算法压缩、合并、再压缩的三段式2048 的合并规则可以概括成三步把一行里的所有数字压到一侧、相邻相同数字合并、再次压缩填补合并产生的空位。以左滑为例一行的合并逻辑是这样写的// 只处理一行四个方向都复用这个函数 private void mergeLine(int[] line) { int[] temp new int[line.length]; int index 0; // 第一步把所有非 0 数字压缩到左侧 for (int value : line) { if (value ! 0) { temp[index] value; } } // 第二步从左到右扫相邻相同则合并 for (int i 0; i index - 1; i) { if (temp[i] temp[i 1]) { temp[i] * 2; score temp[i]; // 合并产生的分数累加 temp[i 1] 0; // 被合并的位置清空 i; // 跳过被合并的位置 } } // 第三步合并后可能又出现空位再次左压 int[] result new int[line.length]; int pos 0; for (int value : temp) { if (value ! 0) { result[pos] value; } } System.arraycopy(result, 0, line, 0, line.length); }第二步里的 i 是这段代码的关键。原版 2048 规定一次滑动每个格子只能参与一次合并所以当 2 和 2 合并成 4 之后这个新生成的 4 不能继续和后面的 4 再合并。加 i 让循环跳过被合并的位置正好实现这个规则。第一次上手写 2048 的新手最容易漏掉的是第三步。合并之后数组里会出现一个 0 的空洞比如一行原来是[2, 2, 4, 0]合并后 temp 变成[4, 0, 4, 0]如果不再次压缩直接画出来数字就不是贴边的状态下一个方向的判断也会错。所以「压缩—合并—再压缩」这三步一个都不能少。3.3 四个方向的统一切换转置与翻转的组合现在的问题来了mergeLine 只处理左滑右滑、上滑、下滑怎么办如果每个方向写一套循环代码量至少要翻三倍而且很容易在边界条件上翻车。我见过的大多数优雅解法是矩阵变换// 把四个方向的移动统一转换成“向左合并” public boolean move(int direction) { // 保存旧状态用于判断滑动后棋盘是否发生变化 int[][] before copyBoard(); switch (direction) { case DIR_LEFT: mergeAllRows(board); break; case DIR_RIGHT: reverseRows(board); // 水平翻转 mergeAllRows(board); reverseRows(board); // 翻转回来 break; case DIR_UP: transpose(board); // 行列转置 mergeAllRows(board); transpose(board); // 转置回来 break; case DIR_DOWN: transpose(board); // 行列转置 reverseRows(board); // 水平翻转 mergeAllRows(board); reverseRows(board); transpose(board); break; } return !isSameBoard(before, board); }这个做法的核心是转置和翻转两个操作。转置就是行列互换把一个纵向数组变成横向水平翻转就是把每一行的顺序反过来。以右滑为例先把每一行左右翻转变成和左滑同方向执行左合并再翻转回来效果上和右滑完全一致。上滑、下滑同理先转置把列变行再套用左合并。这种写法不是为了炫技而是实际工程里的常见解耦思路。当你只需要维护一个方向的合并逻辑时bug 出现的概率会大幅降低。答辩时这里是很加分的一个亮点你可以直接说「2048 的四方向移动本质是数组的方向变换我用矩阵转置和翻转把它统一成了一个方向的处理」。这个思路面试官也爱听比你背十个移动判定的 corner case 强得多。4. 界面渲染与交互接线把数字画到屏幕上算法层的数据是「数字内部状态」但要让人看得到还得靠 View 的绘制。这个项目的 View 层做了一件看起来很基础但值得细说的事它不是一个写了死的 4×4 方格而是根据 View 的实际宽度动态计算每个卡片的大小和位置。也就是说不管屏幕是 360dp 宽还是 500dp 宽棋盘都能等比缩放。4.1 onMeasure 与 onDraw动态计算卡片尺寸安卓自定义 View 里新手最爱踩的第一个坑就是「在 onDraw 里拿 getWidth() 返回 0」。因为这个坑的存在源码把棋盘尺寸计算放在了 onMeasure 和 onDraw 的配合里Override protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) { int widthSize MeasureSpec.getSize(widthMeasureSpec); int heightSize MeasureSpec.getSize(heightMeasureSpec); int boardSize Math.min(widthSize, heightSize); setMeasuredDimension(boardSize, boardSize); }onMeasure 里把 View 的宽高强制设成正方形两个方向上取最小值这就从根源上杜绝了棋盘被拉成矩形的问题。布局文件里不管你怎么写的父布局给的约束多大最后这个 View 都会变成宽高相等的正方形棋盘。绘制部分的核心是循环遍历二维数组按位置画圆角矩形和数字Override protected void onDraw(Canvas canvas) { super.onDraw(canvas); int boardSize getWidth(); // 正方形宽高相等 float margin 20f; // 卡片间距 float cardSize (boardSize - (GRID_SIZE 1) * margin) / GRID_SIZE; for (int row 0; row GRID_SIZE; row) { for (int col 0; col GRID_SIZE; col) { // 计算当前格子的左上角坐标 float left margin col * (cardSize margin); float top margin row * (cardSize margin); // 画卡片背景 canvas.drawRoundRect(left, top, left cardSize, top cardSize, 16f, 16f, bgPaint); // 画数字 int value algorithm.getTile(row, col); if (value ! 0) { textPaint.setTextSize(cardSize / 2.5f); textPaint.setColor(getTextColor(value)); String text String.valueOf(value); float textWidth textPaint.measureText(text); float baseline top cardSize / 2f (textPaint.getFontMetrics().descent - textPaint.getFontMetrics().ascent) / 2f; canvas.drawText(text, left (cardSize - textWidth) / 2f, baseline, textPaint); } } } }这一段有四个参数值得你答辩时讲清楚。margin 是卡片间的留白16f 是圆角矩形的圆角半径cardSize / 2.5f 是数字字号与卡片大小的比例baseline 的计算是为了让文字在卡片里垂直居中。文字居中是整段代码里最容易写歪的地方如果你直接用 top cardSize / 2f 作为 drawText 的 y 坐标文字会比视觉居中偏上因为 drawText 的 y 参数是文字基线而不是文字中心。源码里的 FontMetrics 计算就是用来修正这个偏移的。4.2 新数字生成与游戏结束判断每完成一次有效的滑动棋盘后就需要有一个随机的空位出现新数字。spawnTile 的实现逻辑是收集所有空位随机选一个再按概率决定生成 2 还是 4// 在空位随机生成新数字 public void spawnTile() { Listint[] emptyCells new ArrayList(); for (int i 0; i GRID_SIZE; i) { for (int j 0; j GRID_SIZE; j) { if (board[i][j] 0) { emptyCells.add(new int[]{i, j}); } } } if (emptyCells.isEmpty()) { return; } int[] cell emptyCells.get(random.nextInt(emptyCells.size())); board[cell[0]][cell[1]] random.nextFloat() 0.9f ? 2 : 4; }这里有个实际开发里才会注意到的细节要先把所有空位收集到 List 里再随机取而不是在一个循环里「随机挑中某个空位就生成」。后者的问题是棋盘中空格很多时某些位置的选中概率并不均匀玩起来会感觉新数字总是出在某个方向手感不对。收集再随机是标准做法。游戏结束的判断也是算法层的一个独立方法public boolean isGameOver() { for (int i 0; i GRID_SIZE; i) { for (int j 0; j GRID_SIZE; j) { if (board[i][j] 0) { return false; // 还有空格游戏继续 } if (j 1 GRID_SIZE board[i][j] board[i][j 1]) { return false; // 横向还能合并 } if (i 1 GRID_SIZE board[i][j] board[i 1][j]) { return false; // 纵向还能合并 } } } return true; }游戏结束的唯一条件就是「没有任何空格、且任何相邻的两个数字都不相等」。这个判断是穷举式的没有捷径。需要注意的调用时机是必须在一次有效的滑动并生成新数字之后调用如果在滑动之前调用会把「滑动后产生的新空格」漏掉导致明明还能走一步就提前弹了 Game Over。这个顺序问题在 5.3 里会详细展开。4.3 分数与最高分的界面同步SharedPreferences 的正确姿势分数在算法层累加但界面的刷新要回到 UI 层。源码里的做法是前面 2.1 提到的接口回调。最高分还需要持久化保存否则每次杀掉进程重开就会清零// 保存最高分 SharedPreferences prefs getSharedPreferences(2048_prefs, MODE_PRIVATE); SharedPreferences.Editor editor prefs.edit(); editor.putInt(high_score, highScore); editor.commit(); // 立即写入文件commit() 和 apply() 的区别是大作业答辩里踩坑最多的一个点commit 是同步写入磁盘返回 true 或 falseapply 是异步写入函数立即返回。对于最高分这种非频繁写入的数据我建议用 commit虽然同步写文件有一点性能消耗但保证数据不丢。apply 适合高频的、掉了也无所谓的临时数据。很多下载的源码里只写了 edit().putInt() 没写 commit/apply等于完全没保存重启必丢。5. 避坑与常见问题安卓大作业最容易翻车的五个点把这份源码跑起来不难但如果你改代码改出下面这几个问题也不要慌。我把最常见的翻车场景按「现象 → 原因 → 解决」的格式写出来都是我实际带项目时见过的高频问题。5.1 棋盘被拉伸变成长方形现象App 跑起来后棋盘不是正方形卡片宽高不一致数字的位置偏了。原因自定义 View 没有在 onMeasure 阶段约束宽高比例布局文件里给的是 match_parent屏幕宽度和高度不一样时就被拉伸了。解决在自定义 View 里重写 onMeasure强制设为正方形用两个方向的较小值作为边长Override protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) { int widthSize MeasureSpec.getSize(widthMeasureSpec); int heightSize MeasureSpec.getSize(heightMeasureSpec); setMeasuredDimension( Math.min(widthSize, heightSize), Math.min(widthSize, heightSize)); }顺便在 AndroidManifest.xml 的 MainActivity 上加上android:screenOrientationportrait锁死竖屏防止旋转屏幕时棋盘重新布局又出现宽高不一致的问题。5.2 往已经靠左的棋盘左滑却多出了新数字现象棋盘数字已经全部贴左再次向左滑动棋盘的格子没有变化但随机生成了一个新的 2 或 4。原因move 方法没有返回「棋盘是否发生了变化」View 层不管滑动有没有效果都会调用 spawnTile相当于一次无效滑动也喂了一个新数字。连续滑动几次棋盘会多出好几个不该有的数字。解决move 方法里先备份棋盘状态合并完成后对比新旧数组只要有变化才返回 trueView 层收到 true 才执行 spawnTile// View 层 boolean changed algorithm.move(dir); if (changed) { algorithm.spawnTile(); invalidate(); }这个标志位不只解决新数字乱出还避免无效滑动触发重绘省掉无意义的性能开销。5.3 棋盘还有空位却弹了 Game Over现象棋盘上明显还有两个空格滑动一下数字还能移动但对话框提前弹出「游戏结束」。原因isGameOver 的调用时机不对。如果你在滑动之前检查状态然后把「无空位」当成游戏结束的充分条件就会漏掉一种情况——棋盘没有空位但还有相邻相同数字可以合并。只要还能合并游戏就没结束。解决isGameOver 的判断条件是「无空格 无相邻相同」两个条件同时满足才返回 true。并且调用顺序必须是「滑动 → 生成新数字 → 判断是否结束」不能在滑动前判断。if (changed) { algorithm.spawnTile(); if (algorithm.isGameOver()) { // 弹出结束提示 } }5.4 最高分每次重启 App 都回到 0现象玩了一把最高分显示了 1024把 App 从后台划掉重新打开最高分变成 0。原因最高分只存在内存变量里没做持久化。或者 SharedPreferences 调用了 edit().putInt() 之后没有 commit/apply数据根本没写入文件。解决用 SharedPreferences 时务必把提交方法带上。大作业场景下用 commit 同步写入代码直观调试时也容易确认值是否真的落盘了。读取时放在 onCreate 或 View 初始化阶段SharedPreferences prefs getSharedPreferences(2048_prefs, MODE_PRIVATE); int highScore prefs.getInt(high_score, 0);5.5 真机运行闪退日志报 NullPointerException现象模拟器上一切正常换到真机上打开就闪退Logcat 里报空指针定位到 View 绘制相关代码。原因常见的两个来源。一个是 View 在布局完成前onCreate 阶段调用了 getWidth()/getHeight()返回值是 0拿 0 去做除法直接崩了另一个是屏幕密度不同导致某些像素计算溢出。解决所有依赖 View 宽高的计算移到 onSizeChanged 或 onDraw 里不要在构造器、onCreate、onResume 里做。onSizeChanged 在 View 尺寸变化时必定回调在这里把卡片大小、字体大小算好存成成员变量onDraw 里直接用。5.6 导入项目后 Gradle 同步失败现象用你本机的 Android Studio 打开源码工程Gradle 一直转圈最后报错让你升级或降级插件版本。原因这可能是整个安卓环境里最玄学的部分。Android Studio 的版本、AGPAndroid Gradle Plugin版本、Gradle 版本、JDK 版本四者必须互相匹配网上下的源码很可能用的是别人机器上的版本组合和你本机不兼容。这跟代码逻辑没关系纯粹是环境问题。解决不要在这个问题上死磕最省事的办法是新建一个空项目用你本机验证过能跑的 Gradle 配置然后把源码里的 java 目录、res 目录、AndroidManifest.xml 复制过去再按你自己的包名调整一下引用关系。这个操作 10 分钟能完成比自己研究版本矩阵快得多。这也是我在多个项目里反复用的血泪经验。6. 进阶动画回弹、分数持久化与棋盘扩展到这里一个能玩的 2048 已经完整了。但如果你想让作品更有记忆点或者在答辩时多展示一项能力可以从下面三个方向挑一个做升级。第一个方向是移动动画。原版 2048 的方块滑动是有过渡效果的而静态绘制只是瞬间切换位置。要加动画可以在移动发生时记录每个方块的起始位置和目标位置然后用 ValueAnimator 在 100 到 150 毫秒内做插值逐步更新绘制偏移量ValueAnimator animator ValueAnimator.ofFloat(0f, 1f); animator.setDuration(120); animator.setInterpolator(new DecelerateInterpolator()); animator.addUpdateListener(animation - { // offset 从 0 渐变到 1绘制时利用它计算中间位置 currentOffset (float) animation.getAnimatedValue(); invalidate(); // 每帧刷新 }); animator.start();这个实现的关键是要在算法层额外记录「同一块数字移动前和移动后的坐标」一般用一个 PositionChange 列表保存。动画的本质是把老的坐标变成新的坐标的中间帧而不是重算一遍游戏逻辑。120 毫秒是常见手感太短显得生硬太长会拖慢连续滑动的响应。第二个方向是 5×5 或 6×6 棋盘扩展。源码里已经留好了口子GRID_SIZE 就是棋盘大小WIN_TARGET 就是胜利目标。改成 5×5 时把 GRID_SIZE 从 4 改成 5初始生成的新数字数量也可以从 2 个加为 3 个否则 5×5 的棋盘开局太空。界面侧的间距 margin 需要适当缩小因为格子多了卡片变小20px 的间距在 5×5 下会显得太挤。改完这三个地方就成算法层不需要动。这里要注意胜利目标改成 2048 在 5×5 下反而太容易达成建议同步改成 4096 或 8192才符合大棋盘的游戏节奏。第三个方向是把「Game Over 后重新开局」做得更完整。很多大作业只做了 begin 按钮没有做结束后的清理。你可以加一个确认对话框点击「再来一局」时把算法对象的棋盘数组全部清零、分数归零、重新生成两个初始数字、调用 invalidate()。这个功能逻辑很短但演示时给老师的观感是「这个项目有完整的用户体验闭环」。我自己第一次写 2048 时就把 5.3 里的判断顺序写反了导致棋盘明明还能走却反复弹结束框排错排了两个小时最后才发现只是顺序问题。从那以后我每次拿到安卓源码都会先强制走一遍「数据流 → 绘制 → 状态检查」这个链路把每个模块的调用顺序理清楚再改代码这个习惯帮我避开了至少一半的隐性 bug。希望帮到你。本文还有配套的精品资源点击获取 Android Studio 2048小游戏完整源码：结构、算法与避坑指南
简介基于Android Studio实现的2048小游戏完整项目是一份定位明确的安卓大作业/课程设计源码面向正在学习安卓开发或需要完成期末项目的初学者提供了可下载后快速运行的参考范例。压缩包共141个文件整体仅约394KB结构紧凑其中50个xml文件负责界面布局、菜单与颜色等资源配置30个webp文件存放数字方块和背景图片21个java文件实现棋盘生成、滑动监听、数字合并、计分及胜负判断等核心逻辑gradle、properties及jar等文件共同支撑项目构建与依赖配置目录划分清楚便于按模块查阅和修改。当前已有269人学习下载适合作为安卓入门练手素材。代码注释详实关键算法和事件处理均配有说明新手也能看懂每一步实现思路作为个人手打并获导师认可的98分项目下载后简单部署即可运行对需要期末大作业或课程设计高分参考的同学有直接借鉴价值。1. 为什么 Android Studio 2048 小游戏项目是大作业里的最优解如果你正在为安卓大作业发愁网上搜「android studio 2048小游戏代码」的结论大概率是同一个这个项目代码量不大、演示效果直观、答辩时能讲的东西又多从手势识别到自定义 View 再到状态管理一个 2048 能把安卓课的核心考点全串起来。但真去下载你会发现能直接跑完的完整工程其实很少——多数是贴出来的半截代码Activity 缺这少那算法类更是黑匣子。这份基于 Android Studio 的 2048 小游戏源代码是一个完整可运行的安卓工程从 Gradle 配置、MainActivity 到核心算法类全部齐整适合期末大作业、课程设计想拿去做面试作品集也不掉价。下面按「结构—算法—渲染—踩坑—进阶」的顺序拆读完你能照着复现也能给它改出自己的功能。2. 源码结构拆解Activity、View 与算法类各管一摊拿到一份源代码我建议你先别急着点 Run先把目录结构打开看一遍。这个 2048 小游戏项目的代码量不算大但分层做得比较清楚核心就三个 Java 类加一个布局文件。先把它们的分工讲明白后面改起来你才知道动哪里。2.1 工程目录这几个文件才是你答辩时要讲的重点下面这张表是这份源码里最值得关注的文件也是你答辩时能展开讲的核心文件职责答辩讲解要点MainActivity.java应用入口设置全屏、加载布局、初始化 View、接收分数回调Activity 生命周期、setContentViewGame2048View.java自定义 View负责手势监听、棋盘绘制、动画刷新onTouchEvent、onMeasure、onDrawGame2048Algorithm.java核心算法类持有棋盘二维数组处理合并、生成、游戏状态二维数组操作、状态机设计activity_main.xml页面布局放置 TextView 与自定义 View布局层级与自定义控件引入很多网上下载的同类源码把算法逻辑写在 View 内部表面上省事实际上答辩时很难把「逻辑」和「显示」分开讲。这份源码把算法单独抽成一个类是更接近真实项目的写法。你在讲解时可以直接说棋盘状态是数据层View 只负责把数据画出来手势识别是交互层三层各管一摊互相解耦。这句话一说出口比背十页概念都有说服力。MainActivity 的初始化部分大致是这样的public class MainActivity extends AppCompatActivity { private Game2048View gameView; private TextView tvScore; private TextView tvHighScore; Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); // 隐藏系统状态栏让游戏区域完整铺满屏幕 getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN, WindowManager.LayoutParams.FLAG_FULLSCREEN); setContentView(R.layout.activity_main); gameView findViewById(R.id.game_view); tvScore findViewById(R.id.tv_score); tvHighScore findViewById(R.id.tv_high_score); // 分数回调接口分数变化时由 View 层向外抛出 gameView.setOnScoreChangedListener(new Game2048View.OnScoreChangedListener() { Override public void onScoreChanged(int score, int highScore) { tvScore.setText(分数 score); tvHighScore.setText(最高 highScore); } }); } }这里的关键点是用接口回调而不是让 Activity 去轮询分数。自定义 View 内部维护算法对象当滑动导致分数变化时主动通过 listener 把分数抛给 ActivityActivity 只负责更新界面。这样做的好处是 Activity 和 View 之间的耦合降到最低你后续想把分数同步到通知栏、微信分享之类的只要加一个 listener 实现就行。我一般习惯让 View 在 onAttachedToWindow 里完成算法对象和 SharedPreferences 的初始化这样 View 被创建时数据就有了不会出现界面已经显示但最高分还是 0 的空窗期。源码里也是这个思路只是把初始化的位置放在构造函数里效果差不多。2.2 数据流一次滑动背后发生了什么很多人看不懂源码是因为脑子里没有一条完整的数据流。这个 2048 项目里一次手指滑动要经过 6 步手指按下屏幕onTouchEvent 收到 ACTION_DOWN记录按下坐标。手指抬起onTouchEvent 收到 ACTION_UP计算横向和纵向偏移量判断滑动方向。View 调用算法对象的 move(direction) 方法把方向传进去。算法层遍历棋盘二维数组压缩、合并、再压缩累加分数返回本次滑动是否让棋盘发生了变化。如果棋盘发生了变化算法对象随机在空位生成一个 2 或 4并检查游戏是否结束。View 调用 invalidate() 触发 onDraw 重绘把最新的棋盘状态画到屏幕上。这条链路里最容易出问题的是第 4 步和第 5 步的顺序必须先判断「棋盘有没有变」变了才生成新数字如果没变还硬生成就会出现「往左滑没反应但棋盘多了个数字」的玄学 bug。这个坑我后面专门讲。算法对象的核心数据结构也很简单// Game2048Algorithm.java 核心字段 public class Game2048Algorithm { private int[][] board; // 棋盘二维数组0 表示空格 private int score; // 当前分数 private int highScore; // 历史最高分已持久化 private boolean isGameOver; // 游戏是否结束 private boolean isWin; // 是否达成 2048 public static final int GRID_SIZE 4; // 棋盘行列数 public static final int WIN_TARGET 2048; // 胜利目标 private static final float SPAWN_2_PROB 0.9f; // 生成 2 的概率 }board 是一个 4×4 的 int 数组值 0 代表空格非 0 代表该位置上的数字。为什么不直接用 List 或者 Map因为 2048 的核心操作是「按行/按列压缩合并」二维数组配合行列遍历是最好写的而且数组访问效率高一个滑动操作要在 16 个格子里做多次遍历用数组不会有任何性能压力。GRID_SIZE 和 WIN_TARGET 被设计成常量意味着你把它改成 5 或者 6棋盘的规模就跟着扩容这也是后来做棋盘扩展最容易动的地方。源码里把「生成 2 的概率」也做成了常量这是很细节的处理答辩时可以说「随机生成时 90% 概率出 2、10% 概率出 4符合原版游戏手感」。3. 滑动合并核心算法用一次矩阵变换解决四个方向2048 最核心的玩法是滑动方块、相同数字合并。当你把代码拆开看会发现真正难的不是合并逻辑而是「怎么优雅地处理四个方向」。很多新手写法是写四个方向各写一套循环四套代码长得几乎一样还各自有一堆边界条件。这份源码的做法聪明得多只实现向左合并其他方向通过矩阵翻转、转置转换成向左。3.1 手势识别onTouchEvent 里的方向判定手势识别是自定义 View 的基本功。2048 不需要支持多点触控只需要捕获单指按下和抬起两个事件因此代码很简洁private float startX; private float startY; private static final int SLOP 50; // 滑动触发阈值单位 px Override public boolean onTouchEvent(MotionEvent event) { switch (event.getActionMasked()) { case MotionEvent.ACTION_DOWN: startX event.getX(); startY event.getY(); break; case MotionEvent.ACTION_UP: float deltaX event.getX() - startX; float deltaY event.getY() - startY; int dir -1; // 横向位移大于纵向判为左右滑动 if (Math.abs(deltaX) Math.abs(deltaY) Math.abs(deltaX) SLOP) { dir deltaX 0 ? DIR_RIGHT : DIR_LEFT; } else if (Math.abs(deltaY) SLOP) { dir deltaY 0 ? DIR_DOWN : DIR_UP; } if (dir ! -1) { boolean changed algorithm.move(dir); if (changed) { algorithm.spawnTile(); invalidate(); } } break; } return true; }这段代码的逻辑很直白手指按下时记录起点坐标抬起时计算水平和竖直方向的位移差谁的绝对位移大就判定为哪个方向的滑动。SLOP 的作用是过滤掉那些手指轻微抖动产生的「伪滑动」我把阈值设在 50px 是为了避免在窄屏设备上手指稍微偏移就触发方向切换这个值你可以按自己的手感调整一般范围在 40 到 80px 之间比较合适。这里有两个细节值得注意。第一getActionMasked() 是处理多点触控时的标准写法虽然 2048 只需要单指但用这个方法可以避免以后加双指操作时踩坑。第二方法返回 true 代表消费了触摸事件如果你返回 false事件会被交给父布局处理棋盘就没反应——很多移植过来的源码在嵌套滚动布局里手势失灵就是这个返回值写错了。3.2 合并算法压缩、合并、再压缩的三段式2048 的合并规则可以概括成三步把一行里的所有数字压到一侧、相邻相同数字合并、再次压缩填补合并产生的空位。以左滑为例一行的合并逻辑是这样写的// 只处理一行四个方向都复用这个函数 private void mergeLine(int[] line) { int[] temp new int[line.length]; int index 0; // 第一步把所有非 0 数字压缩到左侧 for (int value : line) { if (value ! 0) { temp[index] value; } } // 第二步从左到右扫相邻相同则合并 for (int i 0; i index - 1; i) { if (temp[i] temp[i 1]) { temp[i] * 2; score temp[i]; // 合并产生的分数累加 temp[i 1] 0; // 被合并的位置清空 i; // 跳过被合并的位置 } } // 第三步合并后可能又出现空位再次左压 int[] result new int[line.length]; int pos 0; for (int value : temp) { if (value ! 0) { result[pos] value; } } System.arraycopy(result, 0, line, 0, line.length); }第二步里的 i 是这段代码的关键。原版 2048 规定一次滑动每个格子只能参与一次合并所以当 2 和 2 合并成 4 之后这个新生成的 4 不能继续和后面的 4 再合并。加 i 让循环跳过被合并的位置正好实现这个规则。第一次上手写 2048 的新手最容易漏掉的是第三步。合并之后数组里会出现一个 0 的空洞比如一行原来是[2, 2, 4, 0]合并后 temp 变成[4, 0, 4, 0]如果不再次压缩直接画出来数字就不是贴边的状态下一个方向的判断也会错。所以「压缩—合并—再压缩」这三步一个都不能少。3.3 四个方向的统一切换转置与翻转的组合现在的问题来了mergeLine 只处理左滑右滑、上滑、下滑怎么办如果每个方向写一套循环代码量至少要翻三倍而且很容易在边界条件上翻车。我见过的大多数优雅解法是矩阵变换// 把四个方向的移动统一转换成“向左合并” public boolean move(int direction) { // 保存旧状态用于判断滑动后棋盘是否发生变化 int[][] before copyBoard(); switch (direction) { case DIR_LEFT: mergeAllRows(board); break; case DIR_RIGHT: reverseRows(board); // 水平翻转 mergeAllRows(board); reverseRows(board); // 翻转回来 break; case DIR_UP: transpose(board); // 行列转置 mergeAllRows(board); transpose(board); // 转置回来 break; case DIR_DOWN: transpose(board); // 行列转置 reverseRows(board); // 水平翻转 mergeAllRows(board); reverseRows(board); transpose(board); break; } return !isSameBoard(before, board); }这个做法的核心是转置和翻转两个操作。转置就是行列互换把一个纵向数组变成横向水平翻转就是把每一行的顺序反过来。以右滑为例先把每一行左右翻转变成和左滑同方向执行左合并再翻转回来效果上和右滑完全一致。上滑、下滑同理先转置把列变行再套用左合并。这种写法不是为了炫技而是实际工程里的常见解耦思路。当你只需要维护一个方向的合并逻辑时bug 出现的概率会大幅降低。答辩时这里是很加分的一个亮点你可以直接说「2048 的四方向移动本质是数组的方向变换我用矩阵转置和翻转把它统一成了一个方向的处理」。这个思路面试官也爱听比你背十个移动判定的 corner case 强得多。4. 界面渲染与交互接线把数字画到屏幕上算法层的数据是「数字内部状态」但要让人看得到还得靠 View 的绘制。这个项目的 View 层做了一件看起来很基础但值得细说的事它不是一个写了死的 4×4 方格而是根据 View 的实际宽度动态计算每个卡片的大小和位置。也就是说不管屏幕是 360dp 宽还是 500dp 宽棋盘都能等比缩放。4.1 onMeasure 与 onDraw动态计算卡片尺寸安卓自定义 View 里新手最爱踩的第一个坑就是「在 onDraw 里拿 getWidth() 返回 0」。因为这个坑的存在源码把棋盘尺寸计算放在了 onMeasure 和 onDraw 的配合里Override protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) { int widthSize MeasureSpec.getSize(widthMeasureSpec); int heightSize MeasureSpec.getSize(heightMeasureSpec); int boardSize Math.min(widthSize, heightSize); setMeasuredDimension(boardSize, boardSize); }onMeasure 里把 View 的宽高强制设成正方形两个方向上取最小值这就从根源上杜绝了棋盘被拉成矩形的问题。布局文件里不管你怎么写的父布局给的约束多大最后这个 View 都会变成宽高相等的正方形棋盘。绘制部分的核心是循环遍历二维数组按位置画圆角矩形和数字Override protected void onDraw(Canvas canvas) { super.onDraw(canvas); int boardSize getWidth(); // 正方形宽高相等 float margin 20f; // 卡片间距 float cardSize (boardSize - (GRID_SIZE 1) * margin) / GRID_SIZE; for (int row 0; row GRID_SIZE; row) { for (int col 0; col GRID_SIZE; col) { // 计算当前格子的左上角坐标 float left margin col * (cardSize margin); float top margin row * (cardSize margin); // 画卡片背景 canvas.drawRoundRect(left, top, left cardSize, top cardSize, 16f, 16f, bgPaint); // 画数字 int value algorithm.getTile(row, col); if (value ! 0) { textPaint.setTextSize(cardSize / 2.5f); textPaint.setColor(getTextColor(value)); String text String.valueOf(value); float textWidth textPaint.measureText(text); float baseline top cardSize / 2f (textPaint.getFontMetrics().descent - textPaint.getFontMetrics().ascent) / 2f; canvas.drawText(text, left (cardSize - textWidth) / 2f, baseline, textPaint); } } } }这一段有四个参数值得你答辩时讲清楚。margin 是卡片间的留白16f 是圆角矩形的圆角半径cardSize / 2.5f 是数字字号与卡片大小的比例baseline 的计算是为了让文字在卡片里垂直居中。文字居中是整段代码里最容易写歪的地方如果你直接用 top cardSize / 2f 作为 drawText 的 y 坐标文字会比视觉居中偏上因为 drawText 的 y 参数是文字基线而不是文字中心。源码里的 FontMetrics 计算就是用来修正这个偏移的。4.2 新数字生成与游戏结束判断每完成一次有效的滑动棋盘后就需要有一个随机的空位出现新数字。spawnTile 的实现逻辑是收集所有空位随机选一个再按概率决定生成 2 还是 4// 在空位随机生成新数字 public void spawnTile() { Listint[] emptyCells new ArrayList(); for (int i 0; i GRID_SIZE; i) { for (int j 0; j GRID_SIZE; j) { if (board[i][j] 0) { emptyCells.add(new int[]{i, j}); } } } if (emptyCells.isEmpty()) { return; } int[] cell emptyCells.get(random.nextInt(emptyCells.size())); board[cell[0]][cell[1]] random.nextFloat() 0.9f ? 2 : 4; }这里有个实际开发里才会注意到的细节要先把所有空位收集到 List 里再随机取而不是在一个循环里「随机挑中某个空位就生成」。后者的问题是棋盘中空格很多时某些位置的选中概率并不均匀玩起来会感觉新数字总是出在某个方向手感不对。收集再随机是标准做法。游戏结束的判断也是算法层的一个独立方法public boolean isGameOver() { for (int i 0; i GRID_SIZE; i) { for (int j 0; j GRID_SIZE; j) { if (board[i][j] 0) { return false; // 还有空格游戏继续 } if (j 1 GRID_SIZE board[i][j] board[i][j 1]) { return false; // 横向还能合并 } if (i 1 GRID_SIZE board[i][j] board[i 1][j]) { return false; // 纵向还能合并 } } } return true; }游戏结束的唯一条件就是「没有任何空格、且任何相邻的两个数字都不相等」。这个判断是穷举式的没有捷径。需要注意的调用时机是必须在一次有效的滑动并生成新数字之后调用如果在滑动之前调用会把「滑动后产生的新空格」漏掉导致明明还能走一步就提前弹了 Game Over。这个顺序问题在 5.3 里会详细展开。4.3 分数与最高分的界面同步SharedPreferences 的正确姿势分数在算法层累加但界面的刷新要回到 UI 层。源码里的做法是前面 2.1 提到的接口回调。最高分还需要持久化保存否则每次杀掉进程重开就会清零// 保存最高分 SharedPreferences prefs getSharedPreferences(2048_prefs, MODE_PRIVATE); SharedPreferences.Editor editor prefs.edit(); editor.putInt(high_score, highScore); editor.commit(); // 立即写入文件commit() 和 apply() 的区别是大作业答辩里踩坑最多的一个点commit 是同步写入磁盘返回 true 或 falseapply 是异步写入函数立即返回。对于最高分这种非频繁写入的数据我建议用 commit虽然同步写文件有一点性能消耗但保证数据不丢。apply 适合高频的、掉了也无所谓的临时数据。很多下载的源码里只写了 edit().putInt() 没写 commit/apply等于完全没保存重启必丢。5. 避坑与常见问题安卓大作业最容易翻车的五个点把这份源码跑起来不难但如果你改代码改出下面这几个问题也不要慌。我把最常见的翻车场景按「现象 → 原因 → 解决」的格式写出来都是我实际带项目时见过的高频问题。5.1 棋盘被拉伸变成长方形现象App 跑起来后棋盘不是正方形卡片宽高不一致数字的位置偏了。原因自定义 View 没有在 onMeasure 阶段约束宽高比例布局文件里给的是 match_parent屏幕宽度和高度不一样时就被拉伸了。解决在自定义 View 里重写 onMeasure强制设为正方形用两个方向的较小值作为边长Override protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) { int widthSize MeasureSpec.getSize(widthMeasureSpec); int heightSize MeasureSpec.getSize(heightMeasureSpec); setMeasuredDimension( Math.min(widthSize, heightSize), Math.min(widthSize, heightSize)); }顺便在 AndroidManifest.xml 的 MainActivity 上加上android:screenOrientationportrait锁死竖屏防止旋转屏幕时棋盘重新布局又出现宽高不一致的问题。5.2 往已经靠左的棋盘左滑却多出了新数字现象棋盘数字已经全部贴左再次向左滑动棋盘的格子没有变化但随机生成了一个新的 2 或 4。原因move 方法没有返回「棋盘是否发生了变化」View 层不管滑动有没有效果都会调用 spawnTile相当于一次无效滑动也喂了一个新数字。连续滑动几次棋盘会多出好几个不该有的数字。解决move 方法里先备份棋盘状态合并完成后对比新旧数组只要有变化才返回 trueView 层收到 true 才执行 spawnTile// View 层 boolean changed algorithm.move(dir); if (changed) { algorithm.spawnTile(); invalidate(); }这个标志位不只解决新数字乱出还避免无效滑动触发重绘省掉无意义的性能开销。5.3 棋盘还有空位却弹了 Game Over现象棋盘上明显还有两个空格滑动一下数字还能移动但对话框提前弹出「游戏结束」。原因isGameOver 的调用时机不对。如果你在滑动之前检查状态然后把「无空位」当成游戏结束的充分条件就会漏掉一种情况——棋盘没有空位但还有相邻相同数字可以合并。只要还能合并游戏就没结束。解决isGameOver 的判断条件是「无空格 无相邻相同」两个条件同时满足才返回 true。并且调用顺序必须是「滑动 → 生成新数字 → 判断是否结束」不能在滑动前判断。if (changed) { algorithm.spawnTile(); if (algorithm.isGameOver()) { // 弹出结束提示 } }5.4 最高分每次重启 App 都回到 0现象玩了一把最高分显示了 1024把 App 从后台划掉重新打开最高分变成 0。原因最高分只存在内存变量里没做持久化。或者 SharedPreferences 调用了 edit().putInt() 之后没有 commit/apply数据根本没写入文件。解决用 SharedPreferences 时务必把提交方法带上。大作业场景下用 commit 同步写入代码直观调试时也容易确认值是否真的落盘了。读取时放在 onCreate 或 View 初始化阶段SharedPreferences prefs getSharedPreferences(2048_prefs, MODE_PRIVATE); int highScore prefs.getInt(high_score, 0);5.5 真机运行闪退日志报 NullPointerException现象模拟器上一切正常换到真机上打开就闪退Logcat 里报空指针定位到 View 绘制相关代码。原因常见的两个来源。一个是 View 在布局完成前onCreate 阶段调用了 getWidth()/getHeight()返回值是 0拿 0 去做除法直接崩了另一个是屏幕密度不同导致某些像素计算溢出。解决所有依赖 View 宽高的计算移到 onSizeChanged 或 onDraw 里不要在构造器、onCreate、onResume 里做。onSizeChanged 在 View 尺寸变化时必定回调在这里把卡片大小、字体大小算好存成成员变量onDraw 里直接用。5.6 导入项目后 Gradle 同步失败现象用你本机的 Android Studio 打开源码工程Gradle 一直转圈最后报错让你升级或降级插件版本。原因这可能是整个安卓环境里最玄学的部分。Android Studio 的版本、AGPAndroid Gradle Plugin版本、Gradle 版本、JDK 版本四者必须互相匹配网上下的源码很可能用的是别人机器上的版本组合和你本机不兼容。这跟代码逻辑没关系纯粹是环境问题。解决不要在这个问题上死磕最省事的办法是新建一个空项目用你本机验证过能跑的 Gradle 配置然后把源码里的 java 目录、res 目录、AndroidManifest.xml 复制过去再按你自己的包名调整一下引用关系。这个操作 10 分钟能完成比自己研究版本矩阵快得多。这也是我在多个项目里反复用的血泪经验。6. 进阶动画回弹、分数持久化与棋盘扩展到这里一个能玩的 2048 已经完整了。但如果你想让作品更有记忆点或者在答辩时多展示一项能力可以从下面三个方向挑一个做升级。第一个方向是移动动画。原版 2048 的方块滑动是有过渡效果的而静态绘制只是瞬间切换位置。要加动画可以在移动发生时记录每个方块的起始位置和目标位置然后用 ValueAnimator 在 100 到 150 毫秒内做插值逐步更新绘制偏移量ValueAnimator animator ValueAnimator.ofFloat(0f, 1f); animator.setDuration(120); animator.setInterpolator(new DecelerateInterpolator()); animator.addUpdateListener(animation - { // offset 从 0 渐变到 1绘制时利用它计算中间位置 currentOffset (float) animation.getAnimatedValue(); invalidate(); // 每帧刷新 }); animator.start();这个实现的关键是要在算法层额外记录「同一块数字移动前和移动后的坐标」一般用一个 PositionChange 列表保存。动画的本质是把老的坐标变成新的坐标的中间帧而不是重算一遍游戏逻辑。120 毫秒是常见手感太短显得生硬太长会拖慢连续滑动的响应。第二个方向是 5×5 或 6×6 棋盘扩展。源码里已经留好了口子GRID_SIZE 就是棋盘大小WIN_TARGET 就是胜利目标。改成 5×5 时把 GRID_SIZE 从 4 改成 5初始生成的新数字数量也可以从 2 个加为 3 个否则 5×5 的棋盘开局太空。界面侧的间距 margin 需要适当缩小因为格子多了卡片变小20px 的间距在 5×5 下会显得太挤。改完这三个地方就成算法层不需要动。这里要注意胜利目标改成 2048 在 5×5 下反而太容易达成建议同步改成 4096 或 8192才符合大棋盘的游戏节奏。第三个方向是把「Game Over 后重新开局」做得更完整。很多大作业只做了 begin 按钮没有做结束后的清理。你可以加一个确认对话框点击「再来一局」时把算法对象的棋盘数组全部清零、分数归零、重新生成两个初始数字、调用 invalidate()。这个功能逻辑很短但演示时给老师的观感是「这个项目有完整的用户体验闭环」。我自己第一次写 2048 时就把 5.3 里的判断顺序写反了导致棋盘明明还能走却反复弹结束框排错排了两个小时最后才发现只是顺序问题。从那以后我每次拿到安卓源码都会先强制走一遍「数据流 → 绘制 → 状态检查」这个链路把每个模块的调用顺序理清楚再改代码这个习惯帮我避开了至少一半的隐性 bug。希望帮到你。本文还有配套的精品资源点击获取