拓冰网站定制 
简介这份安卓音乐播放器源码面向安卓入门与进阶开发者以完整的音乐播放器应用为载体帮助读者理解多媒体处理、界面搭建与后台运行等核心开发技能。压缩包共三十六个文件包含十八个编译类文件、五个Java源码、三个界面布局资源、两张界面截图以及可安装的APK成品整体仅一百二十六KB结构清晰便于逐层阅读。目前已有七百七十六人下载学习是实践性很强的教学范例。资源重点演示了播放器的装载、播放、暂停、跳转与异常处理机制同时覆盖歌曲列表展示、播放控制界面、进度条更新以及前台服务与通知栏常驻提醒等关键实现。结合源码说明与应用截图可帮助开发者快速梳理音乐播放器从界面交互到逻辑控制的完整架构为后续开发更复杂的安卓应用打下坚实基础。1. 拿到这份安卓音乐播放器源码先别急着解压安卓Android源码——MusicPlayer音乐播放器源码.zip 这类包在技术社区里流传很广多数人下载后第一反应是解压、点开 java 目录、找 MainActivity结果看半小时就放弃了。更稳的做法是先确认这是不是一个能直接构建的 Android Studio 工程看根目录有没有 settings.gradleapp 模块下有没有 build.gradlegradle/wrapper 目录里有没有 gradle-wrapper.properties。缺任何一样导入后报错都是环境问题和源码逻辑无关。音乐播放器是 Android 项目里覆盖最全的单体课题Service 后台任务、MediaPlayer 状态机、通知栏、ContentResolver 查本地曲库、SeekBar 进度刷新、音频焦点处理、图片加载 OOM 治理一个都不少。这份源码的真正价值不是跑起来听歌而是把这条链路从头拆到尾。适合对四大组件有基础、想搞懂多媒体工程怎么组织的人纯新手直接看 UI 代码大概率会被 Service 绑定和 Handler 交互绕晕。2. 读源码先读架构MediaPlayer 与 Service 的分工2.1 从 manifest 与目录结构反推源码骨架解压后先打开 app 模块下的 AndroidManifest.xml看 application 节点注册了哪些组件。老派教学源码基本是单 module目录上就 activity、service、adapter、model、utils 几个包这个清单长什么样直接决定播放链路怎么走。manifest xmlns:androidhttp://schemas.android.com/apk/res/android uses-permission android:nameandroid.permission.READ_EXTERNAL_STORAGE/ uses-permission android:nameandroid.permission.FOREGROUND_SERVICE/ application android:iconmipmap/ic_launcher android:labelstring/app_name activity android:name.ui.MainActivity/ activity android:name.ui.PlayerActivity/ service android:name.service.PlayService/ receiver android:name.receiver.HeadsetReceiver/ /application /manifest这段配置透露三层信息READ_EXTERNAL_STORAGE 说明它从 MediaStore 读本地音乐FOREGROUND_SERVICE 说明后台播放走前台服务HeadsetReceiver 处理有线耳机按键。拿到这些声明后读代码的顺序就清楚了——从 MainActivity 点进 PlayService再看它持有哪个播放器实例。UI 向 Service 发指令通常是 bindService 拿 Binder 或 startService 传 action 两种方式教学源码里后者居多因为在播放页销毁后 Service 还能独立存活。2.2 MediaPlayer 状态机决定了封装方式MediaPlayer 是一个状态机组件不是拿起来就能 start 的。最典型的入门错误是在无 setDataSource、未 Prepared 时调 start直接抛 IllegalStateException另一个是把 prepare 放在主线程歌曲稍长就卡 UI。正确封装一般把播放器单独抽一个类统一收口状态流转。public class PlayerEngine { private MediaPlayer mp new MediaPlayer(); private OnPlayerListener listener; private int pendingSeek -1; public void play(String path) { try { mp.reset(); // 回到 Idle 态必须先做 mp.setDataSource(path); // 可能抛 IOException mp.prepareAsync(); // 异步准备不阻塞 UI } catch (IOException e) { Log.e(PlayerEngine, setDataSource failed: path); } mp.setOnPreparedListener(mp - { if (pendingSeek 0) mp.seekTo(pendingSeek); mp.start(); listener.onPrepared(mp.getDuration()); }); mp.setOnErrorListener((mp, what, extra) - { Log.e(PlayerEngine, error what what extra extra); release(); return true; // 已处理不再回调 onCompletion }); } }这里的关键点是 reset 把状态拉回 IdlesetDataSource 失败只走异常分支prepareAsync 的回调一定在主线程执行onError 返回 true 表示事件被消费。pendingSeek 参数解决的是边缓冲边拖动的问题用户在 Preparing 阶段拖进度条先把目标位置存起来onPrepared 里再 seek否则 IllegalStateException 是跑不掉的。2.2.1 进度条与缓存区的两个隐藏雷点播放进度用 getCurrentPosition 轮询这个调用在 Started 状态是安全的但在 Stopped 或 Error 状态调用会异常所以轮询前要先判断 isPlaying。另一个雷是歌曲时长onPrepared 里拿到的 getDuration 才是解码器实际值MediaStore 里的 DURATION 是扫描文件时写的对 VBR 编码的 mp3 会有几十秒偏差显示进度条末端要对齐前者。2.3 什么情况值得替换成 ExoPlayerMediaPlayer 是系统组件这份源码选它做默认底座是合理的处理本地 mp3、aac、wav 完全够用。但如果你拿到包后想改成在线音乐先想清楚选型再动手。对比项MediaPlayerExoPlayer本地 mp3/aac/wav够用零依赖也可以代码更重HLS/DASH 流媒体支持弱版本差异大一等公民扩展清晰倍速、音效、自定义渲染很难介入模块化可替换 Renderer包体积系统自带按需依赖约 3 到 5 MB状态管理状态机繁琐易踩坑API 更直观面向场景替换的常见做法是保留 PlayerEngine 这个封装层把内部实现从 MediaPlayer 换成 ExoPlayer 实例对外只暴露 play/pause/seek 接口UI 层完全不用动。反过来如果需求只是本地听歌换 ExoPlayer 属于过度设计包体积和缓存管理都会成为新负担。读这份源码时先把它默认的 MediaPlayer 链路吃透改造就有参照系。3. 用 Android Studio 导入并跑起这份源码3.1 环境核对JDK、compileSdk 与 Gradle 版本导入前先配环境Android SDK 官网下载的 Studio 只会带最基本的平台版本。打开 gradle/wrapper/gradle-wrapper.properties 看 distributionUrl 对应的 Gradle 版本再打开项目级 build.gradle 看 Android Gradle Plugin 版本两者要和 Studio 支持范围匹配。# 查看 wrapper 指定的 Gradle 版本例如 7.4.2 cat gradle/wrapper/gradle-wrapper.properties | grep distributionUrl # 查看 AGP 版本 grep -r com.android.tools.build:gradle build.gradle app/build.gradle 2/dev/null核对逻辑很简单Studio 版本太新、工程 AGP 太老会提示 minimum supported Gradle versionSDK Manager 里没装 compileSdk 对应的平台Sync 时会报 missing SDK。前者改 wrapper 的 distributionUrl 让 Gradle 自动下载后者在 SDK Manager 里补齐 platform 和 build-tools。不建议同时动 AGP 和 Gradle 两个版本一次只改一个变量报错更容易定位。提示优先改 wrapper 里的 distributionUrl不要赶时髦升 AGP。教学源码往往多年未维护保持低版本反而跑得稳。依赖下载慢是另一个高频卡点。google() 和 mavenCentral() 在国内直连经常超时常见的做法是在项目级 settings.gradle 的 dependencyResolutionManagement 里前置国内镜像仓库。dependencyResolutionManagement { repositories { maven(https://maven.aliyun.com/repository/google) maven(https://maven.aliyun.com/repository/central) google() mavenCentral() } }镜像放前面的意义是命中优先阿里云仓库没有的构件再回源官方仓库不影响完整性和安全性。改完后重新 Sync观察 Build 窗口里下载进度是否在走卡住不动的依赖名往往就是缺包或者仓库没配全。3.2 真机运行与本地曲库扫描模拟器里通常没有音乐文件跑这份源码最好用真机。Android 6.0 及以上运行时权限必须动态申请老源码很容易在 Android 13 上返回空列表因为分区存储之后读取音频的权限名已经从 READ_EXTERNAL_STORAGE 变成 READ_MEDIA_AUDIOtargetSdk 不同需要的权限也不同。ContentResolver resolver getContentResolver(); Cursor cursor resolver.query( MediaStore.Audio.Media.EXTERNAL_CONTENT_URI, new String[]{ MediaStore.Audio.Media._ID, MediaStore.Audio.Media.TITLE, MediaStore.Audio.Media.ARTIST, MediaStore.Audio.Media.DURATION, MediaStore.Audio.Media.ALBUM_ID }, MediaStore.Audio.Media.IS_MUSIC ! 0, null, MediaStore.Audio.Media.TITLE COLLATE NOCASE ASC);投影参数里 _ID 是后续拼播放地址的 key拼接规则固定为 ContentUris.withAppendedId 或直接写 content://media/external/audio/media/IDALBUM_ID 用来查专辑封面地址是 content://media/external/audio/albumart/ID。查询条件排除掉铃声、通知音排序按标题忽略大小写。这段查询是这份源码的入口逻辑列表页撑不起来后面播放链路全是空转。权限适配按 targetSdk 分场景直接用这张表对号入座应用 targetSdk读取音频所需权限关键注意事项28 及以下READ_EXTERNAL_STORAGE安装时授权老包问题少29 到 32READ_EXTERNAL_STORAGE运行时申请拒绝则返回空33 及以上READ_MEDIA_AUDIO分区存储不能直接读整卡4. 后台播放链路的四个必调参数4.1 前台服务与通知栏保证不被系统杀死后台播放的硬性要求是把 Service 提升为前台服务。Android 8.0 之后startService 在后台启动会抛 IllegalStateException必须用 startForegroundService并且进入 Service 后五秒内调用 startForeground 展示通知否则系统直接 ANR。// 通知栏参数NotificationChannel 必须先创建否则通知不显示 NotificationChannel channel new NotificationChannel( play, 播放控制, NotificationManager.IMPORTANCE_LOW); notificationManager.createNotificationChannel(channel); Notification notification new Notification.Builder(this, play) .setSmallIcon(R.drawable.ic_notification) // 必须是纯 alpha 图 .setContentTitle(songTitle) .setContentText(songArtist) .setOngoing(true) .build(); startForeground(1001, notification);setSmallIcon 参数是这里最容易翻车的点必须使用纯 alpha 通道的图标彩色 vector 在某些机型上会显示成白底方块。setOngoing(true) 让用户不能顺手滑掉通知避免通知被清理后服务和前台标识失配。如果这份源码里用的是旧版 NotificationCompat 且没适配通知渠道在 Android 8.0 以上通知会无声消失跑真机时第一件事就是确认下拉栏能看到常驻通知。4.2 音频焦点与蓝牙耳机的处理参数音乐播放器必须和系统里其他音频源协调不申请音频焦点来电话时可能两边同时响。AudioManager am (AudioManager) getSystemService(AUDIO_SERVICE); AudioFocusRequest focusRequest new AudioFocusRequest.Builder(AudioManager.AUDIOFOCUS_GAIN) .setOnAudioFocusChangeListener(afChangeListener) .build(); int result am.requestAudioFocus(focusRequest);AUDIOFOCUS_GAIN 是持续独占适合正常播放临时打断如语音导航用 AUDIOFOCUS_GAIN_TRANSIENT收到焦点丢失事件时暂停重新获得焦点时续播。蓝牙耳机断开、有线耳机拔出时系统会广播 ACTION_AUDIO_BECOMING_NOISY源码里如果只做了来电暂停而没处理这个广播用户拔耳机会发现音乐从扬声器外放这是后台播放体验最差的漏网场景。4.3 SeekBar 进度刷新的正确姿势播放页的进度条本质是一个不断被填充的 View常见实现是主线程 Handler 定时取 getCurrentPosition 然后 setProgress。Handler handler new Handler(Looper.getMainLooper()); Runnable tick new Runnable() { Override public void run() { if (mp ! null mp.isPlaying()) { progressBar.setProgress(mp.getCurrentPosition()); } handler.postDelayed(this, 500); // 500ms 一个刷新周期 } }; handler.post(tick); // onDestroy 必须移除否则页面销毁后回调流仍然在跑 handler.removeCallbacksAndMessages(null);500ms 的参数权衡是100ms 间隔会造成明显卡顿和无谓电量消耗1000ms 让进度条看起来一跳一跳500ms 是视觉流畅和性能的典型折中。setProgress 传入的是毫秒值SeekBar 的 max 设成时长毫秒数进度和拖动映射就是线性的不需要额外换算。Handler 泄漏的治理靠最后一行 removeCallbacksAndMessages在 onDestroy 里执行否则持有 Activity 引用导致内存泄漏。4.4 封面加载与内存边界本地音乐列表的专辑封面如果用手写 BitmapFactory 加载列表快速滑动时内存抖动非常明显。常见做法是交给 Glide 等图片库它内部处理了采样率和缓存策略如果坚持手写必须用 inSampleSize 按 Item 尺寸降采样不要直接 decode 原图。ALBUM_ID 拿到的封面 URI 可能为空加载前先判断兜底到默认封面。这一项和播放状态机一样值得改因为 OOM 崩溃在百首以上曲库时几乎是必然事件。5. 用 adb 把播放链路验证一遍5.1 三行命令定位卡壳环节源码跑起来后与其在 IDE 里打一堆断点不如先用 adb 把运行时状态拉出来看。配上 android 测试环境的 aapt 和 logcat 全家桶定位效率高很多。# 只看播放器相关日志过滤噪声 adb logcat -s MediaPlayer:V PlayerEngine:V PlayService:V # 查看当前媒体会话是否注册成功 adb shell dumpsys media_session # 确认前台服务还活着 adb shell dumpsys activity services .service.PlayServicelogcat 里出现 prepareAsync called in state 8 之类信息直接对应状态机问题dumpsys media_session 输出里能看到 active 的 MediaSession 和回调 binder如果找不到自己应用的包名说明 MediaSession 压根没建起来通知栏的播放控制按钮自然失效。dumpsys activity services 的输出重点看 isForeground 字段是不是 true从前台掉回后台服务说明内存回收或代码里 stopForeground 被误调。5.2 断点打在四条边界上如果日志不足以定位断点优先打在四个位置setDataSource 的 IOException 分支、onError 回调、onAudioFocusChange 的焦点丢失分支、Service 的 onDestroy。这四个点覆盖了播放失败、资源冲突、进程回收的主要路径。验证时准备一首时长十分钟以上的歌曲依次走完播放、息屏、暂停、来电模拟、拔耳机、再切回播放这条完整链路每个动作后观察 logcat 状态变化。把这个 adb 命令组合存成一个 shell 脚本每次改完代码跑一遍再提交能抢回至少一小时的联调时间。本文还有配套的精品资源点击获取 安卓音乐播放器源码解析：MediaPlayer状态机与Service后台播放实践
简介这份安卓音乐播放器源码面向安卓入门与进阶开发者以完整的音乐播放器应用为载体帮助读者理解多媒体处理、界面搭建与后台运行等核心开发技能。压缩包共三十六个文件包含十八个编译类文件、五个Java源码、三个界面布局资源、两张界面截图以及可安装的APK成品整体仅一百二十六KB结构清晰便于逐层阅读。目前已有七百七十六人下载学习是实践性很强的教学范例。资源重点演示了播放器的装载、播放、暂停、跳转与异常处理机制同时覆盖歌曲列表展示、播放控制界面、进度条更新以及前台服务与通知栏常驻提醒等关键实现。结合源码说明与应用截图可帮助开发者快速梳理音乐播放器从界面交互到逻辑控制的完整架构为后续开发更复杂的安卓应用打下坚实基础。1. 拿到这份安卓音乐播放器源码先别急着解压安卓Android源码——MusicPlayer音乐播放器源码.zip 这类包在技术社区里流传很广多数人下载后第一反应是解压、点开 java 目录、找 MainActivity结果看半小时就放弃了。更稳的做法是先确认这是不是一个能直接构建的 Android Studio 工程看根目录有没有 settings.gradleapp 模块下有没有 build.gradlegradle/wrapper 目录里有没有 gradle-wrapper.properties。缺任何一样导入后报错都是环境问题和源码逻辑无关。音乐播放器是 Android 项目里覆盖最全的单体课题Service 后台任务、MediaPlayer 状态机、通知栏、ContentResolver 查本地曲库、SeekBar 进度刷新、音频焦点处理、图片加载 OOM 治理一个都不少。这份源码的真正价值不是跑起来听歌而是把这条链路从头拆到尾。适合对四大组件有基础、想搞懂多媒体工程怎么组织的人纯新手直接看 UI 代码大概率会被 Service 绑定和 Handler 交互绕晕。2. 读源码先读架构MediaPlayer 与 Service 的分工2.1 从 manifest 与目录结构反推源码骨架解压后先打开 app 模块下的 AndroidManifest.xml看 application 节点注册了哪些组件。老派教学源码基本是单 module目录上就 activity、service、adapter、model、utils 几个包这个清单长什么样直接决定播放链路怎么走。manifest xmlns:androidhttp://schemas.android.com/apk/res/android uses-permission android:nameandroid.permission.READ_EXTERNAL_STORAGE/ uses-permission android:nameandroid.permission.FOREGROUND_SERVICE/ application android:iconmipmap/ic_launcher android:labelstring/app_name activity android:name.ui.MainActivity/ activity android:name.ui.PlayerActivity/ service android:name.service.PlayService/ receiver android:name.receiver.HeadsetReceiver/ /application /manifest这段配置透露三层信息READ_EXTERNAL_STORAGE 说明它从 MediaStore 读本地音乐FOREGROUND_SERVICE 说明后台播放走前台服务HeadsetReceiver 处理有线耳机按键。拿到这些声明后读代码的顺序就清楚了——从 MainActivity 点进 PlayService再看它持有哪个播放器实例。UI 向 Service 发指令通常是 bindService 拿 Binder 或 startService 传 action 两种方式教学源码里后者居多因为在播放页销毁后 Service 还能独立存活。2.2 MediaPlayer 状态机决定了封装方式MediaPlayer 是一个状态机组件不是拿起来就能 start 的。最典型的入门错误是在无 setDataSource、未 Prepared 时调 start直接抛 IllegalStateException另一个是把 prepare 放在主线程歌曲稍长就卡 UI。正确封装一般把播放器单独抽一个类统一收口状态流转。public class PlayerEngine { private MediaPlayer mp new MediaPlayer(); private OnPlayerListener listener; private int pendingSeek -1; public void play(String path) { try { mp.reset(); // 回到 Idle 态必须先做 mp.setDataSource(path); // 可能抛 IOException mp.prepareAsync(); // 异步准备不阻塞 UI } catch (IOException e) { Log.e(PlayerEngine, setDataSource failed: path); } mp.setOnPreparedListener(mp - { if (pendingSeek 0) mp.seekTo(pendingSeek); mp.start(); listener.onPrepared(mp.getDuration()); }); mp.setOnErrorListener((mp, what, extra) - { Log.e(PlayerEngine, error what what extra extra); release(); return true; // 已处理不再回调 onCompletion }); } }这里的关键点是 reset 把状态拉回 IdlesetDataSource 失败只走异常分支prepareAsync 的回调一定在主线程执行onError 返回 true 表示事件被消费。pendingSeek 参数解决的是边缓冲边拖动的问题用户在 Preparing 阶段拖进度条先把目标位置存起来onPrepared 里再 seek否则 IllegalStateException 是跑不掉的。2.2.1 进度条与缓存区的两个隐藏雷点播放进度用 getCurrentPosition 轮询这个调用在 Started 状态是安全的但在 Stopped 或 Error 状态调用会异常所以轮询前要先判断 isPlaying。另一个雷是歌曲时长onPrepared 里拿到的 getDuration 才是解码器实际值MediaStore 里的 DURATION 是扫描文件时写的对 VBR 编码的 mp3 会有几十秒偏差显示进度条末端要对齐前者。2.3 什么情况值得替换成 ExoPlayerMediaPlayer 是系统组件这份源码选它做默认底座是合理的处理本地 mp3、aac、wav 完全够用。但如果你拿到包后想改成在线音乐先想清楚选型再动手。对比项MediaPlayerExoPlayer本地 mp3/aac/wav够用零依赖也可以代码更重HLS/DASH 流媒体支持弱版本差异大一等公民扩展清晰倍速、音效、自定义渲染很难介入模块化可替换 Renderer包体积系统自带按需依赖约 3 到 5 MB状态管理状态机繁琐易踩坑API 更直观面向场景替换的常见做法是保留 PlayerEngine 这个封装层把内部实现从 MediaPlayer 换成 ExoPlayer 实例对外只暴露 play/pause/seek 接口UI 层完全不用动。反过来如果需求只是本地听歌换 ExoPlayer 属于过度设计包体积和缓存管理都会成为新负担。读这份源码时先把它默认的 MediaPlayer 链路吃透改造就有参照系。3. 用 Android Studio 导入并跑起这份源码3.1 环境核对JDK、compileSdk 与 Gradle 版本导入前先配环境Android SDK 官网下载的 Studio 只会带最基本的平台版本。打开 gradle/wrapper/gradle-wrapper.properties 看 distributionUrl 对应的 Gradle 版本再打开项目级 build.gradle 看 Android Gradle Plugin 版本两者要和 Studio 支持范围匹配。# 查看 wrapper 指定的 Gradle 版本例如 7.4.2 cat gradle/wrapper/gradle-wrapper.properties | grep distributionUrl # 查看 AGP 版本 grep -r com.android.tools.build:gradle build.gradle app/build.gradle 2/dev/null核对逻辑很简单Studio 版本太新、工程 AGP 太老会提示 minimum supported Gradle versionSDK Manager 里没装 compileSdk 对应的平台Sync 时会报 missing SDK。前者改 wrapper 的 distributionUrl 让 Gradle 自动下载后者在 SDK Manager 里补齐 platform 和 build-tools。不建议同时动 AGP 和 Gradle 两个版本一次只改一个变量报错更容易定位。提示优先改 wrapper 里的 distributionUrl不要赶时髦升 AGP。教学源码往往多年未维护保持低版本反而跑得稳。依赖下载慢是另一个高频卡点。google() 和 mavenCentral() 在国内直连经常超时常见的做法是在项目级 settings.gradle 的 dependencyResolutionManagement 里前置国内镜像仓库。dependencyResolutionManagement { repositories { maven(https://maven.aliyun.com/repository/google) maven(https://maven.aliyun.com/repository/central) google() mavenCentral() } }镜像放前面的意义是命中优先阿里云仓库没有的构件再回源官方仓库不影响完整性和安全性。改完后重新 Sync观察 Build 窗口里下载进度是否在走卡住不动的依赖名往往就是缺包或者仓库没配全。3.2 真机运行与本地曲库扫描模拟器里通常没有音乐文件跑这份源码最好用真机。Android 6.0 及以上运行时权限必须动态申请老源码很容易在 Android 13 上返回空列表因为分区存储之后读取音频的权限名已经从 READ_EXTERNAL_STORAGE 变成 READ_MEDIA_AUDIOtargetSdk 不同需要的权限也不同。ContentResolver resolver getContentResolver(); Cursor cursor resolver.query( MediaStore.Audio.Media.EXTERNAL_CONTENT_URI, new String[]{ MediaStore.Audio.Media._ID, MediaStore.Audio.Media.TITLE, MediaStore.Audio.Media.ARTIST, MediaStore.Audio.Media.DURATION, MediaStore.Audio.Media.ALBUM_ID }, MediaStore.Audio.Media.IS_MUSIC ! 0, null, MediaStore.Audio.Media.TITLE COLLATE NOCASE ASC);投影参数里 _ID 是后续拼播放地址的 key拼接规则固定为 ContentUris.withAppendedId 或直接写 content://media/external/audio/media/IDALBUM_ID 用来查专辑封面地址是 content://media/external/audio/albumart/ID。查询条件排除掉铃声、通知音排序按标题忽略大小写。这段查询是这份源码的入口逻辑列表页撑不起来后面播放链路全是空转。权限适配按 targetSdk 分场景直接用这张表对号入座应用 targetSdk读取音频所需权限关键注意事项28 及以下READ_EXTERNAL_STORAGE安装时授权老包问题少29 到 32READ_EXTERNAL_STORAGE运行时申请拒绝则返回空33 及以上READ_MEDIA_AUDIO分区存储不能直接读整卡4. 后台播放链路的四个必调参数4.1 前台服务与通知栏保证不被系统杀死后台播放的硬性要求是把 Service 提升为前台服务。Android 8.0 之后startService 在后台启动会抛 IllegalStateException必须用 startForegroundService并且进入 Service 后五秒内调用 startForeground 展示通知否则系统直接 ANR。// 通知栏参数NotificationChannel 必须先创建否则通知不显示 NotificationChannel channel new NotificationChannel( play, 播放控制, NotificationManager.IMPORTANCE_LOW); notificationManager.createNotificationChannel(channel); Notification notification new Notification.Builder(this, play) .setSmallIcon(R.drawable.ic_notification) // 必须是纯 alpha 图 .setContentTitle(songTitle) .setContentText(songArtist) .setOngoing(true) .build(); startForeground(1001, notification);setSmallIcon 参数是这里最容易翻车的点必须使用纯 alpha 通道的图标彩色 vector 在某些机型上会显示成白底方块。setOngoing(true) 让用户不能顺手滑掉通知避免通知被清理后服务和前台标识失配。如果这份源码里用的是旧版 NotificationCompat 且没适配通知渠道在 Android 8.0 以上通知会无声消失跑真机时第一件事就是确认下拉栏能看到常驻通知。4.2 音频焦点与蓝牙耳机的处理参数音乐播放器必须和系统里其他音频源协调不申请音频焦点来电话时可能两边同时响。AudioManager am (AudioManager) getSystemService(AUDIO_SERVICE); AudioFocusRequest focusRequest new AudioFocusRequest.Builder(AudioManager.AUDIOFOCUS_GAIN) .setOnAudioFocusChangeListener(afChangeListener) .build(); int result am.requestAudioFocus(focusRequest);AUDIOFOCUS_GAIN 是持续独占适合正常播放临时打断如语音导航用 AUDIOFOCUS_GAIN_TRANSIENT收到焦点丢失事件时暂停重新获得焦点时续播。蓝牙耳机断开、有线耳机拔出时系统会广播 ACTION_AUDIO_BECOMING_NOISY源码里如果只做了来电暂停而没处理这个广播用户拔耳机会发现音乐从扬声器外放这是后台播放体验最差的漏网场景。4.3 SeekBar 进度刷新的正确姿势播放页的进度条本质是一个不断被填充的 View常见实现是主线程 Handler 定时取 getCurrentPosition 然后 setProgress。Handler handler new Handler(Looper.getMainLooper()); Runnable tick new Runnable() { Override public void run() { if (mp ! null mp.isPlaying()) { progressBar.setProgress(mp.getCurrentPosition()); } handler.postDelayed(this, 500); // 500ms 一个刷新周期 } }; handler.post(tick); // onDestroy 必须移除否则页面销毁后回调流仍然在跑 handler.removeCallbacksAndMessages(null);500ms 的参数权衡是100ms 间隔会造成明显卡顿和无谓电量消耗1000ms 让进度条看起来一跳一跳500ms 是视觉流畅和性能的典型折中。setProgress 传入的是毫秒值SeekBar 的 max 设成时长毫秒数进度和拖动映射就是线性的不需要额外换算。Handler 泄漏的治理靠最后一行 removeCallbacksAndMessages在 onDestroy 里执行否则持有 Activity 引用导致内存泄漏。4.4 封面加载与内存边界本地音乐列表的专辑封面如果用手写 BitmapFactory 加载列表快速滑动时内存抖动非常明显。常见做法是交给 Glide 等图片库它内部处理了采样率和缓存策略如果坚持手写必须用 inSampleSize 按 Item 尺寸降采样不要直接 decode 原图。ALBUM_ID 拿到的封面 URI 可能为空加载前先判断兜底到默认封面。这一项和播放状态机一样值得改因为 OOM 崩溃在百首以上曲库时几乎是必然事件。5. 用 adb 把播放链路验证一遍5.1 三行命令定位卡壳环节源码跑起来后与其在 IDE 里打一堆断点不如先用 adb 把运行时状态拉出来看。配上 android 测试环境的 aapt 和 logcat 全家桶定位效率高很多。# 只看播放器相关日志过滤噪声 adb logcat -s MediaPlayer:V PlayerEngine:V PlayService:V # 查看当前媒体会话是否注册成功 adb shell dumpsys media_session # 确认前台服务还活着 adb shell dumpsys activity services .service.PlayServicelogcat 里出现 prepareAsync called in state 8 之类信息直接对应状态机问题dumpsys media_session 输出里能看到 active 的 MediaSession 和回调 binder如果找不到自己应用的包名说明 MediaSession 压根没建起来通知栏的播放控制按钮自然失效。dumpsys activity services 的输出重点看 isForeground 字段是不是 true从前台掉回后台服务说明内存回收或代码里 stopForeground 被误调。5.2 断点打在四条边界上如果日志不足以定位断点优先打在四个位置setDataSource 的 IOException 分支、onError 回调、onAudioFocusChange 的焦点丢失分支、Service 的 onDestroy。这四个点覆盖了播放失败、资源冲突、进程回收的主要路径。验证时准备一首时长十分钟以上的歌曲依次走完播放、息屏、暂停、来电模拟、拔耳机、再切回播放这条完整链路每个动作后观察 logcat 状态变化。把这个 adb 命令组合存成一个 shell 脚本每次改完代码跑一遍再提交能抢回至少一小时的联调时间。本文还有配套的精品资源点击获取