1. 项目概述：一个被低估的Android入门“练兵场”
“打地鼠小游戏App源码+提示框Toast+提示窗口Dialog+菜单Menu+下拉框Spinner”——这个标题乍看像是一份零散的功能清单，但在我带过十几期Android开发实训后，它其实是新手跨越“能写Hello World”到“能搭出完整交互逻辑”之间最关键的那座桥。不是所有小项目都配叫“练兵场”，而这个打地鼠，恰恰把Android四大基础UI组件（Toast、Dialog、Menu、Spinner）全嵌进了真实游戏流程里：你点中地鼠，弹Toast反馈得分；生命值归零，用Dialog跳出“游戏结束”确认框；长按屏幕调出Menu切换难度；难度选项又靠Spinner下拉选择实时生效。它不炫技，但每一步都在教你怎么让控件“活起来”，而不是堆在XML里当摆设。我见过太多人卡在“知道API怎么写，但不知道该在哪儿写、为什么这么写”的阶段，而这套源码就是专治这种“逻辑失联症”的。适合刚学完Activity生命周期、能写简单布局的新手，也适合想系统梳理UI交互链路的转行者。它不教你Kotlin协程或Jetpack Compose，但它会逼你亲手把“用户点一下→代码响一下→界面变一下”这条最朴素的闭环，从头到尾焊死。
2. 整体架构与设计思路拆解：为什么是打地鼠，而不是计算器？
2.1 选题逻辑：用游戏机制倒逼UI组件协同
很多人疑惑：学Toast和Dialog，直接写个“点击弹窗”Demo不更简单？但问题就在这儿——孤立练习永远学不会组件间的“配合”。打地鼠天然自带一套状态流：游戏运行中→用户点击→判断是否击中→更新分数/生命值→触发不同反馈（Toast/Dialog）→用户操作菜单/Spinner改变规则→状态重置。这个链条强制你思考：Toast该在哪个线程发？Dialog的dismiss逻辑要和游戏状态机怎么耦合？Menu的item点击后，如何让Spinner的选中项同步更新难度参数？这些不是API文档能告诉你的，而是你在调试“点中地鼠却没弹分”时，被迫翻源码、查日志、加断点才真正理解的。我试过用计算器替代，结果学员只学会了“按钮setOnClickListener”，却对“状态变更如何驱动UI刷新”毫无概念。打地鼠的“失败惩罚机制”（扣生命值）和“成功奖励机制”（加分+音效）让每个UI反馈都有了明确的业务语义，这是纯工具类App无法提供的训练强度。
2.2 组件选型依据：拒绝过度设计，聚焦核心能力
标题里列的四个组件，全是Android原生SDK中最稳定、兼容性最好、且最能暴露底层原理的“元组件”：
Toast：看似最简单，实则是理解Handler消息机制和主线程UI更新约束的第一课。你得明白为什么
Toast.makeText().show()必须在主线程调用，以及如果在子线程里强行调用会抛什么异常（RuntimeException: Can't create handler inside thread that has not called Looper.prepare()）。很多新手以为Toast只是“弹个文字”，却不知它背后是ViewRootImpl、WindowManager、Looper三者的精密协作。Dialog：这里特指
AlertDialog，而非DialogFragment。原因很实际：新手阶段，先掌握模态对话框的生命周期管理比学碎片化更关键。AlertDialog的setPositiveButton回调里，你必须手动处理“用户点了确定后，是重启游戏还是退出Activity？”——这直接关联到Activity的finish()和recreate()区别。用DialogFragment反而会把焦点引向“碎片通信”这种进阶话题，偏离当前目标。Menu：采用
onCreateOptionsMenu+onOptionsItemSelected的经典模式，而非PopupMenu。因为前者强制你理解菜单资源文件（menu.xml）如何与Java/Kotlin代码绑定，以及MenuItem.getItemId()返回值与R.id.xxx的映射关系。我见过太多人把菜单ID写成字符串硬编码，导致switch分支永远不走，最后发现是忘了在res/menu/下建对应XML。Spinner：选用
ArrayAdapter而非CursorAdapter，因为打地鼠的难度选项（简单/中等/困难）是静态数组，完全没必要引入数据库概念。重点在于教会你setOnItemSelectedListener的onItemSelected回调里，如何安全地获取选中项的position并转换为实际难度值（比如position=0对应difficulty=1），同时避免onNothingSelected被意外触发导致状态错乱。
这套组合拳的设计哲学就一条：用最小必要组件，覆盖最大比例的真实开发痛点。不追新，不炫技，专治“API会写，逻辑不会串”。
2.3 源码结构解析：为什么目录这样组织？
拿到源码，别急着跑。先看目录结构，它本身就在传递设计意图：
app/ ├── src/main/ │ ├── java/com/example/whackamole/ │ │ ├── MainActivity.java // 核心Activity，承载所有UI和逻辑 │ │ ├── GameEngine.java // 独立的游戏状态管理器（非必须，但强烈推荐） │ │ └── Difficulty.java // 枚举类，定义难度等级（简单/中等/困难） │ ├── res/ │ │ ├── layout/activity_main.xml // 主布局：FrameLayout嵌套GridLayout（地鼠网格）+ TextView（分数/生命） │ │ ├── menu/main_menu.xml // 菜单资源：三个item（重新开始/切换难度/退出） │ │ ├── values/strings.xml // 字符串资源：所有Toast/Dialog文本集中管理 │ │ └── drawable/ // 地鼠图片、背景图等关键点在于GameEngine.java的存在。很多初学者会把所有逻辑塞进MainActivity，导致文件动辄上千行。而这里把它抽离成独立类，目的很明确：解耦游戏规则与UI渲染。GameEngine只负责计算“当前该打哪个洞”、“击中后分数加多少”、“生命值是否归零”，它不碰任何TextView.setText()或Toast.show()。MainActivity则专注“监听用户点击”、“调用GameEngine的hitMole(int position)方法”、“根据GameEngine返回的状态码决定弹Toast还是Dialog”。这种分离让代码可测试性飙升——你可以单独给GameEngine写JUnit测试，验证“当难度为中等时，连续击中5次是否触发生命值减半”，而不用启动整个Activity。我在某高校实训中要求学员必须实现这个分离，结果第二周的Bug率下降了40%，因为大家终于能分清“是游戏逻辑错了，还是UI没刷新”。
3. 核心细节解析与实操要点：那些文档里不会写的坑
3.1 Toast的“隐形陷阱”：不只是弹出来那么简单
你以为Toast.makeText(this, "击中！", Toast.LENGTH_SHORT).show()就完了？错。这里有三个新手必踩的坑：
第一坑：Context传错导致内存泄漏
错误写法：
// 在非Activity类（如工具类）里这样写 public class Utils { public static void showToast(Context context, String msg) { Toast.makeText(context, msg, Toast.LENGTH_SHORT).show(); } } // 调用时传入Activity.this Utils.showToast(MainActivity.this, "击中！");表面没问题，但如果Utils.showToast()被某个长期存活的后台线程调用，而此时Activity已销毁，context就成了悬空引用，导致Activity无法被GC回收。正确做法是统一用getApplicationContext()：
// 在Activity内调用 Toast.makeText(getApplicationContext(), "击中！", Toast.LENGTH_SHORT).show(); // 或封装成Activity的扩展方法（Kotlin） fun Activity.showToast(msg: String) { Toast.makeText(applicationContext, msg, Toast.LENGTH_SHORT).show() }getApplicationContext()的生命周期与Application一致，绝不会因Activity销毁而失效。
第二坑：频繁调用导致Toast排队阻塞
打地鼠时用户可能疯狂点击，如果每次点击都show()一个Toast，你会发现Toast一个接一个弹，根本关不掉。解决方案是复用同一个Toast实例：
private Toast mToast; // 初始化一次 mToast = Toast.makeText(this, "", Toast.LENGTH_SHORT); // 每次点击时只改文字，不新建 mToast.setText("击中！得分+10"); mToast.show();这样无论点多少次，屏幕上永远只有一个Toast在显示，且不会堆积。
第三坑：自定义Toast的尺寸失控
想让Toast带图标？别直接setView()自定义View。新手常犯错误是给自定义View设wrap_content，结果在不同机型上高度炸开。正确姿势是固定高度：
View toastView = getLayoutInflater().inflate(R.layout.custom_toast, null); TextView text = toastView.findViewById(R.id.toast_text); text.setText("击中！"); // 关键：设置Toast的宽高 toastView.setMinimumWidth(400); // 像素值，适配不同dpi需用dp转px toastView.setMinimumHeight(120); Toast toast = new Toast(this); toast.setView(toastView); toast.setDuration(Toast.LENGTH_SHORT); toast.show();提示：
400px在mdpi（160dpi）设备上约等于250dp，足够显示一行文字+小图标，又不会撑满屏幕。用getResources().getDimensionPixelSize(R.dimen.toast_width)更规范，但新手先记住这个经验值。
3.2 Dialog的“生死时速”：dismiss时机决定体验
AlertDialog的坑不在创建，而在关闭。常见错误是用户点“确定”后，Dialog消失了，但游戏状态没重置，导致下次点地鼠直接崩溃。根源在于DialogInterface.OnClickListener的执行时机：
// 错误示范：在onClick里直接调用recreate() new AlertDialog.Builder(this) .setTitle("游戏结束") .setMessage("再接再厉！") .setPositiveButton("重新开始", new DialogInterface.OnClickListener() { @Override public void onClick(DialogInterface dialog, int which) { recreate(); // 危险！Activity正在销毁，recreate()可能失败 } }) .show();recreate()会触发Activity重建，但此时Dialog的dismiss()还没完成，系统可能抛WindowLeaked异常。正确做法是用Handler延后执行：
// 正确方案：确保Dialog完全dismiss后再操作 new AlertDialog.Builder(this) .setTitle("游戏结束") .setMessage("再接再厉！") .setPositiveButton("重新开始", (dialog, which) -> { // 先dismiss，再延后100ms执行重置 dialog.dismiss(); new Handler(Looper.getMainLooper()).postDelayed(() -> { resetGame(); // 自定义重置方法 }, 100); }) .show();resetGame()里清空分数、重置生命值、重置地鼠位置，这才是安全的起点。另外，AlertDialog的setCancelable(false)千万别忘，否则用户按返回键直接退出游戏，体验断层。
3.3 Menu的“隐藏依赖”：资源ID与代码的强绑定
菜单功能失效，90%是因为menu.xml和Java代码的ID没对齐。看这个典型错误：
res/menu/main_menu.xml：
<menu xmlns:android="http://schemas.android.com/apk/res/android"> <item android:id="@+id/action_restart" android:title="重新开始" /> <item android:id="@+id/action_difficulty" android:title="切换难度" /> </menu>MainActivity.java里却这样写：
// 错误：用错ID，应该是R.id.action_restart，不是R.string.restart if (item.getItemId() == R.string.restart) { // 编译能过，但永远不走 restartGame(); }R.string.restart是字符串资源ID，R.id.action_restart才是菜单项ID。必须严格匹配。更隐蔽的坑是onOptionsItemSelected的返回值：
// 必须return true，否则系统认为你没处理这个菜单项，后续点击无效 @Override public boolean onOptionsItemSelected(MenuItem item) { if (item.getItemId() == R.id.action_restart) { restartGame(); return true; // 关键！漏掉这句，菜单点一次就失效 } return super.onOptionsItemSelected(item); }return true告诉系统“我已处理”，return false则继续向上级传递，最终可能被父类吃掉。
3.4 Spinner的“静默崩溃”：选中事件的双重校验
Spinner最诡异的Bug是：用户明明选了“困难”，但游戏难度没变。排查发现onItemSelected根本没触发。原因有二：
原因一：Adapter数据源为空
初始化Spinner时，如果ArrayAdapter的List是空的，setOnItemSelectedListener会静默失效。必须确保数据源非空：
// 正确：初始化时给默认数据 String[] difficulties = {"简单", "中等", "困难"}; ArrayAdapter<String> adapter = new ArrayAdapter<>(this, android.R.layout.simple_spinner_item, difficulties); adapter.setDropDownViewResource(android.R.layout.simple_spinner_dropdown_item); spinner.setAdapter(adapter); // 关键：设置默认选中项，否则可能不触发onItemSelected spinner.setSelection(0); // 默认选“简单”原因二：onNothingSelected干扰
当Spinner第一次加载或数据重置时，会先触发onNothingSelected，如果你在里面写了resetDifficulty()，就会覆盖用户的真实选择。解决方案是加标志位：
private boolean isInitialized = false; spinner.setOnItemSelectedListener(new AdapterView.OnItemSelectedListener() { @Override public void onItemSelected(AdapterView<?> parent, View view, int position, long id) { if (!isInitialized) { isInitialized = true; // 第一次加载跳过 return; } // 此处处理用户真实选择 updateDifficulty(position); } @Override public void onNothingSelected(AdapterView<?> parent) { // 空实现，或只做日志记录 } });注意：
isInitialized必须是Activity的成员变量，不能是局部变量，否则每次回调都是新实例。
4. 实操过程与核心环节实现：从零搭建打地鼠全流程
4.1 环境准备与项目初始化
第一步永远不是写代码，而是确认环境。Android Studio版本建议Flamingo（2022.2.1）或更高，因为低版本对ViewBinding支持不完善，而本项目强烈推荐用ViewBinding替代findViewById——它能彻底杜绝NullPointerException。创建新项目时，选择“Empty Activity”，包名设为com.example.whackamole，最低SDK设为API 21 (Android 5.0)，覆盖95%以上设备。创建后立即启用ViewBinding：在app/build.gradle的android块内添加：
buildFeatures { viewBinding true }然后Sync Now。此时MainActivity会自动生成ActivityMainBinding类，所有findViewById(R.id.xxx)都将被binding.xxx替代，代码更安全、更简洁。
4.2 布局文件（activity_main.xml）的关键设计
打地鼠的布局核心是动态网格。别用GridView（已废弃），用GridLayout：
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="match_parent" android:orientation="vertical"> <!-- 顶部状态栏 --> <LinearLayout android:layout_width="match_parent" android:layout_height="wrap_content" android:orientation="horizontal" android:padding="16dp"> <TextView android:id="@+id/tv_score" android:layout_width="0dp" android:layout_height="wrap_content" android:layout_weight="1" android:text="分数：0" android:textSize="18sp" /> <TextView android:id="@+id/tv_life" android:layout_width="0dp" android:layout_height="wrap_content" android:layout_weight="1" android:text="生命：3" android:textSize="18sp" /> </LinearLayout> <!-- 地鼠网格区 --> <GridLayout android:id="@+id/grid_layout" android:layout_width="match_parent" android:layout_height="0dp" android:layout_weight="1" android:columnCount="3" android:rowCount="3" android:padding="20dp"> <!-- 9个地鼠坑位，用View占位，实际由代码动态添加ImageView --> <!-- 这里不写具体ImageView，留空让Java代码控制 --> </GridLayout> </LinearLayout>关键点：GridLayout的android:layout_weight="1"让它占据剩余全部空间，padding="20dp"保证坑位边缘有呼吸感。坑位不写死在XML里，而是用Java代码动态添加ImageView，这样可以统一设置点击事件和动画效果。
4.3 游戏引擎（GameEngine.java）的核心逻辑
这是整个项目的“大脑”，必须独立于UI。定义如下：
public class GameEngine { private int score = 0; private int life = 3; private Difficulty currentDifficulty = Difficulty.EASY; private Random random = new Random(); // 难度枚举 public enum Difficulty { EASY(1000), MEDIUM(700), HARD(400); // 数值代表地鼠出现间隔（毫秒） private final int interval; Difficulty(int interval) { this.interval = interval; } public int getInterval() { return interval; } } // 击中地鼠 public boolean hitMole(int position) { // 简化逻辑：假设position有效即击中 score += currentDifficulty == Difficulty.EASY ? 10 : currentDifficulty == Difficulty.MEDIUM ? 20 : 30; return true; } // 扣除生命值 public void loseLife() { life--; } // 重置游戏 public void reset() { score = 0; life = 3; currentDifficulty = Difficulty.EASY; } // 获取当前状态 public GameState getState() { return new GameState(score, life, currentDifficulty); } // 内部状态类 public static class GameState { public final int score; public final int life; public final Difficulty difficulty; public GameState(int score, int life, Difficulty difficulty) { this.score = score; this.life = life; this.difficulty = difficulty; } } }GameState类是关键，它把分散的状态打包成不可变对象，MainActivity只需监听getState()就能同步UI，避免到处getScore()、getLife()调用。
4.4 MainActivity的完整实现：串联所有组件
现在把所有线索拧在一起。MainActivity的onCreate方法：
public class MainActivity extends AppCompatActivity { private ActivityMainBinding binding; private GameEngine gameEngine; private Handler gameHandler; private Runnable gameRunnable; private ImageView[] moleHoles; // 9个坑位的ImageView数组 @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); binding = ActivityMainBinding.inflate(getLayoutInflater()); setContentView(binding.getRoot()); gameEngine = new GameEngine(); initMoleHoles(); // 初始化9个坑位 initGameLoop(); // 启动游戏循环 setupUIListeners(); // 绑定所有点击事件 } private void initMoleHoles() { moleHoles = new ImageView[9]; GridLayout grid = binding.gridLayout; for (int i = 0; i < 9; i++) { ImageView iv = new ImageView(this); iv.setImageResource(R.drawable.mole_hidden); // 初始为“藏起来”状态 iv.setLayoutParams(new GridLayout.LayoutParams( GridLayout.spec(i / 3), GridLayout.spec(i % 3))); iv.setOnClickListener(v -> onMoleClick(i)); // 统一点击监听 grid.addView(iv); moleHoles[i] = iv; } } private void initGameLoop() { gameHandler = new Handler(Looper.getMainLooper()); gameRunnable = new Runnable() { @Override public void run() { // 随机选一个坑位显示地鼠 int randomIndex = new Random().nextInt(9); showMole(randomIndex); // 根据难度设置下次出现时间 int delay = gameEngine.getState().difficulty.getInterval(); gameHandler.postDelayed(this, delay); } }; // 启动循环 gameHandler.post(gameRunnable); } private void showMole(int index) { // 显示地鼠动画（简化为切换图片） moleHoles[index].setImageResource(R.drawable.mole_shown); // 2秒后自动隐藏 new Handler(Looper.getMainLooper()).postDelayed(() -> { moleHoles[index].setImageResource(R.drawable.mole_hidden); }, 2000); } private void onMoleClick(int position) { // 检查是否击中（此处简化：只要点中就计分） if (moleHoles[position].getDrawable().getConstantState() == getResources().getDrawable(R.drawable.mole_shown).getConstantState()) { gameEngine.hitMole(position); // 更新UI updateUI(); // 弹Toast Toast.makeText(getApplicationContext(), "击中！+" + (gameEngine.getState().difficulty == GameEngine.Difficulty.EASY ? 10 : 20), Toast.LENGTH_SHORT).show(); } } private void updateUI() { GameEngine.GameState state = gameEngine.getState(); binding.tvScore.setText("分数：" + state.score); binding.tvLife.setText("生命：" + state.life); // 生命归零，弹Dialog if (state.life <= 0) { showGameOverDialog(); } } private void showGameOverDialog() { new AlertDialog.Builder(this) .setTitle("游戏结束") .setMessage("最终得分：" + gameEngine.getState().score) .setPositiveButton("再玩一次", (dialog, which) -> { dialog.dismiss(); gameEngine.reset(); updateUI(); // 重置所有坑位 for (ImageView iv : moleHoles) { iv.setImageResource(R.drawable.mole_hidden); } }) .setNegativeButton("退出", (dialog, which) -> finish()) .setCancelable(false) .show(); } private void setupUIListeners() { // 菜单监听 binding.toolbar.setOnMenuItemClickListener(item -> { if (item.getItemId() == R.id.action_restart) { restartGame(); return true; } else if (item.getItemId() == R.id.action_difficulty) { showDifficultyDialog(); return true; } return false; }); // Spinner监听（假设Spinner在toolbar里，或单独加在布局中） Spinner spinner = findViewById(R.id.spinner_difficulty); if (spinner != null) { ArrayAdapter<CharSequence> adapter = ArrayAdapter.createFromResource( this, R.array.difficulty_array, android.R.layout.simple_spinner_item); adapter.setDropDownViewResource(android.R.layout.simple_spinner_dropdown_item); spinner.setAdapter(adapter); spinner.setOnItemSelectedListener(new AdapterView.OnItemSelectedListener() { @Override public void onItemSelected(AdapterView<?> parent, View view, int position, long id) { // position 0=简单, 1=中等, 2=困难 switch (position) { case 0: gameEngine.setCurrentDifficulty(GameEngine.Difficulty.EASY); break; case 1: gameEngine.setCurrentDifficulty(GameEngine.Difficulty.MEDIUM); break; case 2: gameEngine.setCurrentDifficulty(GameEngine.Difficulty.HARD); break; } // 重启游戏循环以应用新难度 gameHandler.removeCallbacks(gameRunnable); gameHandler.post(gameRunnable); } @Override public void onNothingSelected(AdapterView<?> parent) {} }); } } private void restartGame() { gameEngine.reset(); updateUI(); for (ImageView iv : moleHoles) { iv.setImageResource(R.drawable.mole_hidden); } } private void showDifficultyDialog() { // 可选：用Dialog展示难度说明 new AlertDialog.Builder(this) .setTitle("难度说明") .setMessage("简单：地鼠出现慢，得分少\n中等：平衡体验\n困难：地鼠出现快，得分多") .setPositiveButton("确定", (dialog, which) -> dialog.dismiss()) .show(); } @Override protected void onDestroy() { super.onDestroy(); // 清理Handler，防止内存泄漏 if (gameHandler != null) { gameHandler.removeCallbacksAndMessages(null); } } }这段代码展示了所有组件的协同：initMoleHoles()动态创建坑位，initGameLoop()用Handler驱动游戏节奏，onMoleClick()触发Toast，showGameOverDialog()用AlertDialog终结游戏，setupUIListeners()把Menu和Spinner的逻辑缝进主线程。特别是onDestroy()里的removeCallbacksAndMessages(null)，这是防止Activity销毁后Handler还在发消息导致崩溃的保命操作。
5. 常见问题与排查技巧实录：那些让我熬夜到三点的Bug
5.1 “Toast不显示”问题速查表
| 现象 | 可能原因 | 排查步骤 | 解决方案 |
|---|---|---|---|
| 完全不弹 | Context传错（传了null或已销毁的Activity） | 在Toast.makeText()前加Log.d("Toast", "Context: " + context)，检查是否为null | 改用getApplicationContext()，或确保Activity未finish |
| 弹出位置偏移（如只显示半截） | 自定义Toast的View设置了wrap_content且内容过长 | 用Layout Inspector查看Toast View的实际尺寸 | 固定setMinimumWidth()和setMinimumHeight()，或用setText()前先setTextSize() |
| 多个Toast排队弹出 | 每次点击都新建Toast实例 | 在onCreate()里加Log.d("Toast", "New Toast created")，看日志频率 | 复用Toast实例，只调用setText()和show() |
5.2 “Dialog点击无响应”深度排查
新手最崩溃的场景：Dialog弹出来了，但点“确定”没反应。这不是代码问题，是线程问题。AlertDialog的OnClickListener默认在主线程执行，但如果你在onClick里做了耗时操作（如网络请求），会导致ANR（Application Not Responding）。解决方案分两步：
第一步：确认是否ANR
在onClick里加日志：
.setPositiveButton("确定", (dialog, which) -> { Log.d("Dialog", "Start processing..."); // 模拟耗时操作 try { Thread.sleep(3000); // 3秒延迟 } catch (InterruptedException e) { e.printStackTrace(); } Log.d("Dialog", "End processing..."); });如果日志只打印了“Start”，没打印“End”，说明线程被卡死了。此时打开Android Studio的Logcat，过滤ANR，大概率看到Input dispatching timed out。
第二步：正确异步处理
把耗时操作扔到子线程，结果回调到主线程更新UI：
.setPositiveButton("确定", (dialog, which) -> { // 启动子线程 new Thread(() -> { // 耗时操作 doHeavyWork(); // 回调到主线程 runOnUiThread(() -> { // 更新UI，如重置游戏 resetGame(); }); }).start(); });5.3 “Spinner选中后不触发onItemSelected”的终极诊断
这个问题90%源于Adapter数据源变更时的“状态重置”。标准诊断流程：
检查
setAdapter()是否在onCreate()后调用
如果在AsyncTask的onPostExecute()里调用，而此时Activity已重建，Spinner引用为空。加空指针检查：if (spinner != null) { spinner.setAdapter(adapter); } else { Log.e("Spinner", "Spinner is null!"); }验证
ArrayAdapter的数据源是否为空
在setAdapter()后立刻打印：Log.d("Spinner", "Adapter count: " + adapter.getCount());如果输出
0，说明数据源为空，onItemSelected永远不会触发。强制触发一次选中
在setAdapter()后加：spinner.setSelection(0, false); // false表示不触发回调，避免首次加载干扰然后在
onItemSelected里移除isInitialized标志位，改为：if (position == 0 && !isInitialized) { isInitialized = true; return; }
5.4 “Menu不显示”问题根因分析
菜单不显示，八成是onCreateOptionsMenu()没被调用。原因有三：
- Toolbar未设置为ActionBar：在
onCreate()里漏了setSupportActionBar(binding.toolbar)； - 主题禁用了ActionBar：检查
res/values/themes.xml，确保<style name="Theme.WhackAMole" parent="Theme.MaterialComponents.DayNight.DarkActionBar">，不是NoActionBar； onCreateOptionsMenu()返回了false：必须return true，否则菜单不渲染。
快速验证：在onCreateOptionsMenu()里加Log.d("Menu", "Inflating menu")，运行看日志是否打印。不打印，就按上述三点逐个排除。
6. 实战心得与经验延伸：从打地鼠到真实项目
这个打地鼠项目，我带过的学员平均用12小时能跑通，但真正吃透要3天。为什么？因为它的价值不在“做出游戏”，而在建立一套可迁移的Android开发心法。分享几个血泪换来的经验：
第一，永远先画状态图，再写代码。别急着敲Toast.makeText()。拿出纸笔，画出“游戏开始→地鼠出现→用户点击→击中/未击中→分数/生命变化→触发Toast/Dialog→用户操作Menu/Spinner→状态重置”这条链。每个节点标出“谁触发”、“谁响应”、“数据流向”。我见过太多人对着源码改来改去，却连“Toast该在hitMole()后调用，还是在updateUI()后调用”都犹豫不决，根源就是没理清状态流转。
第二，把“资源ID”当命根子护着。R.id.xxx、R.menu.xxx、R.array.xxx这些ID不是魔法数字，它们是编译时生成的整数常量。一旦XML文件名拼错（如main_menu.xml写成main_menu.xmls），或者<item>的android:id少了个@+id/，整个菜单就废了。我的习惯是：所有资源文件建好后，立刻在strings.xml里加一句<string name="debug_resource_check">OK</string>，然后在onCreate()里Log.d("Debug", getString(R.string.debug_resource_check))，确保资源能正常加载。
第三，Handler是新手的照妖镜。你能用Handler写出稳定的游戏循环，就证明你真正理解了Android的线程模型。但别滥用——Handler不是万能胶。当游戏逻辑复杂到需要状态机时，果断上LiveData或StateFlow。打地鼠用Handler够用，但如果是“多人联机打地鼠”，就得考虑CoroutineScope和Channel了。
最后说个延伸方向：把这个打地鼠升级成“跨平台版”。用Jetpack Compose重写UI，用KMM（Kotlin Multiplatform Mobile）把GameEngine逻辑抽到共享模块，iOS端用SwiftUI调用同一套游戏规则。这时候你会发现，当年在GameEngine.java里写的enum Difficulty，在KMM里变成了expect enum class Difficulty，而Toast和Dialog的平台差异，正好逼你去学expect/actual声明。所以别小看这个小项目，它是你通往现代Android开发的必经渡口——渡过去，海阔凭鱼跃；停在岸边，永远在findViewById的泥潭里打转。
我在某公司带新人时，把打地鼠作为入职第一周考核：不求代码完美，但必须能讲清楚“为什么Toast要用getApplicationContext()”、“Dialog的dismiss()和Activity.finish()谁先谁后”。能说清的，两周后就能接手真实模块；说不清的，得重学线程基础。这项目就像一面镜子，照出的是你对Android底层的理解深度，而不是手速。
