从钢琴块游戏入手：Android自定义View与触摸事件实战

简介：Android Studio实现的钢琴块小游戏（别踩白块）完整项目源码，适合Android入门学习者作为练手项目，也适合移动开发课程大作业参考。项目基于Java开发，涵盖方块生成、下落动画、点击判定、计分与结束逻辑等核心玩法，界面呈现黑白方格阵列，逻辑清晰、易于扩展。资源包为zip压缩格式，共1188个文件，大小18.76MB，主要包含java源码、Android资源xml、构建配置gradle及若干class与dex中间产物，另含少量apk、mp3等，目录结构完整，可直接导入Android Studio运行调试。已有1068人学习下载，可从中了解Android游戏开发的事件监听、Canvas绘制、Handler消息处理等常用技术，同时锻炼逻辑思维与代码组织能力。通过阅读源码并动手修改参数，还能加深对游戏循环和碰撞检测的理解，是快速上手安卓开发的实用资料。

1. 钢琴块游戏是Android开发的“最小完整工程”

很多人学Android的第一感觉是“会了Activity就会写App”，但真正上手做项目时才发现，一个完整应用牵涉到的布局优化、事件分发、生命周期管理、线程同步，远比单独学一个组件要复杂。钢琴块小游戏恰好是最适合用来填补这个断档的项目：它逻辑简单，不需要联网，没有数据库，但背后却完整覆盖了Android开发中最核心的几块技术——自定义View的绘制、触摸事件的分发与消费、Handler与线程间的通信、以及音效的实时触发与释放。

这个项目的价值不在于“做出了一个小游戏”，而在于它天然逼着你从多个角度思考同一个问题。举个具体例子，方块下落的速度、音符触发的位置、手指按下的坐标判定，这三者关系紧密，任何一个环节出现问题，玩家都会觉得“按键不灵”或“节奏不对”。这就逼着你去理解坐标系、碰撞判定和帧更新机制，而这些恰恰是Android应用开发中高频使用的底层能力。

这篇文章我会沿着一个完整的实现路径来走：先帮你把一个空项目搭建起来，再让方块动起来，然后处理点击与计分的核心逻辑，最后落到性能与手感调优上。所有代码都可以直接抄走跑起来，参数含义我会逐一拆开说明，包括它们为什么是这个值、调大调小会导致什么结果。适合的读者是刚开始做Android项目、或者做过界面但没碰过自定义绘制的开发者，也适合想快速搭一个App拿来练手面试的安卓初学者。

2. 搭建钢琴块项目：从Studio环境到工程骨架

2.1 Android Studio环境准备与SDK配置

在动手写代码前，先确认本机Android Studio状态正常。如果你的Android Studio还在英文界面，先进入File -> Settings -> Plugins，搜索“Chinese (Simplified) Language Pack”点击Install，重启Studio即可汉化。这个操作不影响后续任何代码逻辑，只是方便你对照本文的菜单路径。

SDK方面，新建项目时建议选“Empty Views Activity”，注意不是“Empty Activity”——后者会用Compose，虽然也能实现游戏，但钢琴块这种高频刷新画面的场景用传统的View体系更容易把逻辑讲清楚。SDK版本选择上，compileSdk用34即可，minSdk建议设在21（Android 5.0）以上，这样能覆盖绝大多数设备，同时不需要处理过度复杂的兼容逻辑。

如果你的Android Studio在viewBinding开启时报错提示“SDK无法勾选”，大概率是SDK Manager里缺了对应版本的Build-Tools。进Settings -> Appearance & Behavior -> System Settings -> Android SDK，在“SDK Tools”标签页勾选要用的构建工具版本，点Apply完成安装。这一步不做，等会儿gradle sync会直接失败，错误信息往往是Failed to find Build Tools revision 34.0.0。

2.2 build.gradle依赖配置与ViewBinding开关

项目创建完成后，先打开模块级build.gradle.kts，确认下面几行：

android { namespace = "com.example.pianoblock" compileSdk = 34 defaultConfig { applicationId = "com.example.pianoblock" minSdk = 21 targetSdk = 34 versionCode = 1 versionName = "1.0" } buildFeatures { viewBinding = true } } dependencies { implementation("androidx.core:core-ktx:1.12.0") implementation("androidx.appcompat:appcompat:1.6.1") implementation("com.google.android.material:material:1.11.0") }

这里重点说两件事。第一，viewBinding = true是你后面能少写大量findViewById的基础，它会自动为每个xml布局生成对应的绑定类。第二，游戏本身其实不需要额外依赖重量级框架，音效用SoundPool、图片全部用代码绘制，所以上面这些基础依赖已经足够，不需要引第三方游戏引擎。

同步完成后，在res/layout/activity_main.xml里放一个全屏容器作为游戏承载区：

<?xml version="1.0" encoding="utf-8"?> <FrameLayout xmlns:android="http://schemas.android.com/apk/res/android" android:id="@+id/gameContainer" android:layout_width="match_parent" android:layout_height="match_parent" android:background="#303030" />

FrameLayout在这里比LinearLayout或ConstraintLayout更合适，因为钢琴块游戏只需要一个GameView铺满全屏，而FrameLayout的定位方式不会额外引入布局开销，能保证后面onDraw里每次刷新都拿到满血的画面渲染能力。

2.2.1 Activity绑定与沉浸式全屏

MainActivity的初始化代码要做三件事：开启ViewBinding、启动GameView、隐藏系统导航栏。第三步很关键，玩家在游戏里是竖向握持手机，如果导航栏弹出，手指很容易误触退出游戏。

class MainActivity : AppCompatActivity() { private lateinit var binding: ActivityMainBinding private lateinit var gameView: GameView override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) binding = ActivityMainBinding.inflate(layoutInflater) setContentView(binding.root) hideSystemBars() gameView = GameView(this) binding.gameContainer.addView( gameView, FrameLayout.LayoutParams( FrameLayout.LayoutParams.MATCH_PARENT, FrameLayout.LayoutParams.MATCH_PARENT ) ) } private fun hideSystemBars() { window.decorView.systemUiVisibility = ( View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY or View.SYSTEM_UI_FLAG_LAYOUT_STABLE or View.SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION or View.SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN or View.SYSTEM_UI_FLAG_HIDE_NAVIGATION or View.SYSTEM_UI_FLAG_FULLSCREEN ) } }

沉浸式全屏的代码可以不用理解每一行的含义，但有个重要细节必须注意：SYSTEM_UI_FLAG_IMMERSIVE_STICKY只负责让系统栏在用户上滑时短暂出现然后自动消失，如果你用的是Android 12及以上的设备，建议直接改用WindowInsetsController的方式，代码简洁很多：

if (Build.VERSION.SDK_INT >= 30) { window.setDecorFitsSystemWindows(false) window.insetsController?.hide( WindowInsets.Type.systemBars() or WindowInsets.Type.displayCutout() ) }

这里的兼容分支要保留，因为老的systemUiVisibility在API 30之后已经标记废弃，但仍有大量存量设备在API 21-29之间，不写上会在这部分机型的沉浸式效果直接失效。

3. 钢琴块游戏核心：自定义View与方块下落逻辑

3.1 为什么用SurfaceView而不用View

钢琴块游戏的核心是画面持续刷新：方块从顶部下落、被点击时消失、新方块从顶部出现。这种场景下，常规的View方案有一个结构性问题——它的onDraw()由主线程调用，而主线程同时还要处理触摸事件。当画面刷新和手指点击同时发生时，主线程工作量大增，轻则帧率波动，重则出现掉帧甚至ANR。

SurfaceView则完全不同。它拥有独立的绘图表面，你可以在子线程中进行绘制操作，主线程只负责接收触摸事件。这意味着“画面持续更新”和“玩家快速点击”互不阻塞，这在钢琴块这种需要极高响应速度的游戏里是必须满足的前提。

再往下细分，SurfaceView还有一个升级版TextureView，它支持在UI层级中做旋转动画，但代价是性能开销更大。对于钢琴块这种需要全屏播放画面的场景，TextureView的优势基本用不上，反而拖累性能。所以在项目架构上，我选择了SurfaceView作为GameView的基类，配合一个独立渲染线程来驱动游戏循环。

3.2 方块的数据结构与生成规则

每一块的逻辑可以用一张数据表来描述——它是整个游戏逻辑的最小单元：

用ArrayDeque（双端队列）来存放这些方块对象。为什么不用ArrayList？因为方块数据是队列性质的：从底部移出，从顶部追加，ArrayDeque的增删效率在头部操作上远高于ArrayList——后者的头插头删复杂度是O(n)，而前者是O(1)。这个差异在游戏运行几分钟后，方块数量达到数千块时会非常明显。

方块生成规则维持一个4列布局，每列宽度等于屏幕宽度除以4。每次生成一行，包含1到2个方块，随机落在这4列中。保证同行的两个方块不会出现在相邻列，避免出现两个方块靠太近导致手指必须横跨半个屏幕才能完成连点。

3.3 屏幕坐标系与下落速度计算

在做绘制与触摸判定前，先统一坐标系。Android的SurfaceView的坐标系原点在屏幕左上角，X轴向右为正，Y轴向下为正。钢琴块的“行”用X轴坐标表达，“下落”实际上是Y轴坐标的持续增加。

下落速度的设定必须与判定区域配合。我采用固定速度加动态加速的策略：

private var baseSpeed = 300f // 起始速度，单位：像素/秒 private var speedStep = 2f // 每得10分增加的速度 private var currentSpeed = baseSpeed private var score = 0 fun updateSpeed() { currentSpeed = baseSpeed + (score / 10) * speedStep }

这里baseSpeed = 300f的含义是每秒移动300像素。假如屏幕高度是2400像素，那么一个方块从顶部出现到从底部消失需要8秒。对新手来说这个速度不紧不慢，既能让人反应得过来，又有一定的挑战性。speedStep = 2f意味着每得10分，方块下落速度增加2像素/秒。这个增长量级是经过验证的——它足够让人在游戏第2分钟感受到压力的上升，但不会突然快到没法玩。

3.4 渲染线程与onDraw绘制逻辑

渲染线程负责驱动整个游戏循环，每一次循环完成“更新坐标 -> 绘制到安全画布 -> 交换画面”这三个步骤。核心代码：

class GameView(context: Context) : SurfaceHolder.Callback, Runnable { private val holder: SurfaceHolder = holder private var isRunning = false private var thread: Thread? = null private var canvas: Canvas? = null override fun surfaceCreated(holder: SurfaceHolder) { isRunning = true thread = Thread(this).also { it.start() } } override fun surfaceDestroyed(holder: SurfaceHolder) { isRunning = false thread?.join() thread = null } override fun run() { val frameTime = 16L // 约60帧/秒 while (isRunning) { val startTime = System.currentTimeMillis() update() // 更新所有方块坐标 draw() // 执行绘制 val delta = System.currentTimeMillis() - startTime val sleepTime = frameTime - delta if (sleepTime > 0) { try { Thread.sleep(sleepTime) } catch (e: InterruptedException) { e.printStackTrace() } } } } }

这里有一个细节必须强调：surfaceDestroyed中的thread?.join()不是多余的。如果不这么做，Activity销毁时渲染线程还在往已销毁的画布上绘图，会导致IllegalArgumentException: Surface was already destroyed之类的崩溃。join()会让主线程等渲染线程退出后再继续执行销毁流程，保证线程的生命周期和Surface一致。

绘制逻辑核心在draw()函数内：

private fun draw() { if (!holder.surface.isValid) return // 画布不可用时直接跳过 canvas = holder.lockCanvas() if (canvas == null) return try { canvas.drawColor(Color.rgb(48, 48, 48)) // 背景色 val blockWidth = width / 4f for (block in blockQueue) { if (block.isPressed) continue // 已消除的块不再绘制 val left = block.col * blockWidth val right = left + blockWidth - 2f // 预留2px间隔 val top = block.y val bottom = block.y + blockHeight paint.color = if (block.isPressed) Color.rgb(0, 0, 0) else Color.rgb(70, 130, 180) canvas.drawRect(left, top, right, bottom, paint) } } finally { holder.unlockCanvasAndPost(canvas) } }

绘制前先lockCanvas锁定一个“要画进去的画布”，绘制完毕通过unlockCanvasAndPost把画布内容提交到屏幕上。这两个操作是严格配对的，中间任何一句代码抛异常，画布锁就没法释放，后续所有绘制都会卡住。用try-finally来做释放保护是标准做法。

blockQueue这里的便利循环用的是for (block in blockQueue)，它等价于for (block in blockQueue.iterator())。注意不要在循环体内直接remove对象，否则会抛ConcurrentModificationException。要消除方块，给isPressed置true然后在run()循环外统一清理。

4. 点击判定与计分逻辑：触摸事件与两行加速技巧

4.1 onTouchEven事件分发与按下坐标获取

触摸事件通过GameView的onTouchEvent来完成，这也是玩家与游戏互动的唯一入口。当屏幕上的手指按下时，Android会将一个MotionEvent顺着ViewHierarchy从上往下投递。我们的GameView已经铺满全屏，所以事件会直接到达这里。

override fun onTouchEvent(event: MotionEvent): Boolean { when (event.actionMasked) { MotionEvent.ACTION_DOWN -> { handleTap(event.x, event.y) return true } MotionEvent.ACTION_MOVE -> { if (!isPlayerTapping) { handleTap(event.x, event.y) } } } isPlayerTapping = true return super.onTouchEvent(event) }

return true表示这个事件被消费了，不会继续传递给其他View。在游戏中你可能希望按住连续消除多个方块，就需要在ACTION_MOVE里也做判定，但要注意一个陷阱——玩家在连点中手指轻微移动时，虽然并没有真正“按下”新位置，但ACTION_MOVE事件已经携带了新的坐标。如果按这个坐标做命中判定，可能会把未碰到的手势误判为按到了相邻方块。

所以在ACTION_MOVE分支里我加了一个isPlayerTapping变量来控制：只有第一次按下后才开启连续判定，每次有效击中都重置一个计时器，超过400毫秒没有新的命中事件就复位。这个逻辑保证了手在屏幕上滑动时会触发“多连击”效果，而不会因为手指的微小移动产生特别苛刻的判定。

4.2 点击判定核心：几何碰撞检测

钢琴块游戏本质上是“手指点击坐标是否落在某个方块范围内”的几何判断：

private fun handleTap(x: Float, y: Float) { val col = (x / blockWidth).toInt() if (col !in 0..3) return // 手指在边界外，直接忽略 val block = findBlockOnColumn(col, y) if (block == null || block.isPressed) { gameOver() // 或者执行miss罚时逻辑 return } block.isPressed = true score++ updateSpeed() playTone(col) // 播放对应列的音效 // 触发连击快感：下面代码是“阶梯判定”的核心 if (isCombo) { comboCount++ } else { comboCount = 1 isCombo = true } } private fun findBlockOnColumn(col: Int, y: Float): Block? { val tolerance = 120f // 判定容差：约为方块高度的 1/3 return blockQueue.firstOrNull { block -> block.col == col && !block.isPressed && y >= block.y - tolerance && y <= block.y + blockHeight + tolerance } }

这段代码中tolerance = 120f是最关键的一个调参点。容差太小，手指按到方块边缘时判定不中，玩家会疯狂抱怨“点到了但没反应”；容差太大，方块还没完全到手指位置就能被提前消除，游戏难度锐减。

120f这个值适合屏幕高度在2200px以上的设备，对应的物理尺寸大约是1.2厘米。它在视觉上表现为“当手指按到方块下边缘上方约1.2厘米时就能触发”，玩家会觉得“沾边就算”，手感是爽快的，又不至于让你隔着老远就消块。

4.3 阶梯加速与双键同按识别

钢琴块的高级手感来自“双指同时按不同列”的支持。这种场景下Android会将两次按下分别发送为两个ACTION_DOWN事件，但有时也会合并为一个“ACTION_POINTER_DOWN”事件。需要多指针支持：

override fun onTouchEvent(event: MotionEvent): Boolean { val action = event.actionMasked if (action == MotionEvent.ACTION_POINTER_DOWN || action == MotionEvent.ACTION_DOWN) { val pointerCount = event.pointerCount for (i in 0 until pointerCount) { val x = event.getX(i) val y = event.getY(i) handleTap(x, y) } } return true }

这个循环里的getX(i)取的是第i根手指的X坐标。如果同时按下了两根手指，pointerCount = 2，循环里会分别拿到两根手指的坐标并发起判定。注意ACTION_POINTER_DOWN对应的索引是event.actionIndex，而ACTION_DOWN事件里你仍然只能拿到0号指针的信息，所以循环判段pointerCount不能帮你获得所有手指的信息，必须访问getX(i)才能拿到每个指针独立的坐标。这块是新手最容易犯的错误——只盯着event.x和event.y，一遇到双指就失灵。

4.4 计分、组合连击与游戏结束判定

计分逻辑采用递增式：单次点击得1分，连续点击（相邻两次点击间隔小于400毫秒）会额外获得连击加成，连击累计超过10次时，每周期的分数变为2分。

private var comboCount = 0 private var isCombo = false private var comboElapsed = 0L private val comboTimeWindow = 400L fun addScore() { score += if (comboCount > 10) 2 else 1 scoreText = score.toString() } fun onFrameUpdate(deltaTime: Long) { if (isCombo) { comboElapsed += deltaTime if (comboElapsed > comboTimeWindow) { isCombo = false comboCount = 0 comboElapsed = 0L } } }

comboElapsed在每次有效击中被重置为0，这能保证“只要玩家连续按，连击不会断”。如果玩家有0.4秒没按，连击就清零。这里的400毫秒是一个求平衡的参数：手感好的节奏大师按钮触发区间一般是250-500毫秒，取400能让手速不快的人也能抱着“再试一下就续上”的心态玩下去，不至于因为连击频繁断裂而挫败。

游戏结束条件有两种：第一种是方块触底未被点击，第二种是点击了一个没有方块的区域（miss判定）。两种都调用gameOver()方法，这儿需要一个独立的isGameRunning标志位，让子线程在run()循环里提前退出：

fun gameOver() { isGameRunning = false // 将最终分数丢给UI层的TextView runOnUiThread { binding.tvScore.text = "最终得分: $score" } }

5. 音效、帧率优化与手感调优

5.1 SoundPool音效加载与触发出触发痛点

没有声音的钢琴块游戏就像没开声音的钢琴。音效是玩家判断“是否击中”的重要反馈源，甚至比视觉反馈更关键。SoundPool是Android上最适合短音效（低于1秒）的音频播放类，它的特点是“异步加载、延迟低、支持同时播放多个音效”——对于一个需要连续快速点击的游戏来说这三点缺一不可。

private fun initSoundPool() { val audioAttributes = AudioAttributes.Builder() .setUsage(AudioAttributes.USAGE_GAME) .setContentType(AudioAttributes.CONTENT_TYPE_SONIFICATION) .build() soundPool = SoundPool.Builder() .setMaxStreams(8) .setAudioAttributes(audioAttributes) .build() // 与某个观点相反：不能写在onCreate里，否则必须等加载完成 soundPool.setOnLoadCompleteListener { _, _, _ -> isSoundLoaded = true } soundId = soundPool.load(this, R.raw.notes_do, 1) soundId2 = soundPool.load(this, R.raw.notes_re, 1) soundId3 = soundPool.load(this, R.raw.notes_mi, 1) soundId4 = soundPool.load(this, R.raw.notes_fa, 1) }

setMaxStreams(8)的含义是同时最多允许8个音效实例播放。为什么不是更多？因为每次音效播放都会占用CPU资源，8个已经足够应付手指雨点般的点击。如果设置更大，在低端机上可能引发明显的掉帧。

需要特别提醒：SoundPool加载是异步的，第一次调用play()的时候可能音效还没就绪。isSoundLoaded这个标志就是用来屏蔽这个窗口期的——玩家刚打开游戏就能立刻点，即便不安音效也不至于崩，但有了这个标志位能避免播放无效音频的错误。

还有一个最常见的坑：在横竖屏切换时Activity重建，旧的SoundPool对象会被垃圾回收，但你依然持有它的引用，此时再调用play()会在某些设备上有概率直接闪退。可靠做法是在onDestroy()里释放所有加载的资源，再在onCreate()里重建SoundPool。

5.2 帧率监控与掉帧排查命令

游戏跑一段时间后，最影响体验的就是“感觉卡”或者“画面不跟手”。这种直觉问题要用数据来验证。Android Studio自带的Profile工具可以查看实时帧率，但它的UI对新手不够直观。更好用的办法是自己写一个帧率计算器，把FPS打出来：

private var frameCount = 0 private var lastFpsTime = 0L private var currentFps = 0f fun calculateFps() { frameCount++ val now = System.currentTimeMillis() if (now - lastFpsTime >= 1000) { currentFps = frameCount / ((now - lastFpsTime) / 1000f) frameCount = 0 lastFpsTime = now Log.d("GameFPS", "当前帧率: $currentFps") } }

这个函数放在run()循环的末尾，每1秒输出一次平均值。在模拟器上跑FPS一般只有25-35，这是正常的——模拟器依赖Host CPU做图形渲染，不代表真机水平。判断标准是拿到一台Android真机调试，运行以下命令开启CPU数据采集：

adb shell dumpsys gfxinfo com.example.pianoblock framestats

输出结果中重点关注Janky frames和Total frames两行。如果Janky frames占比超过10%，说明你的绘制逻辑里有明显的耗时操作，最常见的元凶是触摸事件处理里做了IO操作或创建了过多新对象。另一个常用排查命令是抓取主线程的卡顿堆栈：

adb shell debuggerd -b 你的应用进程号

这些命令可以帮你在玩家抱怨“卡了”之前就主动发现问题。

5.3 必调的4个变量参数与推荐区间

综合实战调试经验，钢琴块游戏手感相关的参数有4个最值得调，我列成一张表方便你对照调整：

baseSpeed建议新玩家先设250，老手再往上加。我见过有人在网上发“速度为600仍然轻松满连”的炫耀帖，这种参数对大多数人没有参考意义——它的屏幕响应能力和手指反应速度都是普通人2倍以上，不具备普适性。

调参时不要一次只调一个值然后看手感——这样你难以判断是哪个改动导致了变化。更有效的做法是用“控制变量法”：先固定其他参数，只改变tolerance，每个档位玩10分钟，记录“miss次数”和“误触次数”，形成一组对比数据，再决定去留。这比“凭感觉调”科学得多。

6. 用硬件层修复一劳永逸的手感短板

6.1 让触摸先于绘制：InputEvent与render线程的并发洞

大部分人的钢琴块到第四节就能玩，但“开始卡点不准”这个问题始终在。深挖下去会发现根源不在进程、不在卡顿，而在于Android的事件分发是同步的——用户的触摸事件经由主线程处理，而你GameView里的渲染循环跑在独立的渲染线程上。当主线程忙碌（比如界面布局的变化、垃圾回收GC）时，触摸事件的响应会延迟，从而出现“明明按了却晚了一拍”的体验。

解决思路很直接：把触摸判定也搬到渲染线程中去，让“触摸采样”和“画面更新”在同一个时钟节拍上运转。Android提供了InputEventReceiver，但直接对接它比较底层，更常见的做法是利用View.postOnAnimation()把触摸操作包装成一个“帧同步任务”：

override fun onTouchEvent(event: MotionEvent): Boolean { when (event.actionMasked) { MotionEvent.ACTION_DOWN, MotionEvent.ACTION_POINTER_DOWN -> { val x = event.x val y = event.y postOnAnimation { handleTap(x, y) // 放到下一帧开始前执行 } } } return true }

postOnAnimation的回调会由系统的Choreographer驱动，保证它在渲染线程的下一次vsync信号发出时执行。这样做真正实现了“画面更新和触摸响应步调一致”，画面的锯齿感会彻底消失，连击手感会迈上一个台阶。

注意，如果你用的是SurfaceView极速模式（setRenderMode(SURFACE_RENDER_MODE_DIRECT)），postOnAnimation依然有效，因为它是基于Choreographer而非View的绘制生命周期。这是本文中唯一一个同时适用于普通View和SurfaceView的触摸优化方案。

6.2 旋转屏幕与后台切换的恢复策略

钢琴块游戏极少被玩家旋转屏幕，但你不能不让系统处理。进入MainActivity时给AndroidManifest指定锁定竖屏：

<activity android:name=".MainActivity" android:screenOrientation="portrait" android:configChanges="orientation|screenSize|keyboardHidden" />

关键是android:configChanges这一行。它告诉系统：当横竖屏切换时不要销毁重建Activity，而是直接调用onConfigurationChanged()交付新配置。这样GRUB保存的方块坐标、分数、当前帧率统计都不会丢失。如果你不做这行声明，切一次屏游戏就从第一块开始重新玩，那谁还愿意把它放手机首屏上。

后台切换的恢复同样重要。钢琴块这类游戏不需要它进入后台时继续运作——玩家切出去回消息，回来时应该看到“游戏暂停”而不是已经GAME OVER。在onPause()中做两件事：把isRunning置false，让渲染线程优雅退出；用SharedPreferences存当前分数与方块状态。onResume()恢复状态，如果游戏之前已跑起来，直接继续；否则重新出第一块方块。

这看似是防崩溃的小事，但在多任务横行的Android生态里，它决定了你的App在用户设备上是不是一个“守规矩”的公民。直接决定你在Play商店或应用市场的评论是五星还是一星。

6.3 用adb命令做真机手感验收的检查清单

到了交付版本，你该做的不是“自己觉得不卡就行”。这里给出一套快速验收的命令组合，它们能帮你客观评估手感是否达标：

# 1. 检查GPU渲染是否达标 adb shell dumpsys gfxinfo com.example.pianoblock framestats | grep -E "Janky|Total" # 2. 捕捉原理线程卡顿痕迹 adb shell debuggerd -b $(adb shell pidof com.example.pianoblock) | head -60 # 3. 查看CPU占用是否异常 adb shell top -n 1 | grep pianoblock

重点关注两个指标：Janky帧率占比低于8%、CPU占用小于30%（在流畅设备上）。如果你发现Janky占比很高，回到上一节的frameCount代码单步FPS日志，跑十局记录日志，找出掉帧集中在哪一段游戏进度——通常是在分数超过200后加速过快导致创建了大量Block对象引发GC。

此时你会意识到，做得好的钢琴块游戏把自己伪装成一个互动工具——手在屏幕上跳舞，游戏在后台轻描淡写地计算、分配内存、清理噪音。真正制胜的法宝不是多炫的画面，而是每一帧的绝对准确与每一毫秒的不拖沓。你把这些维度处理好，即使画面全部是方块、没有动画特效，玩家也会说“这个游戏很‘跟手’”。

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