简介：这是一份基于Android Studio开发的音乐播放器完整工程，面向安卓初学者、移动应用开发课设学生，解决从界面搭建到后台播放的常见难点。项目综合运用UI布局设计、SharedPreferences数据存储、Activity页面跳转、Service后台服务、MusicPlayer播放控制及ListView列表展示等知识点，适合作为入门实战项目。资源共1040个文件，以XML布局、Java源码、Gradle构建脚本、JSON配置文件为主，同时包含可安装的APK、图片素材与运行日志文件，整体压缩包约216.83MB，目录结构完整清晰。目前已有9264人学习下载。通过这份资源可获得可直接编译运行的Android Studio项目源码，配合配套博文中的讲解，能深入理解音乐列表与播放服务的协作逻辑，快速上手修改并完成自己的音乐播放器课设或练手项目。
1. 音乐播放器起步：这个安卓项目到底值不值得你下载
先把话说在前面：如果你正在做安卓课设，或者刚学完 Activity 和 RecyclerView，正愁找不到一个能跑通的完整项目，那这个「Android Studio 实现音乐播放器」的源码包，大概率能让你少熬两宿。它不是一个能跟网易云比功能的商业应用，而是一个把「本地音乐扫描、播放控制、后台播放、通知栏切歌」这些核心链路全部打通的教学型项目，代码结构足够干净，改起来也不至于一头雾水。
我拆过不少号称「小白必看」的安卓项目，说实话大多数是把一堆第三方库堆上去，点开能跑，但让你改个功能就原地爆炸。这个播放器项目的优势在于它没有过度封装，MediaPlayer 怎么用、Service 怎么保活、RecyclerView 怎么绑定数据，每一步都能在代码里找到对应位置。对你来说，它的价值不只是「交作业」，而是你第一次把安卓四大组件里的 Service 和 Activity 真正串起来——这是移动应用开发里躲不开的主线任务。适合谁？适合手里有 Android Studio、愿意跟着改代码而不是纯复制的安卓初学者，以及想快速出一版课设 demo 的同学。
2. 把播放逻辑拆成 Service + Activity：为什么这样选
2.1 直接写在 Activity 里会翻车
很多新手拿到项目的第一反应是：播放按钮一点，MediaPlayer 在 MainActivity 里 start() 不就行了吗？对，前 30 秒确实行。但你按一下 Home 键切到微信回个消息，再切回来，音乐可能就断了——不是可能，是大概率断了。原因很简单：Activity 在不可见时可能被系统回收，即使没被回收，屏幕旋转、配置变更导致的 Activity 重建也会让 MediaPlayer 对象失效。
所以合格的播放器项目，播放逻辑几乎不会直接活在你看到的那个页面上。这个项目的做法是把 MediaPlayer 实例放进一个 Service 里，Activity 只负责发指令：播放、暂停、切歌、调进度条。Service 在后台持有播放状态，Activity 在前台刷新界面，两者用bindService建立连接。这样做的好处是，就算你退到桌面，音乐照样在 Service 里跑，系统也给你一个「正在运行」的标识，而不是直接掐掉。
2.2 Service 骨架：绑定、生命周期、接口定义
先看这个项目里 Service 的骨架代码，它定义了一个MusicService，核心逻辑都在里面：
public class MusicService extends Service { private MediaPlayer mediaPlayer; private final IBinder binder = new MusicBinder(); private String currentPath = ""; private boolean isPlaying = false; public class MusicBinder extends Binder { MusicService getService() { return MusicService.this; } } @Override public IBinder onBind(Intent intent) { return binder; } public void playMusic(String path) { try { if (mediaPlayer == null) { mediaPlayer = new MediaPlayer(); } mediaPlayer.reset(); mediaPlayer.setDataSource(path); mediaPlayer.prepare(); mediaPlayer.start(); isPlaying = true; currentPath = path; } catch (IOException e) { e.printStackTrace(); } } public void pauseMusic() { if (mediaPlayer != null && mediaPlayer.isPlaying()) { mediaPlayer.pause(); isPlaying = false; } } }这段代码的逻辑不复杂，但里面有几个关键点值得一说。
onBind返回的MusicBinder是 Activity 和 Service 之间的通信管道，Activity 拿到这个 Binder 后就能调用playMusic、pauseMusic这些方法。playMusic里的mediaPlayer.reset()非常关键，因为同一个 MediaPlayer 对象想换一个音源播放时，必须先回到空闲状态，否则setDataSource会抛异常。prepare()是同步阻塞的，对本地小文件还好，如果以后要播网络流，就得改成prepareAsync()配合监听器，避免卡住 UI 线程。
还有一个currentPath字段，它是用来记录当前播放的是哪一首歌的。因为界面切歌时 Activity 会先问 Service「你现在在放什么」，而不是无脑地发起一个新的播放请求。这个小细节，决定了你的播放器是不是会出现「点了一首歌，结果播的还是上一首」的灵异问题。
2.3 Activity 侧绑定 Service 的标准姿势
Service 写好了，Activity 这边怎么拿到它？常规做法是bindService，然后在ServiceConnection的回调里把 Binder 转换成具体的 Service 引用：
private ServiceConnection connection = new ServiceConnection() { @Override public void onServiceConnected(ComponentName name, IBinder service) { MusicService.MusicBinder binder = (MusicService.MusicBinder) service; musicService = binder.getService(); isBound = true; } @Override public void onServiceDisconnected(ComponentName name) { isBound = false; musicService = null; } }; @Override protected void onStart() { super.onStart(); Intent intent = new Intent(this, MusicService.class); bindService(intent, connection, Context.BIND_AUTO_CREATE); } @Override protected void onStop() { super.onStop(); if (isBound) { unbindService(connection); isBound = false; } }这里第一个要注意的是Context.BIND_AUTO_CREATE这个参数，它的意思是：如果 Service 还没创建，就自动创建它。如果你的播放器希望「App 一启动音乐服务就在后台待命」，可以改成在onCreate里同时调用startService和bindService，一个负责让 Service 跑起来，一个负责拿引用。
第二个要点是unbindService的时机。很多新手把unbindService写在 Activity 的onDestroy里，大部分时候没问题，但如果你在播放过程中旋转了屏幕，Activity 销毁重建，unbindService会把 Service 断开，正在播的音乐也被迫中断。处理这个问题最简单的做法是只在onStop里解绑，并且不要调用stopService，让 Service 继续在后台跑。这个项目就是这么处理的，这也解释了为什么它能在切到后台后依然稳定出声。
2.4 前后台生命周期：Service 不该在 Activity 消失时陪葬
再往深看一层：即使你unbindService了，Service 只要没被stopService或stopSelf，就还活着。这是安卓 Service 的基本规则。这个踩坑点常出现在新手自己改代码时：明明在 Activity 里onDestroy了，音乐还在响，于是想当然地在onDestroy里加一句stopService——然后音乐倒是停了，切歌功能也断了，因为整个服务进程被杀掉了。
正确思路是：播放一首歌时，Service 应该处于「START_STICKY」的状态，让它即使被系统回收也能自动重建。项目里onStartCommand如果返回START_STICKY，系统会在内存紧张杀掉后台服务后尝试重新创建它，这对音乐播放器至关重要。写过播放器的人都知道一个血泪经验：不处理 Service 重建，用户听歌听到一半切到别的 App，再切回来，播放器已经魂飞魄散了。
3. 本地音乐扫描与列表加载：从存储权限到 RecyclerView
3.1 扫描 SD 卡音乐文件的通用查询方式
一个播放器光能播一首歌没有意义，怎么把手机里的所有 mp3 找出来，是第二个绕不开的坎。这个项目的做法是通过 MediaStore 查询，而不是自己递归去遍历文件目录。递归遍历目录有两个问题：一是 Android 10 以后分区存储机制收紧了文件访问权限，很多路径直接读不到；二是 Scoped Storage 下你需要申请MANAGE_EXTERNAL_STORAGE这种高危权限，应用商店审核会找你麻烦。
标准查询代码如下：
public List<Song> loadLocalMusic() { List<Song> songList = new ArrayList<>(); ContentResolver resolver = getContentResolver(); Uri uri = MediaStore.Audio.Media.EXTERNAL_CONTENT_URI; 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 = resolver.query(uri, projection, selection, null, null); if (cursor != null) { while (cursor.moveToNext()) { Song song = new Song(); song.setId(cursor.getLong(cursor.getColumnIndexOrThrow(MediaStore.Audio.Media._ID))); song.setTitle(cursor.getString(cursor.getColumnIndexOrThrow(MediaStore.Audio.Media.TITLE))); song.setArtist(cursor.getString(cursor.getColumnIndexOrThrow(MediaStore.Audio.Media.ARTIST))); song.setDuration(cursor.getLong(cursor.getColumnIndexOrThrow(MediaStore.Audio.Media.DURATION))); song.setPath(cursor.getString(cursor.getColumnIndexOrThrow(MediaStore.Audio.Media.DATA))); songList.add(song); } cursor.close(); } return songList; }注意这里面有两个容易被忽略的点。
第一个是IS_MUSIC != 0这个筛选条件，它用来排除通知音、铃声这类非音乐音频。不用这个条件的话，你在测试机上跑一遍扫描，列表里可能多出一堆系统提示音。
第二个是DATA这个字段，它返回的是音频文件的绝对路径，比如/storage/emulated/0/Music/xxx.mp3。虽然在高版本 Android 上这个路径对 App 来说不再是直接可读的文件路径，但如果你的 targetSdkVersion 比较低或者走的仍然是 MediaPlayer 的setDataSource(String path)方式，它依然能正常播放。如果以后升级到 targetSdk 29+，你可能需要改用MediaStore的ContentUri来播放，这个项目没涉及，但你要知道边界在哪。
3.2 RecyclerView 列表适配器：点击事件和数据刷新
列表页面是这个项目的门面，也是你交作业时老师第一眼看到的界面。它的实现并不花哨，就是一个标准的三段式：布局 XML + 适配器 + Activity 里 setAdapter。适配器的代码大致长这样：
public class MusicAdapter extends RecyclerView.Adapter<MusicAdapter.ViewHolder> { private List<Song> songList; private OnItemClickListener listener; public interface OnItemClickListener { void onItemClick(int position); } public void setOnItemClickListener(OnItemClickListener listener) { this.listener = listener; } @NonNull @Override public ViewHolder onCreateViewHolder(@NonNull ViewGroup parent, int viewType) { View view = LayoutInflater.from(parent.getContext()) .inflate(R.layout.item_music, parent, false); return new ViewHolder(view); } @Override public void onBindViewHolder(@NonNull ViewHolder holder, int position) { Song song = songList.get(position); holder.tvTitle.setText(song.getTitle()); holder.tvArtist.setText(song.getArtist()); holder.itemView.setOnClickListener(v -> { if (listener != null) { listener.onItemClick(position); } }); } @Override public int getItemCount() { return songList == null ? 0 : songList.size(); } static class ViewHolder extends RecyclerView.ViewHolder { TextView tvTitle, tvArtist; ViewHolder(@NonNull View itemView) { super(itemView); tvTitle = itemView.findViewById(R.id.tv_title); tvArtist = itemView.findViewById(R.id.tv_artist); } } }这里onCreateViewHolder只负责把 item 布局转成 View，真正绑定数据的逻辑在onBindViewHolder里。注意它的参数是 position，你在setOnItemClickListener里拿到的 position 也要和这里的 position 对齐。很多新手把 position 存进了 ViewHolder 的 tag，Item 在列表里复用的时候 position 错乱，点击后播的歌完全对不上号，这就是典型的 RecyclerView 复用陷阱。
正确做法是直接在onBindViewHolder里通过holder.itemView.setOnClickListener拿到当前 position，或者用holder.getBindingAdapterPosition()获取真实位置。如果你在异步加载数据后调用了notifyDataSetChanged()，全量刷新虽然简单，但会导致列表项重新绑定、滑动卡顿，更优雅的做法是 DiffUtil，不过对这个体量的项目来说，notifyDataSetChanged已经是够用的选择了。
3.3 运行时权限与 Android 版本适配
扫描本地音乐需要READ_EXTERNAL_STORAGE权限。Android 6.0 以后运行时权限不能只写在 Manifest 里，必须在代码里动态申请。Android 13 里更进一步，把读取音频拆成了独立的READ_MEDIA_AUDIO权限，和读取图片、视频分开。这个项目如果在高版本设备上跑不出歌，第一怀疑对象就是权限没有真正授予。
项目里的处理方式是封装了一个权限检查方法：
private void checkPermission() { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) { if (checkSelfPermission(Manifest.permission.READ_EXTERNAL_STORAGE) != PackageManager.PERMISSION_GRANTED) { requestPermissions(new String[]{Manifest.permission.READ_EXTERNAL_STORAGE}, 100); } else { loadMusicAndShow(); } } else { loadMusicAndShow(); } }这里有个细节：如果你的测试机是 Android 13（API 33）以上，只申请READ_EXTERNAL_STORAGE可能被系统静默拒绝，弹窗都不会出现。正确做法是根据设备系统版本分支：API 33 以上申请READ_MEDIA_AUDIO，API 33 以下申请READ_EXTERNAL_STORAGE。很多工程上直接把两个权限都写进 Manifest，运行时自己判断该申请谁，这是最稳妥的兼容方案。我在自己项目里一般做一个requestAudioPermission()方法，内部按版本走不同分支，避免将来上架商店被审回来。
4. 播放控制与 UI 联动：进度条、通知栏与状态同步的避坑手册
4.1 进度条更新策略：Handler 还是定时器
音乐播放器的界面不能不带动画。播放时进度条要往前走，总时长和当前时间要不间断变化，这些都靠一个周期性的 UI 刷新任务来完成。这个项目用的是 Handler 加 Runnable 的方式：
private Handler handler = new Handler(Looper.getMainLooper()); private Runnable updateProgressRunnable = new Runnable() { @Override public void run() { if (musicService != null && musicService.isPlaying()) { int currentPosition = musicService.getCurrentPosition(); int duration = musicService.getDuration(); seekBar.setMax(duration); seekBar.setProgress(currentPosition); tvCurrentTime.setText(formatTime(currentPosition)); tvTotalTime.setText(formatTime(duration)); handler.postDelayed(this, 500); } } };为什么不用 Timer 或者ScheduledExecutorService？因为进度条的进度必须刷新在主线程，而 Handler 的postDelayed天然就是切回主线程执行的。用postDelayed(this, 500)而不是立即循环执行，是为了给系统喘口气，避免每 16 毫秒就刷新一次 TextView 导致界面卡顿。500 毫秒是播放器进度条比较通用的刷新间隔，既不觉得卡顿，也不会频繁消耗 CPU。如果你想要更平滑的视觉体验，可以改成 300 毫秒，但没必要低于 200 毫秒。
这个方法还有个隐患：Runnable 里面调用了musicService.isPlaying()，如果 Service 还没绑定上，这个判断会直接空指针。所以正确顺序是先在onServiceConnected里拿到 Service 引用，然后才开始handler.post(updateProgressRunnable)。这个项目里是这么处理的，但如果你自己改代码，很容易在onStart里提前启动刷新轮询，导致前几秒崩溃。这是一个典型的时序翻车点。
4.2 通知栏媒体控制：MediaSession 与 PendingIntent
一个能交差的播放器，切到后台后必须在通知栏显示播放状态和控制按钮。这个项目用的是NotificationManager手动构建通知，加了一个MediaSessionCompat来接收外部指令。核心代码如下：
NotificationCompat.Builder builder = new NotificationCompat.Builder(this, CHANNEL_ID) .setSmallIcon(R.drawable.ic_music_note) .setContentTitle(song.getTitle()) .setContentText(song.getArtist()) .setContentIntent(contentIntent) .setVisibility(NotificationCompat.VISIBILITY_PUBLIC) .addAction(R.drawable.ic_prev, "上一首", prevPendingIntent) .addAction(R.drawable.ic_play_pause, "播放/暂停", playPausePendingIntent) .addAction(R.drawable.ic_next, "下一首", nextPendingIntent) .setOngoing(true); NotificationManager manager = (NotificationManager) getSystemService(NOTIFICATION_SERVICE); manager.notify(1, builder.build());这里setOngoing(true)的含义是通知不可滑动删除，这是音乐播放器通知的标配，防止用户不小心划掉通知后，播放功能无法找回。如果你做过更高阶的项目，会发现正规做法是把这些 Action 的点击发到MediaSessionCompat的onMediaButtonEvent里，而不是直接给每个按钮加PendingIntent去启动 Activity。前者更规范，后者容易在锁屏或省电模式下收不到广播。
这个项目的通知栏还有一个加分项：它实现了setVisibility(NotificationCompat.VISIBILITY_PUBLIC)，这意味着即使手机锁屏，通知内容也会显示在锁屏界面上。虽然你可能觉得没什么特别的，但很多新手自己写的时候默认值其实是VISIBILITY_PRIVATE，锁屏后通知只显示应用名和图标，用户看不到歌名和歌手，体验就会差一截。
4.3 播放器状态同步：Activity 重进页面时的恢复逻辑
用户从通知栏切回 App，MainActivity 是重新执行 onStart 的。此时页面上显示的播放状态必须和 Service 的真实状态一致。如果 Activity 里维护了一个布尔值isPlaying，而 Service 那边的 MediaPlayer 早就换了一首歌，两边就对不上了。
项目里在onStart里做了一次状态拉取：
@Override protected void onStart() { super.onStart(); bindService(intent, connection, Context.BIND_AUTO_CREATE); } @Override protected void onResume() { super.onResume(); if (musicService != null) { updatePlayButtonState(musicService.isPlaying()); seekBar.setProgress(musicService.getCurrentPosition()); } }这个onResume里的同步非常重要。Activity 从后台回到前台时，onResume一定会在onStart之后执行，而此时bindService的回调可能还没回来，所以要做一次判空。你去改这个项目时，如果发现自己写了一个isPlaying字段并试图在 onResume 里用它来刷新按钮，请直接改成从 Service 里读，保证数据源唯一性。这是一个很容易让新手绕进去的坎，但越是这类坑，越能体现你有没有理解「Activity 和 Service 的数据边界」。
5. 避坑日志：三个实测必踩的播放器坑
5.1 模拟器上没声音，代码反复检查也没毛病
现象：在 Android Studio 自带的模拟器里运行项目，点击播放按钮没有声音，日志里也没有任何异常。
原因：模拟器的音频输出默认走的是宿主机的音频设备，如果宿主机的音频驱动没被模拟器正确捕获，或者模拟器系统设置里「Audio」选项处于静音状态，MediaPlayer 播放时实际上没有音频流被送出来。有些模拟器镜像连音频 HAL 都没有，等于一个哑巴设备。
解决：先在模拟器设置里找到「Sound」或「Audio」选项，确认没有静音。更快的办法是换用 Genymotion，或者干脆用真机测试。做安卓音视频开发，真机不该省，模拟器适合验证界面逻辑，不适合验证音频通路。从那以后我每次跑这类项目，第一件事就是检查真机有没有插上、声音通道有没有被后台占用。
5.2 播完最后一首歌，进度条卡在 100%，播放按钮一直显示暂停图标
现象：一首歌正常播完，MediaPlayer 进入播放完成状态，但 UI 既没有跳到下一首，也没有回到开头，播放按钮变成「继续播放」的样子，点一下没反应。
原因：MediaPlayer 播放完成时处于PlaybackCompleted状态，此时如果直接调用start()不会重启播放，必须先seekTo(0)让播放位置归零，或者调用reset()回到空闲状态再重新 setDataSource。项目里如果没有监听OnCompletionListener，这个卡死现象必然复现。
解决：给 MediaPlayer 设置播放完成监听：
mediaPlayer.setOnCompletionListener(mp -> { if (playMode == PlayMode.LOOP_ALL) { playNext(); } else if (playMode == PlayMode.LOOP_ONE) { mp.seekTo(0); mp.start(); } else { isPlaying = false; // 通知 UI 更新按钮状态 } });这里的核心是seekTo(0)而不是直接start()。MediaPlayer 在 PlaybackCompleted 状态下，seekTo(0)会让状态回到 Started 之前的 Prepared 状态，然后再 start 才能正常播放。你如果不加这一步，代码里怎么调 start 都是徒劳。
5.3 安装到 Android 14 手机上，扫描列表一片空白
现象：测试机是 Android 14，运行时权限已经点了允许，但音乐列表迟迟加载不出来，不报错，也不弹窗。
原因：Android 13 新增了READ_MEDIA_AUDIO权限，并把音频从READ_EXTERNAL_STORAGE中拆了出来。如果你的 targetSdk 是 33 或更高，Manifest.permission.READ_EXTERNAL_STORAGE在 Android 13 以上设备上默认不生效，系统压根不会给你弹权限请求框。与此同时，Android 14 对DATA字段的读取限制更严格，依然沿用 absolute path 方案的代码会拿到一个空指针或无效文件路径。
解决：动态申请时做版本分支，API 33 以上用READ_MEDIA_AUDIO，API 33 以下用READ_EXTERNAL_STORAGE。同时，如果你将来把 targetSdk 提升到 34，建议把播放入口从文件路径切换成 ContentUri 方式，否则setDataSource(path)很可能在部分机型上直接抛FileNotFoundException。这类问题是最常被忽视的「系统级黑匣子」——不是你的代码有问题，而是系统接口变了，你踩在了新旧版本的裂缝上。
6. 改造方向照这个来：播放模式、音频焦点与导出 APK 的小技巧
到一个能跑的播放器项目，很多人第一反应是「我做出来了」，然后交作业。但如果你想在答辩时多讲几句，或者在简历项目里多写一行，下面三个改造方向是最划算的，改动量不大，但技术含量看起来会高一个档次。
第一个改动是播放模式。项目里如果只有顺序播放，可以加一个随机播放和单曲循环。实现方式不复杂：在 Service 里加一个playMode枚举，切歌时根据模式决定下一首的位置。单曲循环在播完回调里seekTo(0)和start()就能实现，随机播放则是在歌曲列表里取一个随机 index。代码量不大，但你会在改的过程中第一次接触到「状态枚举」这个概念，面试时能讲清楚MODE_NORMAL、MODE_LOOP_ALL、MODE_LOOP_ONE三种状态如何切换，比背概念有用得多。
第二个改动是音频焦点。这个点很多课设项目都没有，但真正做过播放器的人都会主动处理。简单说，当你的播放器在后台放歌，用户切到网易云再放一首歌，两个 App 的声音会叠在一起，体验非常差。处理方式是获得音频焦点AudioManager.requestAudioFocus，在失去焦点时自动暂停，再abandonAudioFocus释放。这需要加一个AudioFocusChangeListener，整个改动大概 30 行代码，但足以让你在外行面前拉开差距，因为这是商业播放器才标配的行为。
第三个改动是导出 APK 的签名配置。交作业时老师一般要求能安装到手机上，Android Studio 里默认的 debug APK 是可以装的，但有些机器会提示「未知来源应用」，而且 debug 签名在很多高版本系统上表现不正常。建议自己生成一个 release 签名：菜单栏 Build → Generate Signed Bundle or APK → Create New Keystore，后续每次发布都用同一个 keystore 文件。这个步骤不涉及任何代码，但能有效避免「我在别人手机上装不上」的尴尬场面。对课设场景来说，这个技巧能把你的交付物从「一个工程文件夹」变成「一个可直接安装的安装包」，观感完全不同。
最后说一个我自己的习惯：每次改完播放器逻辑，我不会急着用模拟器跑一遍就以为收工。我会先确认三件事——使用 100 首以上的歌曲目录去扫描、切换播放源 20 次观察有没有状态残留、把 App 切到后台放 10 分钟再切回来验证 Service 是否存活。这三步走完，再交代码或者上架，基本不会翻大车。这个习惯救过我很多次，现在也会在每一次的课设项目里复现一遍。希望这些拆完的细节和踩坑记录，能帮你少走两步弯路。
本文还有配套的精品资源，点击获取
