企业官网建设流程全解析

简介：面向计算机专业毕业生与Android入门学习者的毕业论文参考文档，围绕基于Android平台的2048小游戏设计与实现展开，可用于选题借鉴、论文结构梳理与项目开发思路参考。压缩包内仅含1个doc文件，大小约619KB，正文按毕业设计规范组织，涵盖摘要、背景意义、开发技术介绍、需求分析、可行性分析、功能分析与业务流程分析，并延伸至数据库设计、ER图、数据字典、数据流图、详细设计、系统截图、测试、总结、致谢及参考文献等模块。已有223人学习，适合需要了解安卓小游戏项目论文写法、章节安排与答辩材料组织方式的读者。内容以2048游戏为案例，涉及界面布局、游戏算法、数据存储与功能测试等要点，可帮助读者快速把握从需求分析到系统实现的完整论述框架，并对照检查自身论文的模块完整性与写作规范。

1. 一份 Eclipse 时代的 Android 2048 毕设包：它到底能交付什么

每年选题季，计算机毕业论文里被翻出来最多的一类，就是带完整源码的小游戏毕设。这份资源的题目是「基于 Android 的 2048 游戏的设计与实现」，交付物很实在：一份按「概述—可行性分析—需求分析—总体设计与详细设计—软件实现—软件测试—结论」七章排布的完整论文，配一套 Eclipse + ADT 时代的 Android 工程源码。它不是教你从零学 Android，而是把「一个能装到手机上滑动合并方块的 App」和「一套能过答辩的文字材料」一次性摆到你面前。适合三类人：赶毕设节点需要可运行参照物的学生、想看清 2048 这类网格游戏最朴素实现路径的入门开发者、以及需要给课程设计找模板的助教型读者。坑也很明确——2016 年的工程放到今天的机器上，第一条编译错误就能劝退一半人。

2. 把 JDK、SDK、ADT 三件套对齐：老工程在新机器上的第一次编译

这套工程的技术栈是写死在论文里的：Eclipse 作为 IDE，Android SDK 提供平台与工具链，ADT 作为 Eclipse 插件把 Android 工程模板、DDMS、AVD 管理器挂进菜单，构建走的是 Ant 而不是 Gradle。你不需要认同这个选择，但你必须尊重它——把 Gradle 工程的经验套过来，会在「为什么没有 build.gradle」这一步卡住半天。真正要解决的是三件事：JDK 与 Eclipse 的绑定关系、SDK 目录里到底需要哪几个子目录、以及导入后必须手改的工程属性。

2.1 版本矩阵：为什么老工程在新 JDK 上第一条就红

最常见的翻车不是代码错，是 Eclipse 根本没启动起来，弹窗写着「Java was started but returned exit code=13」。原因很朴素：Eclipse 启动时先找一个 JRE，它按 PATH 顺序摸，摸到的是位数不匹配或者版本过高的那个。2016 年前后的 ADT 插件对 JDK 8 之后的语法支持很差，遇到 switch 表达式、var 局部变量推断这类新语法会直接报解析错误，而工程里那些R.java又是自动生成的，报错位置会离谱地指到资源文件上。

我一般的做法是把 JDK 固定在一个独立目录，然后强制 Eclipse 只认它，而不是依赖系统 PATH。改eclipse.ini比改环境变量可靠得多，因为它是进程级的，不会被别的软件污染：

# eclipse.ini，写在 -vmargs 之前，且 -vm 必须单独占一行 -vm C:/dev/jdk8/bin/javaw.exe -vmargs -Xms256m -Xmx1024m -XX:MaxPermSize=256m

这里三个参数值得说清楚：-vm后面那一行必须是 javaw 的绝对路径，不能带引号包整行，Windows 路径用正斜杠或双反斜杠都行；-Xmx1024m是给 Eclipse 自己的堆，不是给 App 的，编译大工程时如果频繁 Full GC 就往上加；-XX:MaxPermSize是老版本 JVM 才认的参数，新 JVM 会警告但不影响启动，留着是为了兼容。顺序错了 Eclipse 会静默忽略-vm，然后继续用默认 JRE，你会以为改了没用——这是个典型的「改了配置但没生效」的黑匣子。

提示：命令行执行java -version和javac -version，两者版本号必须一致。只装 JRE 不装 JDK 时javac会提示找不到命令，而 Eclipse 依然能启动，于是错误会推迟到编译期才爆出来。

2.2 环境变量、SDK 路径与 AVD 的落地配置

SDK 不需要装全套。这套工程只依赖平台框架和基础工具，目录里真正被用到的只有platforms（编译目标，工程里叫 Project Build Target）、platform-tools（含 adb）、tools（含 AVD Manager 和 emulator）、build-tools。system-images只有当你要在模拟器里跑才需要，而且很吃磁盘。我的习惯是先只装一个平台版本，等工程编译通过了再按需补。

环境变量按下面这套配，Windows 和类 Unix 系统逻辑一致：

# 类 Unix：写进 ~/.bashrc 或 ~/.zshrc export JAVA_HOME=/opt/dev/jdk8 export ANDROID_SDK_ROOT=/opt/dev/android-sdk export PATH=$JAVA_HOME/bin:$ANDROID_SDK_ROOT/platform-tools:$ANDROID_SDK_ROOT/tools:$PATH

:: Windows：管理员 CMD 里执行，改完要重开终端才生效 setx JAVA_HOME "C:\dev\jdk8" /M setx ANDROID_SDK_ROOT "C:\dev\android-sdk" /M setx PATH "%PATH%;%ANDROID_SDK_ROOT%\platform-tools;%ANDROID_SDK_ROOT%\tools" /M

参数说明：ANDROID_SDK_ROOT是新变量名，老版本 ADT 认的是ANDROID_HOME，两个都设上不会有副作用，能省掉「SDK Location 填了但重启后丢失」的麻烦。platform-tools必须在 PATH 里，否则 adb 找不到设备时你根本没法判断是真机没连上还是驱动没装。配完后执行adb devices，输出里能看到设备序列号或emulator-5554，说明链路通了。

AVD 的创建在 AVD Manager 里点几下就行，但有两个参数影响很大：一是 CPU/ABI 选 x86 还是 ARM，x86 快但需要宿主开启硬件虚拟化，ARM 慢但兼容性好，老机器上跑 ARM 镜像启动一次要三五分钟，很容易误判成「卡死」；二是 Skin 分辨率，2048 的布局是按格子宽度算的，用太小的分辨率会挤成一团，建议不低于 480×800。

2.3 导入工程后必须改的四处工程属性

工程导入后大概率是一片红，先别急着改代码，按顺序改四个地方，能解决八成问题。

第一处是 Project Build Target。右键工程 → Properties → Android → 勾选一个已安装的平台版本。这一步不做，R.java不会生成，所有R.layout.xxx全部报「cannot be resolved」。

第二处是 Java Compiler 级别。同一面板里把 Compiler compliance level 降到与 JDK 匹配的档位，别用默认的最高档。老工程里常见的匿名内部类写法在新编译器下可能给出警告，但真正的硬错误来自语法版本不匹配。

第三处是文本编码。Properties → Resource → Text file encoding 选 UTF-8。论文工程里到处都是中文注释和中文的应用名，源文件如果不是 UTF-8 存的，导入后就是满屏问号，而且这种乱码会顺着字符串资源传到界面上。

第四处是AndroidManifest.xml里的minSdkVersion与targetSdkVersion。如果模拟器镜像是低版本，把minSdkVersion调到不高于镜像 API 级别，否则安装阶段直接失败，报INSTALL_FAILED_OLDER_SDK，这个报错文案很误导，看起来像设备太老，实际上是 manifest 要求太高。

<!-- AndroidManifest.xml：两个 Activity 都要注册，漏一个就闪退 --> <application android:label="@string/app_name" android:icon="@drawable/ic_launcher"> <activity android:name=".WelcomeActivity" android:exported="true"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> <activity android:name=".GameActivity" /> </application>

这段配置的逻辑值得展开：intent-filter只挂在欢迎页上，它决定了桌面图标点开先进哪个界面；游戏主界面作为普通 Activity 注册即可，由欢迎页通过Intent跳转过去。android:exported在老版本 SDK 上不是必填项，但在新平台上是硬性要求，漏写会在安装时报安全相关的错误。四个属性改完，Project → Clean 一次，让R.java重新生成，红波浪线通常会消掉大半。

3. 4×4 网格与合并算法：2048 真正的核心只有 60 行

界面、动画、主题皮肤这些都是外围，2048 的骨架只有一个 4×4 的整数棋盘和一套「压缩—合并—再压缩」的规则。把这段写对了，剩下的都是画图。很多人卡住不是因为不会 Android，而是把四个方向写成了四套几乎一样的代码，改一处漏三处，最后上下能动、左右合并出错，排查起来很痛苦。

3.1 用一维数组承载 4×4 棋盘：为什么不用二维

二维数组int[4][4]读起来直观，但在这类游戏里有三个隐形代价：传参时到处是双重循环、序列化存盘时要嵌套遍历、单元测试不好写。一维int[16]加上一个索引换算函数，反而更清爽。行优先布局下，index = row * 4 + col，取反就是row = index / 4、col = index % 4。

public class GameEngine { public static final int SIZE = 4; private final int[] grid = new int[SIZE * SIZE]; private int score = 0; public int get(int row, int col) { // 越界直接返回 0，让绘制层不用重复做边界判断 if (row < 0 || row >= SIZE || col < 0 || col >= SIZE) return 0; return grid[row * SIZE + col]; } public void reset() { java.util.Arrays.fill(grid, 0); score = 0; spawn(); // 新局先落两个，这是 2048 的标准开局 spawn(); } }

reset()里连落两个子是必须的，只落一个会导致第一步无论如何滑动都「没有变化」，玩家会以为触摸失灵。get()里的越界保护看着多余，但绘制时经常要用get(row, col-1)判断相邻卡片做视觉衔接，有了它绘制代码能少一层 if。

3.2 mergeLine：压缩、合并、再压缩三步走

一行的处理是整个算法的关键。标准做法是三步：先把所有非零值往左挤，再从左到右扫描相邻相等就合并，最后再挤一次把中间的空洞补上。第三步最容易被漏掉，漏了就会出现「2 2 0 0 合并后变成 4 0 0 0 而不是 4 0 0 0 之外还留了空」这类看起来对、实际上后续判定全乱的问题。

/** * 处理一行（长度固定为 SIZE），返回处理后的新行。 * 注意：调用方负责把结果写回棋盘并判断是否真的发生了变化。 */ private int[] mergeLine(int[] line) { int[] tmp = new int[SIZE]; int idx = 0; // 第一步：压缩，跳过 0，保持相对顺序 for (int v : line) { if (v != 0) tmp[idx++] = v; } // 第二步：合并，i++ 是为了让 2 2 2 2 变成 4 4 而不是 8 0 for (int i = 0; i < SIZE - 1; i++) { if (tmp[i] != 0 && tmp[i] == tmp[i + 1]) { tmp[i] = tmp[i] * 2; score += tmp[i]; // 分数只在合并成功时增加 tmp[i + 1] = 0; i++; // 关键：跳过刚被吃掉的格子 } } // 第三步：再压缩，把合并产生的空洞补掉 int[] result = new int[SIZE]; idx = 0; for (int v : tmp) { if (v != 0) result[idx++] = v; } return result; }

i++那一行是血泪经验所在。去掉它，2 2 2 2会先合成4 0 2 2，然后i走到下标 2 时又拿2和2比，继续合成，最终得到4 0 4 0之外的错误形态；而4 4 8 0这种序列如果连合两次，能一路滚成 16，分数也跟着翻倍。加上i++之后，一次滑动中每个原始卡片最多参与一次合并，这是 2048 规则的本意。

score用成员变量直接累加，而不是返回一个合并列表再统一算，是为了让动画层能在合并发生时立刻拿到增量做飘分效果。代价是这个方法有副作用，不能拿去做「假如往左滑会怎样」的预演——真要做预演，得先复制一份grid和score再跑。

3.3 四个方向靠索引映射复用同一段逻辑

只写一套左滑逻辑，然后用索引映射把「上、右、下」都翻译成「左」，是这段代码里最省事的设计。核心是一个index(row, col, dir)函数，它返回在某个方向上第row行第col列对应的真实格子下标。

public static final int DIR_LEFT = 0, DIR_RIGHT = 1, DIR_UP = 2, DIR_DOWN = 3; /** 把「某个方向上的第 r 行第 c 列」映射成棋盘的真实下标 */ private int index(int r, int c, int dir) { switch (dir) { case DIR_LEFT: return r * SIZE + c; case DIR_RIGHT: return r * SIZE + (SIZE - 1 - c); case DIR_UP: return c * SIZE + r; default: return (SIZE - 1 - c) * SIZE + r; } } /** 统一入口：四个方向共用一套合并逻辑 */ public boolean move(int dir) { boolean changed = false; for (int r = 0; r < SIZE; r++) { int[] line = new int[SIZE]; for (int c = 0; c < SIZE; c++) { line[c] = grid[index(r, c, dir)]; } int[] merged = mergeLine(line); for (int c = 0; c < SIZE; c++) { int target = index(r, c, dir); if (grid[target] != merged[c]) changed = true; grid[target] = merged[c]; } } if (changed) spawn(); // 只有真的动了才落新子 return changed; }

四个映射公式的含义：左滑按行为主、列正序；右滑按行为主、列倒序，相当于把每行镜像后当左滑处理；上滑按列为主、行正序，等于转置；下滑按列为主、行倒序，等于转置后再镜像。这四种变换的逆变换恰好是它们自己，所以写入时用同一个index()就能对回原位置，不需要额外的逆映射表。

changed这个返回值一定要用起来。它有两个作用：一是决定要不要落新子，二是给上层判断「这一步是不是无效操作」。没有它，玩家在已经贴边的方向上继续滑动，棋盘会不断冒出新数字，游戏立刻失去可玩性。

3.4 随机落子与新局判定

落子逻辑短，但有两个细节决定手感。第一是权重，标准规则是 90% 出 2、10% 出 4，直接用Math.random()阈值判断即可；第二是空格收集，先扫一遍所有空位放进列表，再随机取一个，比「随机撞位置直到撞到空的」可靠得多——后者在棋盘快满时会出现明显的卡顿。

private void spawn() { java.util.List<Integer> empty = new java.util.ArrayList<>(16); for (int i = 0; i < grid.length; i++) { if (grid[i] == 0) empty.add(i); } if (empty.isEmpty()) return; int pos = empty.get((int) (Math.random() * empty.size())); grid[pos] = Math.random() < 0.9 ? 2 : 4; } /** 四个方向都试一遍，都不动就是死局 */ public boolean isGameOver() { for (int dir = 0; dir <= DIR_DOWN; dir++) { if (canMove(dir)) return false; } return true; } private boolean canMove(int dir) { // 用副本试算，避免污染真实棋盘和分数 int[] backupGrid = grid.clone(); int backupScore = score; boolean can = move(dir); // move 内部会 spawn，所以必须还原子 System.arraycopy(backupGrid, 0, grid, 0, grid.length); score = backupScore; return can; }

isGameOver()这里有个容易翻车的点：move()内部会调用spawn()落新子，直接拿来试探会污染棋盘。上面的写法用clone()备份 +arraycopy()还原，虽然每次判定有四次数组拷贝，但对 16 个元素来说开销可以忽略。如果追求更干净，可以把「纯计算」和「落子」拆成两个方法，只是要多写一点样板代码。

4. 从手指滑动到卡片重绘：手势、绘制与分数持久化

算法对了，接下来是把它接到屏幕上。这一层最容易出的问题不是编译错误，而是「能跑但不好用」——滑动十次响应三次、卡片数字一变大就溢出、退出再进分数归零。这些都属于体验级 bug，答辩时老师随手一划就能发现。

4.1 onTouchEvent 里的阈值与方向判定

手势识别不需要 GestureDetector，onTouchEvent里记起点、在抬起时算位移就够了。要处理的是三件事：阈值、方向、误触。

private float startX, startY; private final int touchSlop; // 单位 px，建议取 屏幕密度 * 24dp 左右 public GameView(Context context) { super(context); // 用系统标准值比硬编码像素更稳，不同 dpi 下手感一致 touchSlop = ViewConfiguration.get(context).getScaledTouchSlop() * 2; } @Override public boolean onTouchEvent(MotionEvent event) { switch (event.getActionMasked()) { case MotionEvent.ACTION_DOWN: startX = event.getX(); startY = event.getY(); return true; // 必须返回 true，否则收不到后续事件 case MotionEvent.ACTION_UP: float dx = event.getX() - startX; float dy = event.getY() - startY; if (Math.max(Math.abs(dx), Math.abs(dy)) < touchSlop) { return true; // 位移太小，当点击处理，不做移动 } if (Math.abs(dx) > Math.abs(dy)) { engine.move(dx > 0 ? GameEngine.DIR_RIGHT : GameEngine.DIR_LEFT); } else { engine.move(dy > 0 ? GameEngine.DIR_DOWN : GameEngine.DIR_UP); } invalidate(); // 触发重绘 checkGameOver(); return true; default: return super.onTouchEvent(event); } }

参数说明：ACTION_DOWN返回true是整个手势能工作的前提，返回false的话后续ACTION_UP根本不会送到这个 View。touchSlop用ViewConfiguration拿系统值再乘 2，是因为原始值偏灵敏，手指轻微抖动就会被判成滑动，玩家点一下屏幕牌面就动了，体验很糟。方向判定用|dx| > |dy|而不是分别比较正负，是为了避免斜向滑动时出现两次连续移动。

ACTION_UP之外，还得处理ACTION_CANCEL。手指从屏幕边缘滑出系统区域时会发 cancel，如果你的代码只处理 up，会出现「划到一半游戏卡住」的错觉。稳妥做法是在 cancel 里什么都不做，把起点变量重置为 0 即可。

4.2 自定义 View 绘制卡片：颜色表与字号自适应

绘制分两层：背景格和数字卡片。颜色用数组按数值的 2 的幂次索引，数字文字大小按格子宽度的比例算，而不是写死sp。写死字号的后果是到了高分辨率屏幕上数字小得像蚂蚁，到了小屏上四位数的 4096 直接顶出格子。

// 下标 0 是空格底色，1 对应 2，2 对应 4，以此类推 private static final int[] CARD_COLORS = { 0xFFCDC1B4, 0xFFEEE4DA, 0xFFEDE0C8, 0xFFF2B179, 0xFFF59563, 0xFFF67C5F, 0xFFF65E3B, 0xFFEDCF72, 0xFFEDCC61, 0xFFEDC850, 0xFFEDC53F, 0xFFEDC22E }; private int colorOf(int value) { if (value == 0) return CARD_COLORS[0]; int level = (int) (Math.log(value) / Math.log(2)); // 2 -> 1, 4 -> 2 return CARD_COLORS[Math.min(level, CARD_COLORS.length - 1)]; } @Override protected void onDraw(Canvas canvas) { float cell = getWidth() / (float) GameEngine.SIZE; float pad = cell * 0.04f; // 间隙按格子比例走，任何分辨率都好看 paint.setAntiAlias(true); for (int r = 0; r < GameEngine.SIZE; r++) { for (int c = 0; c < GameEngine.SIZE; c++) { int value = engine.get(r, c); rect.set(c * cell + pad, r * cell + pad, (c + 1) * cell - pad, (r + 1) * cell - pad); paint.setColor(colorOf(value)); canvas.drawRoundRect(rect, cell * 0.08f, cell * 0.08f, paint); if (value != 0) { // 位数越多字号越小，保证四位数也不出格 int digits = String.valueOf(value).length(); paint.setColor(value <= 4 ? 0xFF776E65 : 0xFFF9F6F2); paint.setTextSize(cell * (digits <= 2 ? 0.42f : 0.32f)); paint.setTextAlign(Paint.Align.CENTER); float baseline = rect.centerY() - (paint.ascent() + paint.descent()) / 2; canvas.drawText(String.valueOf(value), rect.centerX(), baseline, paint); } } } }

几个参数值得展开：pad用格子的百分比而不用固定 dp，是为了让间隙和卡片一起缩放，否则大屏上会变成一片糊在一起的色块。圆角半径cell * 0.08f同理。文字基线那个公式是 Android 绘制文本的通用写法，直接用centerY()当 baseline 会让文字整体偏上，肉眼能看出来。Paint.Align.CENTER必须配合rect.centerX()使用，否则文字会以左下角为原点往右排。

注意：onDraw里不要做对象分配。rect和paint都应该是成员变量，在构造时初始化一次。每次绘制都new Rect()会持续触发 GC，滑动时掉帧会非常明显。

4.3 分数与最高分的持久化

SharedPreferences是这类小游戏最合适的选择，写入量小、读取频繁、不需要事务。要存两个值：当前分数（用于中途退出恢复）和历史最高分。坑在于提交时机——写在合并那一刻太频繁，写在onDestroy又可能不执行。

private static final String PREF = "game_2048"; private static final String KEY_SCORE = "score"; private static final String KEY_BEST = "best"; private void saveState() { SharedPreferences sp = getContext().getSharedPreferences(PREF, Context.MODE_PRIVATE); // 最高分要先读再比，直接覆盖会把纪录刷掉 int best = sp.getInt(KEY_BEST, 0); if (engine.getScore() > best) { sp.edit().putInt(KEY_BEST, engine.getScore()).apply(); } sp.edit().putInt(KEY_SCORE, engine.getScore()).apply(); } @Override protected void onPause() { super.onPause(); saveState(); // 切后台就存，比 onDestroy 可靠 }

apply()和commit()的区别在这里不重要，前者异步写内存后落盘，不会有主线程阻塞，适合这种高频小幅写入。真正要小心的是KEY_BEST的更新逻辑：如果写成putInt(KEY_BEST, engine.getScore())无条件覆盖，玩家开新局后最高分会被清零，这是很典型的一行代码毁所有。

4.4 两种主题（数字/酷车）的切换成本

论文里提到游戏有「数字」和「酷车一族」两个模式。落到实现上，最省事的做法不是做两套 Activity，而是把「值到外观」的映射抽成一个接口或一个颜色/图片数组，模式切换时只换映射表再invalidate()。

public interface ThemeProvider { int colorOf(int value); // 背景色或背景图资源 id String labelOf(int value, int mode); // 数字模式返回数字，酷车模式返回车型名 }

这样onDraw里只依赖接口，切换模式时把当前ThemeProvider换掉，其他代码一行不动。代价是模式选择的结果也要存进SharedPreferences，否则每次进游戏都要重新选，玩家会烦。常见做法是在欢迎页放两个按钮，点击后把模式写进 Intent 的 extra 传给游戏界面，同时在 sp 里落一份作为默认值。

5. 避坑：导入到真机跑通之间，最容易翻车的 5 个现场

这一章是我自己把这类老工程重跑一遍攒下来的记录。每一条都按「现象 → 原因 → 解决」写，对照着排查，比漫无目的地搜报错快得多。

5.1 编译期的三个高频报错

第 1 条：满屏红，R无法解析

现象：导入工程后所有R.layout.main、R.id.xxx全部标红，提示R cannot be resolved to a variable。Clean 之后依旧。

原因：R.java是在资源编译成功后才生成的，只要res目录下有一个文件不合规，整批资源就编不过，R自然不存在。最常见的不合规是图片文件名包含大写字母或连字符，其次是res/values里的 XML 有语法错误，最后才是 Project Build Target 没勾选。

解决：看 Console 或 Problems 面板里第一条与res相关的错误，别从第一条红波浪线开始找。把res/drawable下的资源统一改成小写加下划线，9.png的图片确认四边黑线完整，然后 Project → Clean。这一步做完还没好，再去检查 Build Target。

第 2 条：中文全变问号，应用名显示成乱码

现象：源码里的中文注释、strings.xml里的应用名、Toast 提示全变成????或方块。

原因：源文件在压缩包里的编码是 GBK，导入时 Eclipse 按默认的 GBK 解读没问题，但工程属性里的 Text file encoding 被设成了 UTF-8，或者反过来。两边不一致时，中文在编译期就被替换成了替换字符，运行时已经无从恢复。

解决：先统一工程编码为 UTF-8（Properties → Resource），然后用外部编辑器把确实存成 GBK 的文件转码另存。注意strings.xml里的中文是转义后的，改编码不会破坏它；真正容易坏的是.java里的注释和硬编码字符串。改完 Clean 一次，让资源重新打包。

第 3 条：编译通过，但安装时报INSTALL_FAILED_OLDER_SDK

现象：Eclipse 控制台显示 build 成功，部署到模拟器时失败，日志里一串INSTALL_FAILED_*。

原因：AndroidManifest.xml里的minSdkVersion高于当前设备或模拟器的 API 级别。2016 年的工程常把minSdkVersion写到很高的值以使用新 API，而你可能随手建了个低版本 AVD。

解决：要么把 manifest 里的minSdkVersion降到不高于镜像级别，要么换一个 API 级别更高的 AVD。改之前先确认代码里没有真正依赖高版本 API 的调用，否则降下来会在运行期抛NoSuchMethodError，比安装失败更难查。

5.2 运行期的闪退与黑屏

第 4 条：点开图标闪一下直接退回桌面

现象：安装成功，桌面图标也在，点击后白屏零点几秒就退出，没有任何 Toast。

原因：八成是 Activity 没在 manifest 里注册，或者注册了但intent-filter挂错了界面。其次是setContentView里的布局 id 写错，再其次是自定义 View 的构造函数里空指针。

解决：接adb logcat，按AndroidRuntime过滤，看Caused by:后面的第一行。ActivityNotFoundException对应注册问题，InflateException对应布局问题，NullPointerException要往上翻栈帧找到具体是哪个类的哪一行。

# 清空日志后重新启动应用，避免被历史日志淹没 adb logcat -c && adb logcat *:E

第 5 条：模拟器里能跑，真机上滑动没反应

现象：同样的 APK，在 AVD 上滑动正常，装到真机上怎么划都不动。

原因：不是代码问题，是事件被父容器拦截了。工程如果用了ScrollView或ViewPager包住游戏视图，父容器会先消费掉纵向滑动，子 View 的onTouchEvent收不到完整的 down-move-up 序列。另一个可能是真机屏幕的 dpi 更高，touchSlop换算后超过了你实际滑动的距离。

解决：在自定义 View 里重写requestDisallowInterceptTouchEvent(true)，在ACTION_DOWN时通知父容器别抢事件。阈值问题则把touchSlop换算成 dp 再打日志确认一次实际像素值，别凭感觉。

提示：ACTION_MOVE里如果做了任何return false，整个手势序列会中断。想在手势过程中做实时预览，就在 move 里只做记录，真正的判定统一放在 up 里。

5.3 交互与数据的两处「玄学」

第 6 条：分数每次进游戏都归零

现象：玩到几百分，按 Home 键出去再进来，分数变回 0，但最高分还在。

原因：onPause里没有调用保存，或者保存时用的 key 和读取时的 key 拼写不一致。这类问题通常是因为读和写分散在两个类里，一个用常量、一个是字符串字面量，改了一处忘了另一处。

解决：把 key 全部收进一个Constants类或者SharedPreferences所在类的private static final里，读写都引同一份。存完立刻打一条日志把取出来的值打出来，确认写入生效，比事后猜要快得多。

6. 把论文里的「详细设计」落成可验证的测试记录

论文第六章是软件测试，但绝大多数这类毕设的测试章节都是「打开游戏，滑动几次，功能正常」这种描述，答辩时老师一问细节就露怯。把这一章做实，其实只需要一张表格和几次可复现的操作记录。

先说表格。测试用例不要按「功能点」列，要按「可观察的结果」列，这样每条用例都能在真机上一分钟验证完：

T3 和 T4 是这套算法里最容易写错的点，也是最值得写进论文的两条。T4 的具体验证方式是：把棋盘手工构造成2 2 4 0一行，左滑后应该是4 4 0 0，如果结果是8 0 0 0，说明mergeLine里少了那个i++。

再说可复现的操作记录。测试环境要写清楚三件事：AVD 的 API 级别和分辨率、真机型号（用代称，比如「某国产中端机型，Android 8.1」）、以及 APK 的构建方式。这三项不写，别人拿到的测试结果无法复现，论文的测试章节就失去了意义。

还有一个容易被忽略的点：把「分数增加」和「卡片合并」分开验证。合并成功但分数没涨，说明score的累加写在了错误的位置——典型错误是写在了mergeLine的压缩阶段，那样每次滑动只要发生位移就会加分。

最后是一个习惯。这类网格类小游戏，我每次改完合并逻辑，都会先把grid手动塞成几个极端局面再跑一遍，而不是急着打 APK 装到手机上。具体是四个：全空、全满且都不同、单行2 2 2 2、对角落各一个大数。这四个局面能在三十秒内暴露掉九成的索引错误和合并错误，比在模拟器里划五十次有效得多。吃过一次亏——某次改完方向映射，上滑和下滑的索引写反了，APK 装了才发现，重新打包、重装、复测折腾了快一个小时；从那以后我每次动index()和mergeLine()，都强制走一遍这四个极端局面再加一轮四方向对拍。希望帮到你。

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