简介这是一个安卓开发课程设计项目实现了一款音乐播放器应用并附带界面图片展示。资源来自大三学生高分通过的课程设计评审分98分适合计算机相关专业学生用于期末大作业、课程设计或项目实战练习。zip压缩包共96个文件其中包含33个xml界面布局与配置、21个java业务逻辑源码、多种png/jpg/webp图片资源、4个mp3测试音频以及Gradle构建脚本等包体约29.09MB。项目按照Android Studio标准结构组织包含gradle配置文件、app源码目录、res资源目录等可直接导入开发工具运行调试Java源码覆盖播放器核心功能与界面交互xml文件对应各页面布局图片与mp3资源便于快速体验与展示整体可读性和复用性较好。目前已有191人学习下载对于需要完成类似移动开发作业或入门Android项目实践的学习者具有一定的参考与借鉴价值。1. 课程设计里被低估的 Android 音乐播放器难在哪期末要交的安卓课设里音乐播放器是出现频率最高的题目之一但同时也最容易做成“能响就行”。很多同学把静态页面上放个 MediaPlayer点一首歌能播就以为完事结果答辩时老师一提问就露馅播放后 Activity 一退音乐就断、列表数据是写死的假数据、封面加载用了 Glide 却不开网络权限、切歌时进度条乱跳。这个高分项目真正拉开差距的地方不在于播放器本体而在于你能不能把它做成一套完整的、经得起追问的本地音乐播放闭环扫描 SD 卡真实音乐文件、用前台 Service 保活播放、SeekBar 进度同步、通知栏可控、图片资源正确展示、并且适配 Android 11 以后的存储权限变化。接下来按这个思路把一条能跑通、能答辩、能加分的完整实现路径拆开讲你跟着做出来的东西和网上那些贴代码的demo不是一个段位。2. MediaPlayer 与前台 Service 组合音乐播放器的播放架构选型课程设计里见到最多的翻车写法是把 MediaPlayer 直接丢在 Activity 里界面还在音乐就在退回桌面或者锁屏Activity 一销毁音乐就停。更隐蔽的问题是在模拟器上测不出性能消耗一到真机连续切歌就出现三五秒的卡顿。要拿高分播放器架构至少要立住一个原则播放逻辑必须和 UI 生命周期分离而 Android 官方给的标准做法就是用 Service 持有 MediaPlayer服务跑在后台Activity 只负责发消息和观察状态。2.1 为什么要用前台 Service 而不是普通后台 ServiceAndroid 8.0 之后系统对后台 Service 的约束非常明确应用处于后台几秒内后台 Service 就会被系统回收而声音播放属于用户能感知的持续性任务,必须写成前台 Service 并显示一条通知才能让播放进程稳定驻留。课程设计里如果你在 onDestroy 里 startService在 Android 12 以上模拟器直接用 crash,就是因为忽略了这一层。我一般会让项目里定义 PlayService 继承 Service在 AndroidManifest 中声明android:foregroundServiceTypemediaPlayback这样既能过系统检查答辩时也能顺带讲清楚前台服务类型这个 Android 9 以后引入的概念。项目不大不需要引入 MediaBrowserServiceService Binder 前台通知已经足够应付课设演示。2.2 最小可用的 PlayService 骨架代码先给一个能直接放进项目的 Java 版骨架它比高技术含量更重要的是结构清楚答辩时每行都说得上用途public class PlayService extends Service { private MediaPlayer mediaPlayer; private final IBinder binder new PlayBinder(); public class PlayBinder extends Binder { PlayService getService() { return PlayService.this; } } Override public void onCreate() { super.onCreate(); mediaPlayer new MediaPlayer(); // 使用 setAudioAttributes 替代已废弃的 setAudioStreamType mediaPlayer.setAudioAttributes( new AudioAttributes.Builder() .setContentType(AudioAttributes.CONTENT_TYPE_MUSIC) .setUsage(AudioAttributes.USAGE_MEDIA) .build()); } Override public int onStartCommand(Intent intent, int flags, int startId) { startForeground(NOTIFICATION_ID, buildNotification()); return START_NOT_STICKY; } Override public IBinder onBind(Intent intent) { return binder; } Override public void onDestroy() { if (mediaPlayer ! null) { mediaPlayer.release(); mediaPlayer null; } super.onDestroy(); } }这段代码里有三个答辩一定会被追问的点先说清楚。onStartCommand返回START_NOT_STICKY表示服务被系统杀掉后不自动重建——音乐播放这种场景用户如果手动清掉了后台你自动重启反而体验差换成START_STICKY是另一种策略适合必须重新拉起继续跑的任务但课设演示状态不需要。startForeground的调用时机也有讲究onCreate 里只初始化 MediaPlayeronStartCommand里才拉起前台通知这样保证首次 bind 和 start 两种启动方式都能把通知带上不会出现服务活着但没进前台的警告。setAudioAttributes是 API 21 以后替代setAudioStreamType的新接口指定USAGE_MEDIA表示这是媒体播放音量调节时按媒体音量走和闹钟铃声互不干扰。2.3 Activity 和 Service 之间怎么通信服务在后台跑界面进度条和切歌按钮要操作它最常见方案是bindService拿到 Binder 后直连调用。但你要注意bindService和startForeground是两条独立的启动路径。只在 Activity 里 bind不调用startForeground服务照样会被系统回收正确处理是同时调起 start 和 bind或者用bindService之后在 Service 连接成功时补一次startForeground。下面是初始化代码的关键部分private PlayService playService; private ServiceConnection connection new ServiceConnection() { Override public void onServiceConnected(ComponentName name, IBinder service) { PlayService.PlayBinder binder (PlayService.PlayBinder) service; playService binder.getService(); // 拿到服务后立刻恢复界面状态防止转屏后进度丢失 bindSuccess true; } Override public void onServiceDisconnected(ComponentName name) { playService null; } }; Intent intent new Intent(this, PlayService.class); startForegroundService(intent); // Android 8 以上必须用这个 bindService(intent, connection, Context.BIND_AUTO_CREATE);startForegroundService这个方法名经常有人写错它是 API 26 引入的带前台承诺的启动,系统要求你在五秒内必须调用startForeground否则会抛ForegroundServiceDidNotStartInTimeException。这也是热销代码库里最常见的低版本崩溃点旧代码只写startService直接放到 API 26 以上的真机就崩。BIND_AUTO_CREATE表示绑定不存在时自动创建服务这样 bind 和 start 同时发生时两者共用同一个 Service 实例不会出现绑定的是一个、启动的是另一个的诡异状态。2.4 播放、暂停、切歌方法里的细节两个高频坑prepare()同步放歌时界面抖动和数据源复用后不重置状态。我一般这样处理public void playSong(String path) { try { mediaPlayer.reset(); mediaPlayer.setDataSource(path); mediaPlayer.prepare(); // 本地文件路径同步准备够用不必上 prepareAsync mediaPlayer.start(); // 播完后自动切下一首的监听要在这里重新设置 mediaPlayer.setOnCompletionListener(mp - playNext()); } catch (IOException e) { // 文件被删或路径无权限时打日志UI 层做 toast 提示 Log.e(PlayService, play failed: path, e); } } public void pause() { if (mediaPlayer.isPlaying()) { mediaPlayer.pause(); } } public void seekTo(int progress) { mediaPlayer.seekTo(progress); }逻辑说明就一条每次setDataSource之前必须reset()不然重复播放不同歌曲时会报IllegalStateExceptionprepare()对本地文件来说足够平滑只有网络流媒体才需要prepareAsync防止 ANR。seekTo(progress)传入的是毫秒不是秒UI 层传过来的一定要乘以 1000这是进度条乱跳的头号原因。3. 扫描本地音乐与图片展示Android 11 存储权限适配是重中之重课设第 2 章把播放架构立住第 3 章要应付也是评审最爱的追问方向你的音乐列表是哪来的图片从哪读的如果答案写死在数组里这一题直接扣分不少。这章节就把读真实文件、展示真实封面、适配 Android 11 以后的分区存储一次讲透。3.1 在 Android 13 上用 MediaStore 查音乐文件很多课程设计项目还把 targetSdkVersion 定在 28 左右一到新模拟器都安装不上。这套实现的正确姿势是 targetSdk 33 或 34运行时申请READ_MEDIA_AUDIO权限然后通过 MediaStore 查询系统媒体库。下面是查询代码String[] projection { MediaStore.Audio.Media._ID, MediaStore.Audio.Media.TITLE, MediaStore.Audio.Media.ARTIST, MediaStore.Audio.Media.DURATION, MediaStore.Audio.Media.DATA }; String selection MediaStore.Audio.Media.IS_MUSIC ! 0; Cursor cursor getContentResolver().query( MediaStore.Audio.Media.EXTERNAL_CONTENT_URI, projection, selection, null, MediaStore.Audio.Media.TITLE ASC);注意projection里没查ALBUM_ID是因为后面加载封面有单独方案IS_MUSIC ! 0这个条件能过滤掉录音、铃声、通知音只留音乐文件DATA字段在未来 Android 版本中会逐步收窄读取权限但作为课设中使用没有问题——如果你想要更稳的写法改用MediaStore.Audio.Media.DISPLAY_NAME结合ContentResolver.openFileDescriptor也能实现。DURATION的单位是毫秒UI 层格式化成mm:ss时不乘 1000 是常见错误。3.2 Android/data 目录为什么读不到content:// 和 file:// 之争热门检索词里有一大堆content://com.ss.android.uri.key/external_root/android/data/...、file:///storage/emulated/0/android/data/...之类的报错这其实是同一个问题的不同形态Android 11 分区存储后应用不能直接用 File 路径去读其他应用的Android/data目录file://Uri 在分享和读取时也大概率被拦截。课设的正确位置是读自己的目录和自己能访问的公共媒体目录。扫描到的音乐文件全部来自 MediaStore 的查询结果不需要手工拼路径去Android/data里找东西。如果有图片展示需求可以从歌名或歌曲路径找同目录专辑封面的替代方案用MediaStore.Audio.Albums查ALBUM_ART字段更规范Uri albumArtUri ContentUris.withAppendedId( Uri.parse(content://media/external/audio/albumart), albumId);这个content://media/external/audio/albumart是系统提供的标准封面访问协议。万一查询不到封面就回退到一张默认专辑图不要用 File 碰运气读私有目录那个在新系统上基本必败。3.3 Glide 加载封面和 RecycleView 图片展示的细节图片加载直接选 Glide它天然支持 content Uri不需要先转成 Bitmap 再传 ImageView 绕远路。音乐列表页长这样class SongAdapter extends RecyclerView.AdapterSongAdapter.ViewHolder { private ListSongBean songs; Override public void onBindViewHolder(ViewHolder holder, int position) { SongBean song songs.get(position); holder.title.setText(song.getTitle()); holder.artist.setText(song.getArtist()); holder.duration.setText(formatDuration(song.getDuration())); // 有封面就加载没有就放默认图Glide 自动处理 content uri if (song.getAlbumArtUri() ! null) { Glide.with(holder.itemView.getContext()) .load(song.getAlbumArtUri()) .error(R.drawable.ic_default_cover) .placeholder(R.drawable.ic_default_cover) .centerCrop() .into(holder.cover); } else { holder.cover.setImageResource(R.drawable.ic_default_cover); } } }placeholder和error两个占位图参数在该场景里是必需的本地媒体库中很多音频文件没有内嵌封面Glide 加载失败时若没有 error 图列表会闪一下空白图片很显眼答辩时容易被一眼挑出瑕疵。centerCrop()保证不同尺寸的封面图在 ImageView 里铺满不变形列表项视觉更整齐。3.4 图片展示做网格视图时的内存尺度如果优化成 GridView 展示全部封面分页或限制条目数量很有必要。学习阶段曾在一台 6GB 内存真机上直接加载 600 张封面图Glide 虽然不崩但快速滑动掉帧非常明显。控制手段是让 GridLayoutManager 的 spanCount 等于 3同时图片请求加.override(300, 300)让 Glide 直接按小尺寸加载// 网格页数据只取前 200 条配合 .override 控制内存占用 ListAlbumBean albums queryAlbums(); if (albums.size() 200) { albums albums.subList(0, 200); }.override(300, 300)是 Glide 的高频技巧它不只是缩小了显示而是直接减少了解码后的 Bitmap 内存占用一张 2000×2000 的原图压到 300×300内存占用直接下降约 44 倍。这个细节写进课设报告里比写使用了图片加载框架值钱得多。4. 进度条与播放状态同步音乐播放器 UI 层最难写顺的一块课设答辩现场最常见的翻车画面歌曲已经开始播了进度条不动或者拖动进度条手一松又跳回原位。这不是 MediaPlayer 的问题是你不会用 Handler 同步 UI 和 Service 状态。进度条和播放状态联动是音乐播放器 UI 层的真正难点得分重点也在这里。4.1 用 Handler 循环刷新 SeekBar 进度进度条同步我一般放在 Activity 的 onResume 里启动一个 Runnable刷新频率设在 500ms 到 1s 之间刷新太快会频繁触发 UI 重绘功耗增高太慢则进度条看起来一跳一跳体验不佳。500ms 是课程设计里最不容易被答辩老师挑刺的值private final Handler handler new Handler(Looper.getMainLooper()); private final Runnable progressRunnable new Runnable() { Override public void run() { if (playService ! null playService.isPlaying()) { int position playService.getCurrentPosition(); int duration playService.getDuration(); seekBar.setMax(duration); seekBar.setProgress(position); currentTimeText.setText(formatDuration(position)); } handler.postDelayed(this, 500); } };每轮刷新都调用setMax(duration)是保险做法因为歌曲切换后总时长会变只用一次 setMax 的话进度条比例就错了。formatDuration(position)把毫秒转成 mm:ss。另一个细节是postDelayed写在 Runnable 内部而不是外部确保只有run被执行后才安排下一次刷新尽量减小 Handler 消息队列积累。注意在 onPause 里要移除这个 RunnableOverride protected void onPause() { super.onPause(); handler.removeCallbacks(progressRunnable); }如果不移除进入后台的 Activity 会继续每 500ms 重绘一次进度条Logcat 里能看到大量Choreographer掉帧警告。这也是答辩老师用你切到桌面后代码还在跑吗这条问题来判断水平的隐藏考点。4.2 SeekBar 拖动时避免刷新冲突拖动进度条的手感问题出自手指按在进度条上时Handler 还在按原进度刷新两边互相拉扯。正确解法是加一个布尔标记位isTrackingTouchseekBar.setOnSeekBarChangeListener(new SeekBar.OnSeekBarChangeListener() { Override public void onProgressChanged(SeekBar seekBar, int progress, boolean fromUser) { if (fromUser) { // 拖动过程中实时显示预览时间但不真的 seek避免卡顿 currentTimeText.setText(formatDuration(progress)); } } Override public void onStartTrackingTouch(SeekBar seekBar) { isTrackingTouch true; handler.removeCallbacks(progressRunnable); } Override public void onStopTrackingTouch(SeekBar seekBar) { isTrackingTouch false; playService.seekTo(seekBar.getProgress()); handler.post(progressRunnable); // 立刻刷新一次 } });这套逻辑的特点是onProgressChanged里只改文字、不执行seekTo因为拖动过程中会高频触发回调每次执行 MediaPlayer.seekTo 会产生大量磁盘 IO 和音轨重定位连续拖动时明显听到爆音。真正的 seek 只在松手那次onStopTrackingTouch里执行一次效果和音乐 App 完全一致。4.3 播放按钮状态与各界面同步Service 播到下一首时Activity 的暂停/播放按钮图标要及时变成正确的状态。至少要有两张状态图播放中显示暂停图标暂停时显示播放图标。记录一个对应的列表页高亮项// 播放状态回调里做两件事更新中间按钮 更新列表高亮 private void refreshPlayState(int currentIndex) { ivPlayPause.setImageResource(isPlaying ? R.drawable.ic_pause : R.drawable.ic_play); if (currentIndex 0 adapter ! null) { adapter.setCurrentPlayIndex(currentIndex); } }上一首/下一首的边界要处理歌曲列表只有三首时下一首要循环回第一首而不是走到 -1 或者越界空指针。这里代码控制在列表长度 0 才允许切歌空列表的页面就不会因为点击按钮崩掉。4.4 通知栏控制与生命周期异常收尾前台通知必须带有可用的上一首、暂停/播放、下一首三个按钮这是音乐播放器的通用预期功能。用 NotificationCompat.MediaStyle 最方便Notification notification new NotificationCompat.Builder(this, CHANNEL_ID) .setSmallIcon(R.drawable.ic_music) .setContentTitle(songTitle) .setContentText(songArtist) .setContentIntent(pendingIntent) .setVisibility(NotificationCompat.VISIBILITY_PUBLIC) .addAction(R.drawable.ic_prev, 上一首, prevPendingIntent) .addAction(R.drawable.ic_play, 暂停/播放, playPendingIntent) .addAction(R.drawable.ic_next, 下一首, nextPendingIntent) .setStyle(new NotificationCompat.MediaStyle() .setShowActionsInCompactView(0, 1, 2)) .build();setShowActionsInCompactView(0, 1, 2)表示在锁屏这样的小空间区域三个操作按钮也完整显示否则默认可能被折叠。PendingIntent 需要按 0、1、2 的不同 requestCode 分别创建避免 Intent 复用导致点击任意按钮都触发同一个操作。Service 里onDestroy要同时stopForeground和stopSelf不然通知栏残留一个幽灵播放通知被老师看到会觉得项目收尾不严谨。5. 让课程设计项目更像产品的收尾技巧与答辩验证清单前面把架构和核心页面的逻辑都写完了但拿高分的项目往往不只是代码能跑而是演示时所有小地方都没有漏洞。这一章集中给三个能立竿见影的提升点外加一个答辩前必过的验证清单全部是关于已验证和可操作细节的补充直接照着做就行。5.1 增加列表点击连续播放和异常文件点击保护列表的 onItemClick 不能把点击后做什么只写在播放一首歌的字面上,点击顺延处理逻辑要把播放不工作的问题都纳入考虑。常见处理方式是封装playOnClick(position)private void playOnClick(int position) { if (position 0 || position songList.size()) { return; } SongBean song songList.get(position); if (song.getPath() null || !new File(song.getPath()).exists()) { Toast.makeText(this, 文件不存在或已被移除, Toast.LENGTH_SHORT).show(); return; } playService.playSong(song.getPath()); refreshPlayState(position); }这段保护代码带了两个判断位置越界和文件真实性。因为本地媒体库有可能在列表读取后音乐文件被用户在文件管理器里删掉如果直接播放会在 Service 层抛 IOException。在 UI 层提前拦截Toast 一句文件不存在或已被移除比 Logcat 里刷一行红色 stacktrace 好太多。5.2 增加迷你播放条和页面联动底部固定一个迷你播放条显示当前歌曲名、封面小图和播放/暂停按钮能让界面的完成度立刻比普通课设高一大截。实现方式是在主布局底部加一个 LinearLayout默认visibilityGONE第一次播放成功时改成 VISIBLE状态同步时更新封面和歌名。使用 CoordinatorLayout 时建议把它放在 AppBarLayout 之外、Fragment 容器之下避免被手势冲突顶掉——这也是你搜索协调布局banner或底部栏滑动冲突时高频出现的问题。5.3 答辩演示前验证清单正式演示最容易出事的顺序是模拟器权限弹窗、耳机插入、息屏锁屏、快速切歌。按这个顺序检查检查项操作方式预期结果运行时权限首次启动拒绝音乐权限再点击扫描有合理提示不崩溃前台服务播放后按 Home 键通知栏有播放通知音乐不中断进度同步拖动到歌曲 1/2 位置松手播放位置立即跳转耳机拔插播放中拔出耳机音乐暂停不继续外放快速切歌3 秒内连续点下一首不崩溃不重复播放同一首列表刷新播放中返回列表再点另一首当前图标同步后及时刷新最后一行不是废话多花半小时做一份.md格式的 README写清楚如何导入 Android Studio、最低 API 是多少、哪些机型验证过、几个关键类各自负责什么实现分包合理的话老师会把你的评分和能直接二次开发放在同一档。做课设拿高分靠的从来不是炫技代码而是别人掉坑你没有掉坑的完整度。本文还有配套的精品资源点击获取