很多人在拿到“Android MAD HW3 仿网易云播放器”这个作业题的时候，第一反应是去找一套网易云的开源 UI 来抄，或者直接在 GitHub 上搜播放器 Demo。其实这个作业真正考察的并不是 UI 还原度，而是你有没有把一个播放器应用需要处理的状态管理、生命周期绑定、异步加载、媒体焦点这些核心问题想清楚。这次我把自己完成这个项目的完整思路、踩过的坑、以及最后整理出来的可复现代码框架记录下来，给正在做同类作业的同学一个参考。1. 先拆题：这个作业真正让你练什么1.1 仿写目标拆解：界面、交互、逻辑各占多少“仿网易云播放器”这个题目看起来是个 UI 任务，实际上拆开之后是四层内容叠加：静态界面、交互动效、音频播放逻辑、以及数据加载方式。界面层面，网易云播放器的特点是红白配色、Tab 底部导航、歌单列表封面、播放页黑底大字歌词。交互层面，包括列表点击跳转、播放页出现、底部迷你播放条跟随滚动。逻辑层面，MediaPlayer 的播放、暂停、切换、进度更新。数据层面，从本地媒体库扫描音频文件，或者从固定资源目录读取预置音频。我在动手之前列了一个优先级清单，分配给不同模块的精力大概是：列表 20%、播放逻辑 30%、通知栏和控制交互 20%、UI 美化 20%、其余 10%。如果只看 UI 而忽略播放逻辑，代码交上去很可能会变成“图片浏览器”而不是播放器。把 UI 做得简单一点没关系，但是播放器的核心状态流转必须完整。1.2 技术选型的取舍逻辑这个作业的常规技术栈是 RecyclerView + MediaPlayer + Service（或前台服务）。很多同学会纠结要不要上 ExoPlayer，我的建议是作业场景优先用 MediaPlayer。原因有几点：第一，MediaPlayer 是 Android 原生 API，状态机清晰，课程考察点往往就围绕它的生命周期展开；第二，ExoPlayer 虽然功能强，但依赖较多，如果目标仅仅是本地音频播放，属于过度设计；第三，MediaPlayer 配合 AudioManager 处理音频焦点时，代码模式非常经典，这些原理在工作后依然有参考价值。界面方面，我选择了单 Activity + 双 Fragment 的结构，主界面放列表，播放页用 Dialog 风格 Fragment 或者另一个 Fragment 切换。如果你接触过 Jetpack Navigation，用它管理这两个页面也很自然，但如果没有，用 supportFragmentManager 手动切换也可以，逻辑都一样。1.3 功能边界规划在开始写代码前，我把功能边界定为以下几条：扫描本地媒体库中的所有音频，按歌曲名、歌手、时长展示在列表中点击列表项播放对应音频，当前播放项高亮并显示播放状态底部迷你栏显示当前歌曲，可暂停/继续，点击可展开播放页播放页展示封面、歌词占位区、进度条、播放模式切换和上一首/下一首后台播放能力：退出应用界面后音乐继续播放，通知栏显示控制器处理来电/其他应用播放等音频焦点抢占场景这已经是一个完整播放器的骨架了。再多加内容，比如歌词滚动解析、VIP 模拟按钮、搜索筛选，在时间有限的情况下容易喧宾夺主。2. 项目骨架搭建：播放器类 App 的目录与架构2.1 分层目录规划做这个项目时，我在包结构上采用了基础的三层划分，不复杂但足够清晰：com.example.musicplayer ├── data/ │ ├── model/ │ │ └── Song.kt │ └── repository/ │ └── MusicRepository.kt ├── player/ │ └── PlayManager.kt ├── ui/ │ ├── list/ │ │ ├── SongListFragment.kt │ │ └── SongListAdapter.kt │ ├── player/ │ │ └── PlayerFragment.kt │ └── MainActivity.kt └── service/ └── PlaybackService.ktdata 层负责从 ContentResolver 读取音频文件的元数据，player 层只负责播放器的状态和操作方法，ui 层负责界面渲染与用户交互。实际写的时候还可以压缩得更简单，但我建议保留 repository 这一层，因为后续做假数据切换、缓存、单元测试都会方便很多。2.2 播放管理器封装：状态机是关键MediaPlayer 最让人头疼的地方是它自身带状态机，比如已经 release 之后再调用 stop 会抛异常，播放完成回调之后直接 start 也会出现问题。所以我在业务代码里没有直接操作 MediaPlayer，而是封装了一个 PlayManager，内部维护一个播放状态枚举。enum class PlayState { IDLE, // 初始状态，无媒体资源 PREPARING, // 正在准备 PLAYING, PAUSED, COMPLETED, RELEASED }对外暴露的接口包括：play(song, list)、pause()、resume()、seekTo()、next()、previous()、switchPlayMode() 和 release()。每一个方法第一步都是检查当前状态是否允许这个操作，比如 IDLE 状态下调用 pause 直接忽略。这一步看起来多余，但解决了 90% 的诡异崩溃问题。2.3 数据层：用 ContentResolver 扫本地音乐扫描本地音频的核心代码并不复杂，但需要知道正确的查询字段和排序逻辑。我使用的是 MediaStore.Audio.Media.EXTERNAL_CONTENT_URI，查询字段包括 _id、title、artist、duration、data（文件路径）、albumId 等。记住一点：Android 10（API 29）之后，data 字段已经不再是完全可信的路径，文件访问机制变成了作用域存储。如果只是拿路径去让 MediaPlayer 播放，在较新系统上偶尔能播放，但依赖 File 读取文件内容的方式会逐渐被禁止。作业场景下如果只是把 data 传给 MediaPlayer.setDataSource(path)，大多数机型还是可行的；但更稳妥的方案是使用 MediaStore 查询 URI，把它转换为 content:// 形式传给 MediaPlayer，这个我会在下一节详细说。3. 核心功能实现细节：从列表到播放的完整链路3.1 动态权限与媒体库扫描如果你直接跑查询 MediaStore 的代码，几乎一定会遇到 SecurityException。Android 6.0 以后，本地音乐读取属于运行时权限，需要在代码中请求 READ_MEDIA_AUDIO 或 READ_EXTERNAL_STORAGE。不同版本的权限申请方式不同，我在这块写了一个兼容判断：private fun requestAudioPermission() { val permission = if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) Manifest.permission.READ_MEDIA_AUDIO else Manifest.permission.READ_EXTERNAL_STORAGE if (ContextCompat.checkSelfPermission(requireContext(), permission) != PackageManager.PERMISSION_GRANTED ) { requestPermissions(arrayOf(permission), REQUEST_AUDIO_PERMISSION) } else { loadSongsFromMediaStore() } }这里有个容易忽略的细节：Android 13 上如果同时申请了 READ_MEDIA_AUDIO 和 READ_MEDIA_IMAGES，系统会弹出两个对话框，任何一个被拒绝都会影响后续逻辑。所以作业里只申请需要的权限，不要图省事把所有权限一起要。权限授予之后，查媒体库的代码大概是这样的：fun loadSongsFromMediaStore(): List<Song> { val songs = mutableListOf<Song>() val collection = MediaStore.Audio.Media.EXTERNAL_CONTENT_URI val projection = arrayOf( MediaStore.Audio.Media._ID, MediaStore.Audio.Media.TITLE, MediaStore.Audio.Media.ARTIST, MediaStore.Audio.Media.DURATION, MediaStore.Audio.Media.ALBUM_ID ) val selection = "${MediaStore.Audio.Media.IS_MUSIC} != 0" val sortOrder = "${MediaStore.Audio.Media.TITLE} ASC" context.contentResolver.query( collection, projection, selection, null, sortOrder )?.use { cursor -> val idCol = cursor.getColumnIndexOrThrow(MediaStore.Audio.Media._ID) val titleCol = cursor.getColumnIndexOrThrow(MediaStore.Audio.Media.TITLE) val artistCol = cursor.getColumnIndexOrThrow(MediaStore.Audio.Media.ARTIST) val durationCol = cursor.getColumnIndexOrThrow(MediaStore.Audio.Media.DURATION) val albumIdCol = cursor.getColumnIndexOrThrow(MediaStore.Audio.Media.ALBUM_ID) while (cursor.moveToNext()) { val id = cursor.getLong(idCol) val title = cursor.getString(titleCol) ?: "未知歌曲" val artist = cursor.getString(artistCol) ?: "未知歌手" val duration = cursor.getInt(durationCol) val albumId = cursor.getLong(albumIdCol) val contentUri = ContentUris.withAppendedId(collection, id) songs.add( Song( id = id, title = title, artist = artist, duration = duration, uri = contentUri.toString(), albumId = albumId ) ) } } return songs }作业里往往会给项目塞入音频资源文件，所以我也推荐在代码里做一步合并逻辑：把 res/raw 下的音频文件或 assets 目录里的音频解析为歌曲条目，追加到列表末尾。这样可以保证模拟器上没有音乐文件时，作业演示仍能正常播放。3.2 RecyclerView 列表与播放状态联动列表页是整个项目的门面，也是 RecyclerView 适配器最容易写崩的地方。我认真踩过这个坑：Item 复用时旧位置的状态会串到新位置上。比如第 5 个 Item 正在播放，往下滑动再滑回来，可能第 6 个 Item 也变成了播放中样式。解决办法有两个层面。第一层，adapter 不要保存播放状态，而是从唯一的数据源读取。我选择在 MainActivity 中维护一个 currentPlayIndex，把它传给 adapter，adapter 在 onBindViewHolder 时判断 position == currentPlayIndex 来决定是否显示高亮。第二层，每次列表数据更新或播放状态切换后，要调用 notifyDataSetChanged 或精确的 notifyItemChanged(旧位置) + notifyItemChanged(新位置)。在 onBindViewHolder 里大致的逻辑是：override fun onBindViewHolder(holder: SongViewHolder, position: Int) { val song = songs[position] holder.binding.title.text = song.title holder.binding.artist.text = song.artist val isPlaying = (position == currentPlayIndex) && isPlayingFlag holder.binding.root.isSelected = isPlaying holder.binding.playingIcon.visibility = if (isPlaying) View.VISIBLE else View.GONE }item 根布局的 isSelected 属性配合 selector 背景可以做到切换背景色，不用手动 bind 两次。如果你还没接触过 Selector，这个技巧会很实用：在 drawable 里定义 selected 状态的背景色，设置给 root，剩下的交给系统处理。点击事件要绑定在 itemView 上，点击时回调接口把 position 传给 ViewModel 或直接传给 Activity，由它去调用 PlayManager。3.3 MediaPlayer 封装与进度更新播放器核心我封装在 PlayManager 里。这里有一个很重要的设计：不要把 MediaPlayer 创建在 Activity 或 Fragment 中。因为只要界面旋转、销毁，MediaPlayer 就被带走了，音乐自然中断。作业要求里往往隐含了“退出界面后仍能播放”这一条，所以 MediaPlayer 要么放在前台 Service 中，要么放在一个 Application 级别的单例里。考虑到作业场景，我用了 Application 级单例 + 前台 Service 的组合。PlayManager 是单例，Service 只是承载通知栏与后台执行环境。如果你只做单例而不用 Service，应用退到后台后进程可能被回收，所以 Service 还是必要的。MediaPlayer 的标准用法是：mediaPlayer = MediaPlayer() mediaPlayer?.setAudioAttributes( AudioAttributes.Builder() .setContentType(AudioAttributes.CONTENT_TYPE_MUSIC) .setUsage(AudioAttributes.USAGE_MEDIA) .build() ) mediaPlayer?.setDataSource(song.uri) mediaPlayer?.prepareAsync()prepareAsync 是异步准备，需要监听 OnPreparedListener 再调用 start。如果直接同步 prepare，环境不好的情况下会卡住主线程。加载完成前可以展示 loading 状态，否则用户反复点击播放按钮容易产生卡顿感。进度更新的方式有两种：一种是使用 Handler 循环发消息，每 200ms 读取一次 currentPosition；另一种是使用 Lifecycle 的 repeatOnLifecycle 配合 kotlinx.coroutines 来处理。作业里用 Handler 最常见，也最好理解：private val progressHandler = Handler(Looper.getMainLooper()) private val progressRunnable = object : Runnable { override fun run() { val progress = playManager.getCurrentPosition() val duration = playManager.getDuration() if (duration > 0) { seekBar.progress = (progress * 1000 / duration).toInt() } progressHandler.postDelayed(this, 200) } }注意：进度条更新不要用类似 Thread.sleep 的循环来搞，这在主线程上会直接卡死 UI。Handler 的 postDelayed 是异步循环，不会阻塞主线程。如果你水平更高一点，可以把进度更新放在协程里，配合 lifecycleScope，但 Handler 足够应对课程验收。MediaPlayer 还有一个关键属性：播放完成监听。播放到末尾时，如果只有一首歌，应该回到开头暂停；如果有多首歌，应该自动进入下一首。我更倾向于在 OnCompletionListener 里先处理播放模式，再决定是循环播放、进入下一首还是暂停。3.4 通知栏控制与音频焦点通知栏控制器属于这个作业的加分项，但我觉得它应该是必做项，因为没有后台播放能力的播放器是不完整的。核心思路是使用 MediaSessionCompat + NotificationCompat 构建媒体通知。在较新版本上你还需要声明 POST_NOTIFICATIONS 权限，否则通知不显示。通知栏的 action 应该包括上一首、播放/暂停、下一首。点击通知跳回 MainActivity 时，要使用 PendingIntent.getActivity 并带上 FLAG_IMMUTABLE，这个是 Android 12 以上的硬性要求，不加会导致崩溃。音频焦点部分是一个容易被面试官问到的点。播放器应当监听 AudioManager 的音频焦点变化，比如电话打进来、其他播放器开始发声时暂停音乐。核心代码是对 OnAudioFocusChangeListener 的响应。我在实际代码里是这样处理的：audioManager = getSystemService(Context.AUDIO_SERVICE) as AudioManager val focusRequest = AudioFocusRequest.Builder(AudioManager.AUDIOFOCUS_GAIN) .setAudioAttributes( AudioAttributes.Builder() .setUsage(AudioAttributes.USAGE_MEDIA) .setContentType(AudioAttributes.CONTENT_TYPE_MUSIC) .build() ) .setAcceptsDelayedFocusGain(true) .setOnAudioFocusChangeListener { focusChange -> when (focusChange) { AudioManager.AUDIOFOCUS_LOSS -> { playManager.pause() } AudioManager.AUDIOFOCUS_LOSS_TRANSIENT -> { playManager.pause() } AudioManager.AUDIOFOCUS_GAIN -> { // 如果想恢复播放，可以在这里按需恢复 } } } .build()AUDIOFOCUS_LOSS 代表焦点永久丢失，比如切到了其他音乐 App，这时应该暂停，并且不要再试着恢复。AUDIOFOCUS_LOSS_TRANSIENT 是临时失去焦点，比如来电或语音助手，暂停后可以等待恢复。如果你不处理音频焦点，音乐会在来电时继续播放，这在作业演示和代码答辩里都是明显的减分项。4. 网易云风格 UI 还原的实用思路4.1 红白配色与圆角卡片布局网易云播放器的经典元素是红白配色和圆角卡片。我用的主色值是 #C20C0C，背景偏白或偏浅灰，列表项使用圆角背景加细线条分割。RecyclerView 的 item 布局在作业里可以做得比较简单：左侧是一个圆形或圆角方形封面占位图，中间偏左是歌名，歌名下方是歌手名，右侧是播放状态图标。封面图如果没有真实专辑图，可以使用一个默认图标，或者用 Palette API 从列表页的占位图颜色中提取主色作为封面底色。后者做出来效果会明显好很多，但复杂度略高。我建议先把默认图标和占位图方案跑通，有余力再做 Palette 取色。圆角卡片如果用 CardView 会方便很多，但如果你不想引入额外依赖，直接在 drawable 里写一个 shape 文件也可以：<shape xmlns:android="http://schemas.android.com/apk/res/android"> <solid android:color="@android:color/white" /> <corners android:radius="12dp" /> </shape>列表项间距通过 item 布局的 layout_margin 控制，分割线通过 divider 或 item 内部分割。4.2 播放页封面动效：旋转动画与模糊背景网易云播放页最深入人心的是那张大面积模糊背景和封面唱片旋转动画。模糊背景可以通过在布局中设置两个同样大小的 ImageView 实现：底层做模糊和缩放，上层显示封面图。模糊效果在作业里一般用 RenderScript 或 FastBlur，但 RenderScript 在新系统上已经弃用了。我建议直接用 Glide 的 .transform(BlurTransformation) 来做，因为 Glide 本身也有部分模糊能力。或者更简单地，把一张背景图放大后降低透明度，也可以模拟出类似的视觉层次感。唱片旋转动画实现很简单，就是给封面图设置 RotateAnimation，无限循环，线性插值器：val rotateAnimation = RotateAnimation( 0f, 360f, Animation.RELATIVE_TO_SELF, 0.5f, Animation.RELATIVE_TO_SELF, 0.5f ).apply { duration = 20000 repeatCount = Animation.INFINITE interpolator = LinearInterpolator() } coverImageView.startAnimation(rotateAnimation)播放时启动动画，暂停时调用 coverImageView.clearAnimation()。这里有一个体验细节：如果直接 clearAnimation，下次播放会从 0 度重新转，看起来不够连贯。更精细的做法是记录 onAnimationEnd 时的角度或者使用属性动画配合 ObjectAnimator，但这个属于加分项，不做也不影响验收。4.3 深色模式适配：先用资源目录做起来网易云在夜间模式做得很好，但作业里适配深色模式主要是展示你了解资源目录的限定符机制。我采用的做法是：颜色都定义在 values/colors.xml 中，然后在 values-night/colors.xml 里定义另一套颜色。这样系统切换深色模式时，界面会自动更换颜色。需要注意的一点是，不要写死颜色值，比如在布局里直接写 #FFFFFF 或 TextView 直接使用黑色，这样深色模式切换后文字和背景会糊在一起。全部改成 @color/xxx 引用，虽然前期麻烦，但之后切换主题会很丝滑。5. 作业中最常见的 5 个坑与排查实录5.1 MediaPlayer 状态机崩溃这是所有 MediaPlayer 项目中第一大崩溃来源。现象是：连续点击下一首，快速点击暂停/播放，或者播放完成后再次点击播放，应用容易在 setDataSource / start / stop 阶段报 IllegalStateException。我排查时把 PlayManager 里每个公开方法都加上状态判断。比如：fun play(song: Song) { releaseInternal() // 先释放旧播放器 if (state == PlayState.RELEASED || state == PlayState.IDLE) { createPlayer() } ... }再比如：fun pause() { if (!isPlaying()) return mediaPlayer?.pause() state = PlayState.PAUSED }isPlaying() 返回的是 mediaPlayer?.isPlaying == true。这样就把非法调用挡在门外。MediaPlayer 的文档里有很多状态切换图，作业阶段不需要背图，但要在代码里做防御，让每次调用都只在合法状态下执行。5.2 RecyclerView 复用导致高亮错乱这个坑我前面提过，再展开一次。第一次做的时候，我在 adapter 里用了一个 boolean isCurrentPlaying 字段，每次点播放就把这个字段设成 true，然后 notifyDataSetChanged。视觉上看起来没问题，滑动之后问题就来了——高亮跑到别的 Item 上，因为 Item View 被复用了，position 变了，而字段没有跟着变。正确做法是 adapter 不保存播放状态。播放状态只存在于 PlayManager 或 MainActivity 维护的一个变量中。adapter 的 onBindViewHolder 每次从外部读取 position 是否等于当前播放 index，然后设置 UI。如果你想让列表在播放状态切换时刷新得更精细，可以维护一个 oldIndex 和 newIndex，然后只刷新两个位置：adapter.notifyItemChanged(oldIndex) adapter.notifyItemChanged(newIndex)这样不会导致整个列表闪烁。5.3 旋转屏幕播放中断与状态丢失模拟器里旋转屏幕时，Activity 会重建。如果你把 MediaPlayer 放在 Activity 内部，音乐会直接停掉。我一开始就遇到这种情况。解决方案就是前面说的，把 MediaPlayer 放进 Application 级单例，并配合前台 Service 运行。这样 Activity 重建后，PlayManager 还在，进度、播放列表、当前歌曲都还在，界面只需要在 onResume 里重新读取状态即可。如果你只想用 ViewModel 保存状态也有一个办法：用 ViewModel 持有 MediaPlayer 引用，因为 ViewModel 在配置变更时不会销毁。但从后台播放能力来看，单例 + Service 是更正规的解法。5.4 通知栏与 Activity 通信失效通知栏的播放/暂停按钮点击后，Activity 里的 UI 没有更新，因为通知栏和 Activity 是两个不共享内存状态的组件吗？不，它们其实共享同一个 PlayManager 单例，所以状态是一致的。但问题出在更新 UI 的时机。Activity 在 onResume 时刷新一次界面，但如果用户在通知栏点击暂停，Activity 并没有收到任何事件，所以 UI 卡在播放状态。解决方式是使用一个简单的回调监听机制。PlayManager 里维护一个监听器列表：interface PlaybackListener { fun onPlayStateChanged(isPlaying: Boolean) fun onSongChanged(song: Song?) }Activity 在 onStart 注册监听，在 onStop 注销。通知栏点击暂停时会触发 PlayManager 的 pause，然后 PlayManager 通知所有监听器，Activity 就能实时更新。如果你还没有接触过 LiveData 或 StateFlow，手写一个监听器列表完全够用，也能让你更好地理解事件驱动逻辑。当然，用 LiveData 更省事，作业里用 LiveData 也是加分项。5.5 音频焦点抢占与暂停失效当你在调试播放器时，另一个 App 开始播放音乐，比如打开了短视频，音频焦点可能被抢走。如果你没有处理音频焦点，两个声音会同时出现，体验很差。正确做法是：开始播放前申请音频焦点，失去焦点时暂停，重新获得焦点后再继续。我在前面已经贴过核心代码，这里只补充一个细节：AUDIOFOCUS_GAIN 回调里不要无条件恢复播放。如果用户是手动暂停的，就不要在获得焦点后自动播放。判断方式是 PlayManager 里维护一个 userPaused 标志字段，区分暂停是用户主动触发的还是焦点被动引发的。6. 如果时间充裕，还可以往里做哪些扩展作业交完之后，回头做技术复盘时，我整理了三个真正有含金量的优化方向：第一，用 MediaStore 的 AlbumArt 读取封面，而不是只显示默认占位图。这个稍复杂，但效果提升明显。第二，把本地扫描迁移到协程 + Flow，配合 Loading 状态，体验会接近真实产品。第三，加入搜索框，用 SQLite Like 查询标题和歌手，这是非常经典的 SQL 应用场景。我个人觉得，这个项目的价值在于它把 Android 的四大组件、资源系统、多媒体框架全部串了一遍。做完之后你对 Activity 生命周期和 MediaPlayer 状态机的理解会非常扎实。最后分享一个小技巧：作业演示时，模拟器里最好预先放几首带封面的音频文件。很多同学在演示时因为模拟器没有音频文件，列表空荡荡，代码再完整都展示不出来。在开发者选项里把“不保留活动”关掉，演示时切换应用更流畅。
很多人在拿到“Android MAD HW3 仿网易云播放器”这个作业题的时候，第一反应是去找一套网易云的开源 UI 来抄，或者直接在 GitHub 上搜播放器 Demo。其实这个作业真正考察的并不是 UI 还原度，而是你有没有把一个播放器应用需要处理的状态管理、生命周期绑定、异步加载、媒体焦点这些核心问题想清楚。这次我把自己完成这个项目的完整思路、踩过的坑、以及最后整理出来的可复现代码框架记录下来，给正在做同类作业的同学一个参考。1. 先拆题：这个作业真正让你练什么1.1 仿写目标拆解：界面、交互、逻辑各占多少“仿网易云播放器”这个题目看起来是个 UI 任务，实际上拆开之后是四层内容叠加：静态界面、交互动效、音频播放逻辑、以及数据加载方式。界面层面，网易云播放器的特点是红白配色、Tab 底部导航、歌单列表封面、播放页黑底大字歌词。交互层面，包括列表点击跳转、播放页出现、底部迷你播放条跟随滚动。逻辑层面，MediaPlayer 的播放、暂停、切换、进度更新。数据层面，从本地媒体库扫描音频文件，或者从固定资源目录读取预置音频。我在动手之前列了一个优先级清单，分配给不同模块的精力大概是：列表 20%、播放逻辑 30%、通知栏和控制交互 20%、UI 美化 20%、其余 10%。如果只看 UI 而忽略播放逻辑，代码交上去很可能会变成“图片浏览器”而不是播放器。把 UI 做得简单一点没关系，但是播放器的核心状态流转必须完整。1.2 技术选型的取舍逻辑这个作业的常规技术栈是 RecyclerView + MediaPlayer + Service（或前台服务）。很多同学会纠结要不要上 ExoPlayer，我的建议是作业场景优先用 MediaPlayer。原因有几点：第一，MediaPlayer 是 Android 原生 API，状态机清晰，课程考察点往往就围绕它的生命周期展开；第二，ExoPlayer 虽然功能强，但依赖较多，如果目标仅仅是本地音频播放，属于过度设计；第三，MediaPlayer 配合 AudioManager 处理音频焦点时，代码模式非常经典，这些原理在工作后依然有参考价值。界面方面，我选择了单 Activity + 双 Fragment 的结构，主界面放列表，播放页用 Dialog 风格 Fragment 或者另一个 Fragment 切换。如果你接触过 Jetpack Navigation，用它管理这两个页面也很自然，但如果没有，用 supportFragmentManager 手动切换也可以，逻辑都一样。1.3 功能边界规划在开始写代码前，我把功能边界定为以下几条：扫描本地媒体库中的所有音频，按歌曲名、歌手、时长展示在列表中点击列表项播放对应音频，当前播放项高亮并显示播放状态底部迷你栏显示当前歌曲，可暂停/继续，点击可展开播放页播放页展示封面、歌词占位区、进度条、播放模式切换和上一首/下一首后台播放能力：退出应用界面后音乐继续播放，通知栏显示控制器处理来电/其他应用播放等音频焦点抢占场景这已经是一个完整播放器的骨架了。再多加内容，比如歌词滚动解析、VIP 模拟按钮、搜索筛选，在时间有限的情况下容易喧宾夺主。2. 项目骨架搭建：播放器类 App 的目录与架构2.1 分层目录规划做这个项目时，我在包结构上采用了基础的三层划分，不复杂但足够清晰：com.example.musicplayer ├── data/ │ ├── model/ │ │ └── Song.kt │ └── repository/ │ └── MusicRepository.kt ├── player/ │ └── PlayManager.kt ├── ui/ │ ├── list/ │ │ ├── SongListFragment.kt │ │ └── SongListAdapter.kt │ ├── player/ │ │ └── PlayerFragment.kt │ └── MainActivity.kt └── service/ └── PlaybackService.ktdata 层负责从 ContentResolver 读取音频文件的元数据，player 层只负责播放器的状态和操作方法，ui 层负责界面渲染与用户交互。实际写的时候还可以压缩得更简单，但我建议保留 repository 这一层，因为后续做假数据切换、缓存、单元测试都会方便很多。2.2 播放管理器封装：状态机是关键MediaPlayer 最让人头疼的地方是它自身带状态机，比如已经 release 之后再调用 stop 会抛异常，播放完成回调之后直接 start 也会出现问题。所以我在业务代码里没有直接操作 MediaPlayer，而是封装了一个 PlayManager，内部维护一个播放状态枚举。enum class PlayState { IDLE, // 初始状态，无媒体资源 PREPARING, // 正在准备 PLAYING, PAUSED, COMPLETED, RELEASED }对外暴露的接口包括：play(song, list)、pause()、resume()、seekTo()、next()、previous()、switchPlayMode() 和 release()。每一个方法第一步都是检查当前状态是否允许这个操作，比如 IDLE 状态下调用 pause 直接忽略。这一步看起来多余，但解决了 90% 的诡异崩溃问题。2.3 数据层：用 ContentResolver 扫本地音乐扫描本地音频的核心代码并不复杂，但需要知道正确的查询字段和排序逻辑。我使用的是 MediaStore.Audio.Media.EXTERNAL_CONTENT_URI，查询字段包括 _id、title、artist、duration、data（文件路径）、albumId 等。记住一点：Android 10（API 29）之后，data 字段已经不再是完全可信的路径，文件访问机制变成了作用域存储。如果只是拿路径去让 MediaPlayer 播放，在较新系统上偶尔能播放，但依赖 File 读取文件内容的方式会逐渐被禁止。作业场景下如果只是把 data 传给 MediaPlayer.setDataSource(path)，大多数机型还是可行的；但更稳妥的方案是使用 MediaStore 查询 URI，把它转换为 content:// 形式传给 MediaPlayer，这个我会在下一节详细说。3. 核心功能实现细节：从列表到播放的完整链路3.1 动态权限与媒体库扫描如果你直接跑查询 MediaStore 的代码，几乎一定会遇到 SecurityException。Android 6.0 以后，本地音乐读取属于运行时权限，需要在代码中请求 READ_MEDIA_AUDIO 或 READ_EXTERNAL_STORAGE。不同版本的权限申请方式不同，我在这块写了一个兼容判断：private fun requestAudioPermission() { val permission = if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) Manifest.permission.READ_MEDIA_AUDIO else Manifest.permission.READ_EXTERNAL_STORAGE if (ContextCompat.checkSelfPermission(requireContext(), permission) != PackageManager.PERMISSION_GRANTED ) { requestPermissions(arrayOf(permission), REQUEST_AUDIO_PERMISSION) } else { loadSongsFromMediaStore() } }这里有个容易忽略的细节：Android 13 上如果同时申请了 READ_MEDIA_AUDIO 和 READ_MEDIA_IMAGES，系统会弹出两个对话框，任何一个被拒绝都会影响后续逻辑。所以作业里只申请需要的权限，不要图省事把所有权限一起要。权限授予之后，查媒体库的代码大概是这样的：fun loadSongsFromMediaStore(): List<Song> { val songs = mutableListOf<Song>() val collection = MediaStore.Audio.Media.EXTERNAL_CONTENT_URI val projection = arrayOf( MediaStore.Audio.Media._ID, MediaStore.Audio.Media.TITLE, MediaStore.Audio.Media.ARTIST, MediaStore.Audio.Media.DURATION, MediaStore.Audio.Media.ALBUM_ID ) val selection = "${MediaStore.Audio.Media.IS_MUSIC} != 0" val sortOrder = "${MediaStore.Audio.Media.TITLE} ASC" context.contentResolver.query( collection, projection, selection, null, sortOrder )?.use { cursor -> val idCol = cursor.getColumnIndexOrThrow(MediaStore.Audio.Media._ID) val titleCol = cursor.getColumnIndexOrThrow(MediaStore.Audio.Media.TITLE) val artistCol = cursor.getColumnIndexOrThrow(MediaStore.Audio.Media.ARTIST) val durationCol = cursor.getColumnIndexOrThrow(MediaStore.Audio.Media.DURATION) val albumIdCol = cursor.getColumnIndexOrThrow(MediaStore.Audio.Media.ALBUM_ID) while (cursor.moveToNext()) { val id = cursor.getLong(idCol) val title = cursor.getString(titleCol) ?: "未知歌曲" val artist = cursor.getString(artistCol) ?: "未知歌手" val duration = cursor.getInt(durationCol) val albumId = cursor.getLong(albumIdCol) val contentUri = ContentUris.withAppendedId(collection, id) songs.add( Song( id = id, title = title, artist = artist, duration = duration, uri = contentUri.toString(), albumId = albumId ) ) } } return songs }作业里往往会给项目塞入音频资源文件，所以我也推荐在代码里做一步合并逻辑：把 res/raw 下的音频文件或 assets 目录里的音频解析为歌曲条目，追加到列表末尾。这样可以保证模拟器上没有音乐文件时，作业演示仍能正常播放。3.2 RecyclerView 列表与播放状态联动列表页是整个项目的门面，也是 RecyclerView 适配器最容易写崩的地方。我认真踩过这个坑：Item 复用时旧位置的状态会串到新位置上。比如第 5 个 Item 正在播放，往下滑动再滑回来，可能第 6 个 Item 也变成了播放中样式。解决办法有两个层面。第一层，adapter 不要保存播放状态，而是从唯一的数据源读取。我选择在 MainActivity 中维护一个 currentPlayIndex，把它传给 adapter，adapter 在 onBindViewHolder 时判断 position == currentPlayIndex 来决定是否显示高亮。第二层，每次列表数据更新或播放状态切换后，要调用 notifyDataSetChanged 或精确的 notifyItemChanged(旧位置) + notifyItemChanged(新位置)。在 onBindViewHolder 里大致的逻辑是：override fun onBindViewHolder(holder: SongViewHolder, position: Int) { val song = songs[position] holder.binding.title.text = song.title holder.binding.artist.text = song.artist val isPlaying = (position == currentPlayIndex) && isPlayingFlag holder.binding.root.isSelected = isPlaying holder.binding.playingIcon.visibility = if (isPlaying) View.VISIBLE else View.GONE }item 根布局的 isSelected 属性配合 selector 背景可以做到切换背景色，不用手动 bind 两次。如果你还没接触过 Selector，这个技巧会很实用：在 drawable 里定义 selected 状态的背景色，设置给 root，剩下的交给系统处理。点击事件要绑定在 itemView 上，点击时回调接口把 position 传给 ViewModel 或直接传给 Activity，由它去调用 PlayManager。3.3 MediaPlayer 封装与进度更新播放器核心我封装在 PlayManager 里。这里有一个很重要的设计：不要把 MediaPlayer 创建在 Activity 或 Fragment 中。因为只要界面旋转、销毁，MediaPlayer 就被带走了，音乐自然中断。作业要求里往往隐含了“退出界面后仍能播放”这一条，所以 MediaPlayer 要么放在前台 Service 中，要么放在一个 Application 级别的单例里。考虑到作业场景，我用了 Application 级单例 + 前台 Service 的组合。PlayManager 是单例，Service 只是承载通知栏与后台执行环境。如果你只做单例而不用 Service，应用退到后台后进程可能被回收，所以 Service 还是必要的。MediaPlayer 的标准用法是：mediaPlayer = MediaPlayer() mediaPlayer?.setAudioAttributes( AudioAttributes.Builder() .setContentType(AudioAttributes.CONTENT_TYPE_MUSIC) .setUsage(AudioAttributes.USAGE_MEDIA) .build() ) mediaPlayer?.setDataSource(song.uri) mediaPlayer?.prepareAsync()prepareAsync 是异步准备，需要监听 OnPreparedListener 再调用 start。如果直接同步 prepare，环境不好的情况下会卡住主线程。加载完成前可以展示 loading 状态，否则用户反复点击播放按钮容易产生卡顿感。进度更新的方式有两种：一种是使用 Handler 循环发消息，每 200ms 读取一次 currentPosition；另一种是使用 Lifecycle 的 repeatOnLifecycle 配合 kotlinx.coroutines 来处理。作业里用 Handler 最常见，也最好理解：private val progressHandler = Handler(Looper.getMainLooper()) private val progressRunnable = object : Runnable { override fun run() { val progress = playManager.getCurrentPosition() val duration = playManager.getDuration() if (duration > 0) { seekBar.progress = (progress * 1000 / duration).toInt() } progressHandler.postDelayed(this, 200) } }注意：进度条更新不要用类似 Thread.sleep 的循环来搞，这在主线程上会直接卡死 UI。Handler 的 postDelayed 是异步循环，不会阻塞主线程。如果你水平更高一点，可以把进度更新放在协程里，配合 lifecycleScope，但 Handler 足够应对课程验收。MediaPlayer 还有一个关键属性：播放完成监听。播放到末尾时，如果只有一首歌，应该回到开头暂停；如果有多首歌，应该自动进入下一首。我更倾向于在 OnCompletionListener 里先处理播放模式，再决定是循环播放、进入下一首还是暂停。3.4 通知栏控制与音频焦点通知栏控制器属于这个作业的加分项，但我觉得它应该是必做项，因为没有后台播放能力的播放器是不完整的。核心思路是使用 MediaSessionCompat + NotificationCompat 构建媒体通知。在较新版本上你还需要声明 POST_NOTIFICATIONS 权限，否则通知不显示。通知栏的 action 应该包括上一首、播放/暂停、下一首。点击通知跳回 MainActivity 时，要使用 PendingIntent.getActivity 并带上 FLAG_IMMUTABLE，这个是 Android 12 以上的硬性要求，不加会导致崩溃。音频焦点部分是一个容易被面试官问到的点。播放器应当监听 AudioManager 的音频焦点变化，比如电话打进来、其他播放器开始发声时暂停音乐。核心代码是对 OnAudioFocusChangeListener 的响应。我在实际代码里是这样处理的：audioManager = getSystemService(Context.AUDIO_SERVICE) as AudioManager val focusRequest = AudioFocusRequest.Builder(AudioManager.AUDIOFOCUS_GAIN) .setAudioAttributes( AudioAttributes.Builder() .setUsage(AudioAttributes.USAGE_MEDIA) .setContentType(AudioAttributes.CONTENT_TYPE_MUSIC) .build() ) .setAcceptsDelayedFocusGain(true) .setOnAudioFocusChangeListener { focusChange -> when (focusChange) { AudioManager.AUDIOFOCUS_LOSS -> { playManager.pause() } AudioManager.AUDIOFOCUS_LOSS_TRANSIENT -> { playManager.pause() } AudioManager.AUDIOFOCUS_GAIN -> { // 如果想恢复播放，可以在这里按需恢复 } } } .build()AUDIOFOCUS_LOSS 代表焦点永久丢失，比如切到了其他音乐 App，这时应该暂停，并且不要再试着恢复。AUDIOFOCUS_LOSS_TRANSIENT 是临时失去焦点，比如来电或语音助手，暂停后可以等待恢复。如果你不处理音频焦点，音乐会在来电时继续播放，这在作业演示和代码答辩里都是明显的减分项。4. 网易云风格 UI 还原的实用思路4.1 红白配色与圆角卡片布局网易云播放器的经典元素是红白配色和圆角卡片。我用的主色值是 #C20C0C，背景偏白或偏浅灰，列表项使用圆角背景加细线条分割。RecyclerView 的 item 布局在作业里可以做得比较简单：左侧是一个圆形或圆角方形封面占位图，中间偏左是歌名，歌名下方是歌手名，右侧是播放状态图标。封面图如果没有真实专辑图，可以使用一个默认图标，或者用 Palette API 从列表页的占位图颜色中提取主色作为封面底色。后者做出来效果会明显好很多，但复杂度略高。我建议先把默认图标和占位图方案跑通，有余力再做 Palette 取色。圆角卡片如果用 CardView 会方便很多，但如果你不想引入额外依赖，直接在 drawable 里写一个 shape 文件也可以：<shape xmlns:android="http://schemas.android.com/apk/res/android"> <solid android:color="@android:color/white" /> <corners android:radius="12dp" /> </shape>列表项间距通过 item 布局的 layout_margin 控制，分割线通过 divider 或 item 内部分割。4.2 播放页封面动效：旋转动画与模糊背景网易云播放页最深入人心的是那张大面积模糊背景和封面唱片旋转动画。模糊背景可以通过在布局中设置两个同样大小的 ImageView 实现：底层做模糊和缩放，上层显示封面图。模糊效果在作业里一般用 RenderScript 或 FastBlur，但 RenderScript 在新系统上已经弃用了。我建议直接用 Glide 的 .transform(BlurTransformation) 来做，因为 Glide 本身也有部分模糊能力。或者更简单地，把一张背景图放大后降低透明度，也可以模拟出类似的视觉层次感。唱片旋转动画实现很简单，就是给封面图设置 RotateAnimation，无限循环，线性插值器：val rotateAnimation = RotateAnimation( 0f, 360f, Animation.RELATIVE_TO_SELF, 0.5f, Animation.RELATIVE_TO_SELF, 0.5f ).apply { duration = 20000 repeatCount = Animation.INFINITE interpolator = LinearInterpolator() } coverImageView.startAnimation(rotateAnimation)播放时启动动画，暂停时调用 coverImageView.clearAnimation()。这里有一个体验细节：如果直接 clearAnimation，下次播放会从 0 度重新转，看起来不够连贯。更精细的做法是记录 onAnimationEnd 时的角度或者使用属性动画配合 ObjectAnimator，但这个属于加分项，不做也不影响验收。4.3 深色模式适配：先用资源目录做起来网易云在夜间模式做得很好，但作业里适配深色模式主要是展示你了解资源目录的限定符机制。我采用的做法是：颜色都定义在 values/colors.xml 中，然后在 values-night/colors.xml 里定义另一套颜色。这样系统切换深色模式时，界面会自动更换颜色。需要注意的一点是，不要写死颜色值，比如在布局里直接写 #FFFFFF 或 TextView 直接使用黑色，这样深色模式切换后文字和背景会糊在一起。全部改成 @color/xxx 引用，虽然前期麻烦，但之后切换主题会很丝滑。5. 作业中最常见的 5 个坑与排查实录5.1 MediaPlayer 状态机崩溃这是所有 MediaPlayer 项目中第一大崩溃来源。现象是：连续点击下一首，快速点击暂停/播放，或者播放完成后再次点击播放，应用容易在 setDataSource / start / stop 阶段报 IllegalStateException。我排查时把 PlayManager 里每个公开方法都加上状态判断。比如：fun play(song: Song) { releaseInternal() // 先释放旧播放器 if (state == PlayState.RELEASED || state == PlayState.IDLE) { createPlayer() } ... }再比如：fun pause() { if (!isPlaying()) return mediaPlayer?.pause() state = PlayState.PAUSED }isPlaying() 返回的是 mediaPlayer?.isPlaying == true。这样就把非法调用挡在门外。MediaPlayer 的文档里有很多状态切换图，作业阶段不需要背图，但要在代码里做防御，让每次调用都只在合法状态下执行。5.2 RecyclerView 复用导致高亮错乱这个坑我前面提过，再展开一次。第一次做的时候，我在 adapter 里用了一个 boolean isCurrentPlaying 字段，每次点播放就把这个字段设成 true，然后 notifyDataSetChanged。视觉上看起来没问题，滑动之后问题就来了——高亮跑到别的 Item 上，因为 Item View 被复用了，position 变了，而字段没有跟着变。正确做法是 adapter 不保存播放状态。播放状态只存在于 PlayManager 或 MainActivity 维护的一个变量中。adapter 的 onBindViewHolder 每次从外部读取 position 是否等于当前播放 index，然后设置 UI。如果你想让列表在播放状态切换时刷新得更精细，可以维护一个 oldIndex 和 newIndex，然后只刷新两个位置：adapter.notifyItemChanged(oldIndex) adapter.notifyItemChanged(newIndex)这样不会导致整个列表闪烁。5.3 旋转屏幕播放中断与状态丢失模拟器里旋转屏幕时，Activity 会重建。如果你把 MediaPlayer 放在 Activity 内部，音乐会直接停掉。我一开始就遇到这种情况。解决方案就是前面说的，把 MediaPlayer 放进 Application 级单例，并配合前台 Service 运行。这样 Activity 重建后，PlayManager 还在，进度、播放列表、当前歌曲都还在，界面只需要在 onResume 里重新读取状态即可。如果你只想用 ViewModel 保存状态也有一个办法：用 ViewModel 持有 MediaPlayer 引用，因为 ViewModel 在配置变更时不会销毁。但从后台播放能力来看，单例 + Service 是更正规的解法。5.4 通知栏与 Activity 通信失效通知栏的播放/暂停按钮点击后，Activity 里的 UI 没有更新，因为通知栏和 Activity 是两个不共享内存状态的组件吗？不，它们其实共享同一个 PlayManager 单例，所以状态是一致的。但问题出在更新 UI 的时机。Activity 在 onResume 时刷新一次界面，但如果用户在通知栏点击暂停，Activity 并没有收到任何事件，所以 UI 卡在播放状态。解决方式是使用一个简单的回调监听机制。PlayManager 里维护一个监听器列表：interface PlaybackListener { fun onPlayStateChanged(isPlaying: Boolean) fun onSongChanged(song: Song?) }Activity 在 onStart 注册监听，在 onStop 注销。通知栏点击暂停时会触发 PlayManager 的 pause，然后 PlayManager 通知所有监听器，Activity 就能实时更新。如果你还没有接触过 LiveData 或 StateFlow，手写一个监听器列表完全够用，也能让你更好地理解事件驱动逻辑。当然，用 LiveData 更省事，作业里用 LiveData 也是加分项。5.5 音频焦点抢占与暂停失效当你在调试播放器时，另一个 App 开始播放音乐，比如打开了短视频，音频焦点可能被抢走。如果你没有处理音频焦点，两个声音会同时出现，体验很差。正确做法是：开始播放前申请音频焦点，失去焦点时暂停，重新获得焦点后再继续。我在前面已经贴过核心代码，这里只补充一个细节：AUDIOFOCUS_GAIN 回调里不要无条件恢复播放。如果用户是手动暂停的，就不要在获得焦点后自动播放。判断方式是 PlayManager 里维护一个 userPaused 标志字段，区分暂停是用户主动触发的还是焦点被动引发的。6. 如果时间充裕，还可以往里做哪些扩展作业交完之后，回头做技术复盘时，我整理了三个真正有含金量的优化方向：第一，用 MediaStore 的 AlbumArt 读取封面，而不是只显示默认占位图。这个稍复杂，但效果提升明显。第二，把本地扫描迁移到协程 + Flow，配合 Loading 状态，体验会接近真实产品。第三，加入搜索框，用 SQLite Like 查询标题和歌手，这是非常经典的 SQL 应用场景。我个人觉得，这个项目的价值在于它把 Android 的四大组件、资源系统、多媒体框架全部串了一遍。做完之后你对 Activity 生命周期和 MediaPlayer 状态机的理解会非常扎实。最后分享一个小技巧：作业演示时，模拟器里最好预先放几首带封面的音频文件。很多同学在演示时因为模拟器没有音频文件，列表空荡荡，代码再完整都展示不出来。在开发者选项里把“不保留活动”关掉，演示时切换应用更流畅。