每年一到毕设季就有同学在群里问“Android做什么题目好”。“基于Android的音乐教学平台”这个题我当初就是冲着名字选的——看起来不冷门、又不像图书管理系统那样烂大街功能上既能碰多媒体又能碰网络还能名正言顺地画几个自定义View。真做下来才发现这题的水比想象中深光是音频播放、进度条、视频全屏这些细节就能耗掉一大半时间。这篇把整个项目从选题到落地拆开讲包括技术选型、核心模块实现、以及我踩过的几个大坑希望能给正在做类似毕设、或者想练手Android项目的人一点实在参考。1. 项目选题与整体设计别只做一个“能跑的App”1.1 为什么选音乐教学平台而不是“管理系统”先说选题。每年毕设里最不缺的就是“XX管理系统”“XX商城”这类题目不是不行而是同质化太严重。老师听了三年“图书借阅系统”看到“音乐教学平台”至少会觉得有点新鲜感。更实际的是管理系统的技术点集中在增删改查答辩时老师问“难点在哪”你可能答不上来音乐教学平台天生带几个硬骨头音频播放、视频课程、自定义钢琴键盘、练耳答题、播放进度控制每一个都能展开讲出具体问题这就解决了“答辩无话可说”的问题。从学习角度讲这类项目覆盖的面很全用户登录注册、课程列表加载、视频贴片、音乐播放、自定义View触摸事件、数据库存储、状态管理一个项目把Android开发的主流知识点全走了一遍。哪怕你不是做毕设纯粹想写一个能拿得出手的App作品这个方向也比“记账本”有说服力得多。1.2 技术选型的三轮取舍原生、语言、前后端确定做Android之后第一个绕不开的问题用原生还是跨平台。我当时的判断很简单——毕设要突出的是“Android能力”Flutter和React Native写起来虽然爽但自绘引擎、平台通信这些恰恰会掩盖你原本想展示的Android细节而且真机调试时音频焦点、视频Surface这类问题跨平台框架的处理逻辑堆了一层抽象查起来更头疼。所以定了Android原生包体小、音频链路短、权限和系统服务全在自己手上就算遇到问题也能一步步查到系统层。第二轮是语言选择Java还是Kotlin。当时我的环境里两个都支持但Kotlin的空安全机制和协程封装的网络请求开发效率真的比Java高不少。尤其是播放器状态管理和异步回调Kotlin的lambda和高阶函数写起来清爽很多。如果你还在用Java其实也能做但代码量会明显多一截。第三轮是最关键的纯本地还是前后端分离。很多毕设图省事直接SQLite存数据、不联网也能跑。但我建议至少做一个轻量后端接口哪怕是Spring Boot搭的REST API原因有二一是课程列表、曲库、测评题目这类数据天然要动态更新写死在本地既不真实也不方便演示二是答辩时“前后端联调”“接口设计”“Token鉴权”是加分项老师一听你分了端意味着你理解真实项目的协作模式。同时本地数据库做缓存和收藏这样离线也能看已加载的课程。1.3 功能模块拆分与数据库设计把整个项目拆成六个模块这是最稳的打法用户模块注册、登录、个人信息。密码用非明文存储登录后返回Token。课程模块课程列表、课程详情、章节视频、图文资料。练习模块钢琴键盘、视唱练耳、节奏练习记录每次练习数据。曲库模块曲目列表、歌曲详情、音频播放、收藏。测评模块乐理选择题、答题计时、成绩单、错题回顾。个人中心学习进度、练习统计、收藏列表、设置。数据库方面我用了Room表按业务切分用户表、课程表、章节表、曲目表、练习记录表、测评记录表、收藏表。这里有个设计细节课程表和章节表是一对多曲目表里存一个播放地址字段测评记录表里用一个JSON字段存答题明细。别小看这个JSON字段如果单独建一张答卷明细表查询是方便但插入和关联时表结构会变得很重用JSON存明细模块展示时序列化解析就行毕设这个体量完全够用。2. 核心模块实现从播放器到钢琴键盘的实战细节2.1 播放引擎选型MediaPlayer不够用换成Media3音乐教学平台最核心的就是播放能力。一开始我图省事用了MediaPlayer结果曲子播到一半想切下一首要自己维护播放队列想混着视频课程和音频曲目统一管理MediaPlayer也有点带不动。后来我换成了Media3ExoPlayer这是目前Android上主流的播放方案底层封装了MediaPlayer的很多痛点。为什么换三个原因一是它原生支持播放队列丢一个list进去自动顺序播二是流媒体地址和本地文件都能播不需要自己判断协议三是音频和视频可以共用一套Player实例状态监听接口统一。课程讲解视频用同一个引擎代码可以直接复用。我的封装方式是建一个单例的PlayerManager核心代码如下class PlayerManager(context: Context) { val player: ExoPlayer ExoPlayer.Builder(context).build() fun play(url: String) { val mediaItem MediaItem.fromUri(url) player.setMediaItem(mediaItem) player.prepare() player.playWhenReady true } fun pause() player.pause() fun resume() player.play() fun seekTo(positionMs: Long) player.seekTo(positionMs) fun release() player.release() }单例的好处是整个App里同一时间只存在一个播放器切到课程视频也好、切到曲库听歌也好不会出现两个声音同时响的尴尬场景。这里有一点特别注意Activity或Fragment销毁时一定要调用release()尤其是在视频课程页退出后不释放播放器会导致后台还在耗流量、占内存搞不好还会被系统杀进程。另外播放器的状态切换要做成状态机空闲、准备中、播放中、暂停、播放完成。每次回调里根据状态更新UI——比如缓冲时显示转圈播放完成时把进度条归零并切到下一首。Media3的Player.Listener回调里已经给了这些状态我们只是把它映射到界面逻辑上。2.2 自定义播放进度条滑动跟手、点击跳转很多同学直接用SeekBar但音乐教学中曲目动辄几分钟原生SeekBar的样式和交互都不够精致。我用自定义View画了一个播放进度控件底层是缓冲进度上层是播放进度中间一个圆形滑块。这个控件做起来其实不难关键在触摸事件。触摸处理的思路是按下时记住当前位置并停止播放进度刷新拖动时随时间变化移动滑块抬起时根据滑块位置计算出目标秒数并seekTo。为什么要暂停播放进度刷新如果不暂停你一边拖播放进度一边往前跳界面会来回拉扯体验很差。实现上可以用一个布尔变量isDragging来标记回调里判断这个标记再决定要不要刷新进度。原生的SeekBar其实也支持触摸监听但自定义View在UI样式控制和点击跳转上更自然。点击跳转的需求是“用户点了进度条某个位置直接跳到对应时间点”原生SeekBar默认点哪儿跳哪儿但它跳的粒度取决于max值设置精度不够自定义View里getX()直接除以总宽度再乘以总时长精度就能精确到秒。我画了一个双进度条先draw一个灰色底再画缓冲的浅色层最后画播放进度的高亮层滑块用一个圆形Canvas绘制触摸判定区域要放大到40dp以上不然手指不好点。2.3 钢琴键盘与练耳练习自定义View画一个能点的琴这个功能是音乐教学平台里最有辨识度的一块。需求很简单界面上显示一组钢琴键用户点哪个键就播放对应的音符同时用做视唱练耳的基础练习。我用自定义View直接画键盘没有用任何图片资源这样各种屏幕尺寸都能自适应。布局算法是经典的白键黑键模型白键数量固定比如一个八度7个白键每个白键宽度总宽度/白键数白键高度控件高度黑键宽度取白键宽度的0.6倍高度取白键高度的0.6倍位置嵌在两个白键的边界处。绘制时先把白键画完再画黑键——注意黑键要覆盖在白键上面所以黑键必须在白键之后绘制否则就被遮住了。触摸判定是关键为每个键建立一个Rect按下时遍历这些Rect判断MotionEvent的坐标落在哪个键范围内。这里有个细节黑键Rect比白键Rect小用户按在两个白键中间靠近顶部的位置时应该优先命中黑键所以遍历顺序要先查黑键再查白键。音符反馈我用了SoundPool预加载一组钢琴音色文件到内存按键时触发播放。SoundPool适合短音频的实时播放比MediaPlayer延迟低得多钢琴这种交互场景正好用得上。音高对照表就是一组频率或者音色资源的映射按下什么键播放什么音这个逻辑很简单但练习“听音辨音”时很有用用户点击琴键听声音、再看对应的简谱标记训练耳朵对音高的敏感度。3. 实操过程从零搭建到可演示项目3.1 工程初始化与架构分层工程用Android Studio创建我用的是Kotlin语言minSdk设为24targetSdk设为34。这里有一个经验之谈targetSdk别设太低不然真机跑的时候系统会弹兼容性提示甚至直接限制文件访问也别盲目追最新有些第三方库还没适配新版SDK编译会报一堆错。24起步是因为覆盖了绝大多数现役手机老机子也能装。包结构我是按职责分的网上也有各种MVP、MVVM模板我觉得毕设项目不用过度设计但有个清晰分层很有必要data包网络请求、Room数据库、数据仓库model包实体类ui包各Activity、Fragment、Adapter按功能页分子包common包工具类、自定义View、接口回调工程里我同时用了ViewModelLiveData做页面数据管理Room做本地缓存Retrofit做网络请求ViewBinding替代了findViewById。ViewBinding这个真的强烈推荐It布局里写错一个R.id.xxx编译期就报错不用再等到运行的时候才崩溃。3.2 网络层与数据缓存登录、Token、统一响应前后端分离定了之后接口设计要统一。我定的响应体结构是{ code: 0, message: success, data: { ... } }Retrofit的Service接口里返回类型用ResponseBody包一层然后自定义一个Result 类做泛型解析时判断code是否为0非0时把message弹给用户。登录接口成功后会把Token存在SharedPreferences里之后每次请求都在OkHttp的拦截器里自动拼接Authorization头这样请求代码不用每个接口都传一遍token。缓存策略分两层第一层是网络上来数据后直接写进Room作为缓存副本第二层是打开App时先读本地教室数据再请求网络刷新页面。你可能会问为什么不直接一个请求搞定因为这几年音乐教学App最常见的使用场景是用户在地铁上、信号不稳的地方先读本地能秒开再等网络刷新体验明显更顺。测评题这类更新频率高的数据就只走网络不做缓存保证用户拿到的是最新试卷。3.3 关键页面实现首页列表、课程详情、答题计时首页课程列表用RecyclerView加分页加载。上拉加载更多时用一个布尔变量isLoading防止重复请求每次翻页后返回下一页数据。很多新手在这里会犯一个错直接addAll把数据加进去结果快速滑动时出现重叠或跳位。正确做法是在Adapter里构造一个全新的数据listnotifyItemRangeInserted这样RecyclerView的动画和视图回收调度才不会乱。课程详情页是整个项目里最费心思的页面。顶部是视频播放器下面是一个章节列表。点击列表里的章节视频区切换播放地址并自动播放。这里有个交互细节切换章节时要重置播放器的进度条、标题、播放按钮状态。如果之前看到一半这边也要保存每个章节的播放进度下次进入时直接续播。我用Room建了个学习进度表key是用户ID加章节IDval是最后播放时间点进入页面时先读这个表再seekTo。答题页我用了系统自带的倒计时方式整体考试30分钟页面上一个全局计时器每道题做单选做完点下一题。比较坑的是“用户中途退出答题页再进来”这种场景如果数据全部在内存里一退出就没了。我的方案是用ViewModel持有当前答题状态因为ViewModel在配置变更和销毁前能保留数据更稳妥的是同时在每次切换题目时把答题进度写进Room退出后重新进入页面时询问“是否继续上次答题”这也算个加分功能。4. 常见问题与排查技巧我在调试中踩过的坑4.1 存储权限为什么写文件时总报“Operation not permitted”这是Android高版本适配最容易踩的坑。早期应用可以直接往/storage/emulated/0/目录下写任意文件但从Android 11开始强制分区存储应用不能直接访问外部存储的共享目录哪怕是曾经的“合法路径”也一样会被拒绝。我当时下载乐谱文件、缓存离线音频时代码里直接写了绝对路径真机上跑起来一直报权限错误log提示“Operation not permitted”查了半天才知道是分区存储的锅。正确的做法分两种如果只是App自己用的数据直接写应用专属目录也就是getExternalFilesDir()或者filesDir这个目录不需要任何存储权限卸载App时也会自动清除如果要导出给用户比如保存一份练习成绩单到“下载”目录那就要通过MediaStore API或者系统文件选择器SAF让用户授权一个位置再用Uri写入。这里顺便提一嘴/storage/emulated/0/Android/data/包名/这样的路径网上很多旧代码还在用在新系统上坑多最好别碰。如果你只是为了调试方便把图片、音频暂时放到“项目下面的assets目录”反而是最简单的方式缺点是不能动态更新。4.2 音频焦点与后台播放来电话之后播放器“哑了”做的过程中发现一个场景用户正戴着耳机听曲库里的一首歌突然来了个电话通话结束后继续播放但声音却出不来。排查后定位到是音频焦点AudioFocus的问题。Android系统里同时只允许少数几个应用持有音频焦点电话、语音通话这类场景会抢占焦点。如果应用没有按流程处理就可能在失去焦点并恢复后没有重新申请。我的处理方式是在播放器封装里加音频焦点管理App开始播放前请求焦点播放或暂停时切换焦点被其他应用打断时在onAudioFocusChange监听里做出响应。代码大致这样audioManager.requestAudioFocus( audioFocusChangeListener, AudioManager.STREAM_MUSIC, AudioManager.AUDIOFOCUS_GAIN )监听回调里分成三种情况拿到焦点就正常播放、失去焦点但允许“短暂声音”比如导航提示就降低音量、完全失去焦点就暂停。把这几段逻辑补进去后来电话、闹钟、微信语音这些场景都不会再卡声音。另外我还接入了MediaSession这样锁屏后通知栏能看到播放状态用户不用打开App也能暂停切歌这一点在答辩演示时特别亮眼。4.3 视频黑屏与Surface冲突Activity销毁之后画面不见了课程视频用的是Media3播放时页面上要放一个PlayerView。踩坑发生在“点击视频全屏、横过来播放、再退出”这条链路上。进全屏时我重建了Activity结果重新回到页面时视频画面黑屏但声音还在。为什么因为Player实例还在但新Activity的Surface和旧Player绑定的Surface不是同一个画面就丢了。后来解决思路分两步第一步视频播放在Activity里做切换全屏时不要把Activity销毁重建而是在同一个Activity里动态改布局方向第二步所有播放状态播放进度、是否播放、当前曲目都保存在PlayerManager这个全局单例里界面只是“展示”这些状态不负责“保存”状态。这样无论Activity怎么重建Player不释放画面就不会断。如果真遇到黑屏优先检查PlayerView的Surface是不是重新绑定了。4.4 崩溃与内存抖动列表大图用不好OOM离你不远音乐教学平台里课程封面、曲库专辑图都要加载网络图片。图片加载我用的Coil加载已保存的图片前还做了一遍压缩。但是图片加载大图和列表页滑动翻页时内存会飙升搞不好OOM。后来我切到GlideGlide有一个最大的优势是在这些图片视图中接入生命周期界面不可见时暂停加载请求可见时恢复。同时把RecyclerView里用到的图片尺寸固定下来加载时直接指定宽高避免为大图分配多余内存。还有一个细节列表里的图片不要直接用原图URL后端返回时生成一个缩略图地址列表用缩略图详情页用原图这样滑动流畅度会明显提升一个档次。4.5 依赖冲突和版本号混乱gradle sync折腾一整天项目引入了Media3、Room、Retrofit、Coil、ViewBinding结果gradle构建时一会儿报“Duplicate class”一会儿报“dependency to a newer version”。排查下来大多是因为各个模块对底层库版本要求不一致。经验是所有第三方库尽量写在同一个地方集中管理不要一个依赖一个版本散落各处。我后来在项目的gradle文件里写了一个版本目录把重点库版本号统一管理全部对齐。另外遇到“Duplicate class”时别慌多半是同一个库被不同传递依赖引入了双份检查一下用到的库有没有互相绑定的情况或者直接升级版本不兼容的一方就会合并掉。问题原因解决文件写入报“Operation not permitted”Android 11分区存储限制外部目录用应用专属目录或MediaStore来电后继续播放没声音未处理音频焦点requestAudioFocus 监听回调全屏后视频黑屏有声音Activity重建导致Surface不匹配不重建Activity全局管理Player列表滑动卡顿/OOM图片过大或未绑定生命周期Glide缩略图暂停不可见加载gradle sync失败依赖版本冲突统一版本目录升级冲突库写在最后源码是参考自己敲一遍才是自己的做这套项目前后花了两个多月真正难的不是某一块功能而是把播放器、视频、题库、自定义控件揉在一起还能稳定跑。拿到源码参考可以省很多事但我的建议是别直接“跑起来就交”——老师问“你这个进度条怎么做”的时候如果你连onTouchEvent里的down事件处理都没看过那就是灾难。教给大家一个小方法拿到源码先把日志打穿从入口Activity开始打Log跟着用户体验点一遍你就会发现项目真正的骨架其实就那么几条线。后续想扩展的话可以加AI音准评测、教师端后台管理、这一题还能写更多花样但这个质量交付一定足够做一份漂亮的毕业设计了。