简介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建议设在21Android 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 version1.0 encodingutf-8? FrameLayout xmlns:androidhttp://schemas.android.com/apk/res/android android:idid/gameContainer android:layout_widthmatch_parent android:layout_heightmatch_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 方块的数据结构与生成规则每一块的逻辑可以用一张数据表来描述——它是整个游戏逻辑的最小单元字段类型说明colInt所在列0-3yFloat当前顶部的Y坐标heightFloat方块高度isPressedBoolean是否已被点击消除用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初始下落速度px/s250-350难度陡增反应时间短过于轻松无挑战speedStep每10分加速量px/s1.5-3.0后期速度爆炸后期节奏平淡tolerance点击判定容差px80-150误触概率高打击感弱comboTimeWindow连击窗口ms300-500连击难度低连击难维持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:screenOrientationportrait android:configChangesorientation|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。此时你会意识到做得好的钢琴块游戏把自己伪装成一个互动工具——手在屏幕上跳舞游戏在后台轻描淡写地计算、分配内存、清理噪音。真正制胜的法宝不是多炫的画面而是每一帧的绝对准确与每一毫秒的不拖沓。你把这些维度处理好即使画面全部是方块、没有动画特效玩家也会说“这个游戏很‘跟手’”。本文还有配套的精品资源点击获取