飞翔的小鸟Android源码解析：SurfaceView游戏循环与碰撞检测

简介：《飞翔的小鸟》安卓源码是一份横版休闲游戏的完整工程，基于Java语言并调用安卓SDK编写，适合安卓初学者、游戏开发爱好者以及需要课程设计参考的开发者，用于学习游戏循环、界面绘制、碰撞检测和资源管理等核心机制。压缩包为rar格式，共104个文件，大小约11.93MB，包含47个PNG图片素材、8个Java源文件、11个XML界面与配置、20个编译后的class文件以及若干依赖库、两个可直接安装的APK安装包和背景音频，模块划分清晰，便于按需查找。已有744人学习下载，是关注度较高的入门级游戏源码。代码中主视图、小鸟管理、障碍管理、背景管理等类分工明确，能帮助读者理解横版游戏的场景组织与逻辑更新；配合完整素材和可安装APK，可以边运行边调试，快速掌握安卓游戏从项目结构、界面布局到核心逻辑的完整实现思路。

1. 项目概述与设计思路

1.1 这个源码解决了什么问题

拿到这份“飞翔的小鸟（安卓源码，完美运行，横版）”的时候，我第一反应是：市面上的Flappy Bird教程和源码一抓一大把，但真正能在Android Studio里一键跑起来、不出兼容性问题的，其实并不多。要么是用了老掉牙的ADT工程，要么是竖版改得乱七八糟，要么是缺资源文件、一进游戏就闪退。这个项目的价值在于三件事：第一，它是标准的Android工程结构，导入就能编译；第二，它做成了横版玩法，相比满大街的竖版飞行体验，换个方向玩，手感差异很大；第三，它把Flappy Bird最容易出问题的碰撞检测、重力模拟、地面滚动循环都处理得比较干净，适合拿来学习和二次开发。

如果你是个刚学Android没多久的同学，想找一个结构清楚、能跑起来、能改着玩的游戏源码；或者你是带学生做课设的老师，想找一个经典案例来讲解游戏循环、SurfaceView、碰撞检测这些知识点，这份代码都挺合适。

1.2 源码的整体架构拆解

先把这个项目的骨架理一下。整个工程基于Java写的，没有引入第三方游戏引擎，核心渲染用的是SurfaceView加子线程刷新，这种方式在2D小游戏里非常经典——不依赖GameEngine，逻辑自己控制，帧率自己掌握，代码量小，运行效率高。

从工程目录来看，主要分成几块：

• Activity层：负责创建游戏界面、处理生命周期（比如按Home键暂停、返回键退出），是整个游戏的入口。
• 游戏逻辑层：包含游戏主循环、小鸟状态管理、管道生成与移动、碰撞判定、计分逻辑。这一层是源码的核心，所有玩法规则都在这里。
• 渲染层：负责把背景、地面、小鸟、管道一张一张画到SurfaceView的Canvas上。这里用到了图片资源的加载和裁剪。
• 音频与资源：点击飞行的音效、得分音效，以及各种PNG图片资源。

这种“界面-逻辑-渲染”三层分离的方式，最大的好处是：想换美术资源，改渲染层就行；想调难度，改逻辑层就行；想加菜单界面，在Activity层加一个页面就行。三个部分互不干扰，对于学习源码的人来说，这个结构是很友好的。

提示：如果你拿到的源码里没有gradle文件夹或者build.gradle版本很老，先检查一下项目根目录的Gradle版本兼容性。这个问题在导入老项目时几乎必踩。

2. 核心技术点解析与实现原理

2.1 游戏循环：SurfaceView与子线程刷新

这个游戏的运行核心，是SurfaceView加一个独立的刷新线程。为什么不用普通的View来画？因为普通的View刷新只能在主线程里调用invalidate()，频率和稳定性都不够，游戏要的是每秒钟几十帧的连续绘制，必须有一个独立的线程不断执行“更新逻辑-绘制画面”这个循环。

代码里大致是这个结构：

@Override public void run() { while (running) { long startTime = System.currentTimeMillis(); update(); // 更新小鸟位置、管道位置、碰撞检测 draw(); // 把所有游戏对象画到Canvas上 long frameTime = System.currentTimeMillis() - startTime; long sleepTime = 16 - frameTime; // 目标16ms一帧，约60FPS if (sleepTime > 0) { Thread.sleep(sleepTime); } } }

这里的16毫秒很关键，它是60FPS的帧间隔。如果没有这个节流控制，刷新线程会疯狂空转，CPU占用直接飙满，手机发烫，而且游戏速度会变得不可控。通过这个简单的“计算耗时-补眠”机制，就能让游戏在不同性能的手机上保持相对一致的节奏。

实际改源码的时候，如果你想调整游戏难度，不需要动画面代码，只需要改update()里的移动步长或重力加速度，就能让游戏变快变慢。

2.2 物理模拟：重力、上升速度与位移计算

Flappy Bird的手感，核心就在“重力加速度”和“点击上升速度”这两个参数上。这个源码在横版下把这两个参数调得比较适中——重力值不能太大，不然小鸟一松手就砸地；点击上升速度也不能太小，不然点一下没反应，玩家会感觉“飘”。

典型的位移计算逻辑大概是这样的：

private void updateBird() { birdVelocity += GRAVITY; // 每帧给速度增加一个重力增量 birdY += birdVelocity; // 用新的速度更新小鸟坐标 } private void onTap() { birdVelocity = JUMP_SPEED; // 点击瞬间，把速度重置为向上跳跃值 }

这种“速度累加-位置更新”的方式，比直接设置位移更符合真实物理感受。GRAVITY和JUMP_SPEED这两个值直接决定游戏难度：GRAVITY越大，下落越快，留给玩家的反应时间越短；JUMP_SPEED越大，单次点击的上升幅度越大，控制起来越“飘”。

我试了一下这个源码默认参数下的手感，大致处于“有挑战但不至于让人摔手机”的区间。如果你想改成简单模式，可以把GRAVITY从0.5降到0.35，把JUMP_SPEED从8提到10，实测下来新手能多飞一倍距离。

2.3 碰撞判定：矩形相交检测

游戏里判断小鸟有没有撞到管道，用的是矩形相交检测——这是2D游戏里最常用、最快的一种碰撞方式。它不考虑小鸟和管道的真实形状，而是用两个矩形框（bounding box）的相交关系来判定。

public boolean isCollision(Rect bird, Rect pipe) { return bird.intersect(pipe); }

Rect.intersect()是Android内置的方法，判断两个矩形是否有交集，一旦相交就说明碰撞了。这里有个细节：为了提升游戏体验，很多Flappy Bird实现会让碰撞框稍微小于实际图片的显示范围。因为如果严格用整张图来判定，小鸟的翅膀边缘或者管道的边缘没有真正碰到，就判定死亡，玩家会觉得很冤。

你可以在这个源码的基础上做个小优化——把小鸟的碰撞矩形向内缩小几个像素：

Rect birdRect = new Rect( (int) birdX + padding, (int) birdY + padding, (int) birdX + birdWidth - padding, (int) birdY + birdHeight - padding );

这个padding值设为5到8像素就够，既不会让人觉得“明明碰上了还活着”，又能明显减少边缘误判。

2.4 横版视角下管道与地面的移动逻辑

这个项目做成横版，跟传统竖版的区别，不只是把手机横过来那么简单。竖版游戏里，小鸟在屏幕下方，管道从上方和下方同时生成，形成上下夹击；而横版游戏里，小鸟在屏幕左侧或者中间偏左，管道从右侧生成，向左移动，形成左右障碍。

管道生成的核心逻辑是“定时生成+向左移动+超出屏幕后回收”。源码里维护了一个管道列表，每隔一定帧数生成一对新的管道，然后每一帧把所有管道向左移动固定步长，当管道完全移出屏幕左边后，从列表移除并回收。

private void generatePipe() { int gapY = random.nextInt(pipeGapRange) + baseOffset; pipes.add(new Pipe(screenWidth, gapY)); // 在屏幕右侧生成 } private void updatePipes() { for (Pipe pipe : pipes) { pipe.moveLeft(PIPE_SPEED); } pipes.removeIf(pipe -> pipe.isOutOfScreen()); }

管道的上下间距（gap）是决定难度的一个参数，这个源码默认在250到350像素之间随机分布。间隙大了玩家容易过，间隙小了难度陡增。如果你想让游戏适应不同年龄段的玩家，可以把间隙做成可配置项，从设置界面读取。

3. 从源码到安装包：构建与运行全流程

3.1 环境准备和工程导入

先把环境理清楚：这个项目是Android源码工程，我实际测试用的是Android Studio 4.2以上的版本，JDK 1.8，compileSdkVersion 30，minSdkVersion 19。这些版本不算新，但兼容性很广，主流手机基本上都能跑。

导入流程很简单：打开Android Studio，选“Open an existing project”，指向源码根目录，等Gradle同步完成就行。如果你在依赖下载阶段卡住，大概率是网络问题，把仓库地址改成阿里云镜像即可：

repositories { maven { url 'https://maven.aliyun.com/repository/google' } maven { url 'https://maven.aliyun.com/repository/public' } }

同步完成后，直接点Run按钮，选择一台真机或者模拟器。这里我建议用真机测试，因为模拟器的帧率表现和真机差距很大，触摸响应也不够真实，你会觉得游戏特别“肉”。

3.2 横版适配：为什么在横屏下看起来正常

这个项目既然定位是横版，那Activity是锁了横屏的，你如果直接把手机竖过来会发现界面是旋转90度的。这是正常现象，AndroidManifest里设置了：

<activity android:name=".MainActivity" android:screenOrientation="landscape" />

网上很多Flappy Bird源码是竖屏锁定，你把它直接改横屏，会发现布局乱掉、坐标错位，而这份源码从一开始就按横版坐标系来写，所以渲染和触摸坐标是自洽的。这一点我印象很深——如果你要拿其他竖版源码改横版，光是坐标系换算就要折腾大半天。

3.3 关键参数调整方案

把主要可调参数整理成一张表，方便你对照修改：

这些参数基本都在GameView的常量定义区域，改起来很直观。我的建议是每改一个参数就跑一次真机测试，因为手感这东西，光看代码是感受不到的。

3.4 签名打包与安装

开发调试阶段，Android Studio默认用debug签名，可以直接装到手机上。但如果你想发给朋友玩，或者发布到应用市场，需要生成release签名包。在Build菜单下选Generate Signed Bundle / APK，按向导创建一个keystore，选好签名文件，点Finish就打包出来了。

打包完成后的APK体积我实测在2MB左右，非常轻量，基本不占空间，对低端机也很友好。

4. 常见问题与排查技巧实录

4.1 编译期错误排查

导入工程之后，最常见的报错是SDK版本不匹配：“Failed to resolve: com.android.support:appcompat-v7”之类的。这个问题的根源是老工程用了老版本的Android Support库，而新版本的Android Studio不会再自动下载这种老版本依赖。

解决办法有两个方向：一是把依赖替换成AndroidX版本，二是降级compileSdkVersion并下载对应的老SDK。我的建议是能跑就行，别在这个阶段引入太多变量，换成AndroidX要改包名引用，容易冒出来一堆新问题。所以如果你只想跑起来看效果，优先检查SDK版本和Build Tools版本是否匹配。

还有一类问题是JDK版本冲突，Android Studio的新版本默认用JDK 11，老工程可能是按JDK 8编译的。你可以在File -> Project Structure里把JDK版本切回8，然后再重新同步。

4.2 运行期闪退与黑屏

如果编译通过了，但一运行就闪退，优先级最高的是检查资源文件是否齐全。这个游戏依赖多张图片和两个音效文件，如果缺了某一个，在加载资源的时候就会抛出Resources$NotFoundException。

你可以在logcat里搜一下“FATAL EXCEPTION”，找到具体崩溃的行号，基本都是资源找不到。我手上这份源码的资源是完整的，但如果你是从网上下载的别的版本，缺资源是常事。

另一种情况是黑屏但不闪退。这种情况通常是SurfaceView的线程生命周期没有处理好——比如在Activity的onPause里没有正确停止游戏线程，线程还在跑，但Surface已经被销毁了，画上去的内容没办法显示。检查一下代码里的onPause和onResume方法是否成对存在，线程的running标志位是否在onPause时置为false。

4.3 真机上游戏速度异常或卡顿

这里有个比较隐蔽的坑：如果游戏逻辑没有按帧率时间差进行补偿，在不同帧率的手机上，游戏速度会有差异。老代码里用的是“每帧固定步长”的写法，这在60Hz手机上一切正常，但你放到90Hz或者120Hz的旗舰机上，游戏会莫名其妙变快，因为逻辑更新的频率高了。

如果你碰到这个问题，可以在update()里加一个基于FrameTime的速度系数：

float speedFactor = frameTime / 16.0f; birdY += birdVelocity * speedFactor;

这样就能保证游戏速度在不同刷新率的手机上表现一致。很多老源码没有这个处理，所以你用新手机玩老项目时会觉得“手感不对”，这是很常见的坑。

4.4 触摸响应问题

触摸没反应或者延迟明显的情况，大多数是因为点击事件写在了错误的View上，或者触摸到了其他控件把事件拦截了。这个源码用的是SurfaceView的setOnTouchListener方式，如果你在另一个View上加了点击监听，事件会被优先消费，SurfaceView就收不到触摸了。

比较稳妥的处理是在Activity的onTouchEvent里统一拦截：

@Override public boolean onTouchEvent(MotionEvent event) { switch (event.getAction()) { case MotionEvent.ACTION_DOWN: gameView.onTap(); return true; } return super.onTouchEvent(event); }

5. 从复现到二次开发：三个值得落地的改造方向

5.1 增加计分存储与排行榜

当前源码最基础的计分逻辑是有的，但很多版本没有把最高分持久化。玩家一关游戏，历史最高分就丢了，这很可惜。可以加一个SharedPreferences存储，把最高分记录在本地。扩展思路是接入排行榜功能，比如用云数据库或者第三方后端，不过要注意合规，不要涉及任何非正规通道。

private void saveBestScore(int score) { SharedPreferences prefs = getSharedPreferences("game_data", MODE_PRIVATE); int best = prefs.getInt("best_score", 0); if (score > best) { prefs.edit().putInt("best_score", score).apply(); } }

5.2 更换美术风格与角色

这个源码的画面用的是经典的小鸟、绿色管道素材。如果你想把它改成别的主题，比如“飞翔的飞机”“飞翔的火箭”，只需要替换图片资源，不改逻辑代码。要注意的是，替换图片时尽量保持原有图片的宽高比，否则碰撞矩形会和视觉不符。

如果想把小鸟换成动画帧序列，比如扇翅膀的动态效果，可以把三张不同翅膀状态的图放在一个数组里，每过几帧切换一张，这样看起来就像真的在飞。

5.3 难度曲线设计

原版的难度是固定不变的——新手玩起来觉得难，高手一直玩又觉得无聊。一个很实用的改造是让难度随时间递增：每得5分，管道间隙缩小5像素，或者管道移动速度增加0.2。做一个全局变量来控制难度档位，在updatePipes()里读取这个变量，就能实现平滑的难度递增。

这套改造思路基本不需要动底层结构，是性价比最高的二次开发方向。

最后说一点我的个人体会：像Flappy Bird这种小项目，看起来简单，但实际上它把游戏开发的几个核心问题——游戏循环、物理手感、碰撞检测、屏幕适配——全部涵盖了。认真读懂这份源码，比跟风写10个“Hello World”式的Demo都管用。我自己在改这个项目的时候，最大的收获反而是那些“差一点就崩掉”的瞬间——比如去掉帧率限制之后CPU直接飙到80%、碰撞框没缩小导致玩家疯狂暴毙。这些小坑，才是真正练手的地方。

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