应用切到后台后音乐和课程音频还在播，用户已经把这当成基本要求。在阿里云的链路里，云端媒体服务和客户端系统要一起配好，才能做到不断播、不耗电失控。下面先说清楚后台播放指什么，再看客户端要配哪些项，最后用一个音频课的例子走一遍。
后台播放到底指什么
应用退到后台、屏幕熄灭或切到别的页面，音视频仍在输出，这就是后台播放。它和页面内播放的区别在于，系统是否允许应用继续占用音频输出。没配好的时候，常见现象是播了十几秒突然停，用户只会觉得这个App不稳定。
内容一般放在视频点播或对象存储里，经CDN送到终端，由播放器SDK负责拉取、解码和渲染。排查时要分两层看：内容能不能稳定拉下来，系统让不让它在后台继续跑。只顾一头，另一头出问题照样断。
客户端要配的几项
不同平台的写法不一样，但要配的东西大致对应。
- iOS：在工程的Background Modes里勾选音频相关选项，把AVAudioSession的类别设为playback，并在播放前激活会话。少了其中任何一步，切后台时系统都可能直接挂起音频。
- Android：播放要放在前台服务里跑，前台服务必须显示一条通知。较新的系统版本要求声明前台服务类型，媒体播放需要使用对应的类型。再通过MediaSession把播放状态报给系统，锁屏和通知栏的控件才有数据可用。
- 通用：播放器实例不要跟着页面走。页面一销毁，播放器跟着释放，后台自然也就没了。
很多团队在测试时会遇到同一个现象：前台播放正常，一退后台就断。多数情况下根源是最后一条，播放器绑在了页面生命周期上。把它挪到全局的播放服务里，页面只负责发指令，这类问题会少很多。
以在线教育音频课为例
设想一个在线教育App，每节约二十分钟的音频课，学员习惯通勤时听。音频放在对象存储里，经视频点播转码分发，客户端用播放器SDK播放。这个组合很常见，也正好能把几个环节串起来看。
上线初期，问题大致有三类。学员切去微信回消息，音频过十几秒就停；锁屏后，通知栏的进度条拖不动；弱网时切到后台，缓冲反复中断，听起来一段一段的。三个问题的原因不同，不能用同一招解决。
处理思路可以分层。前两个问题在客户端：开启后台音频能力，把播放器交给全局服务持有，再接入系统媒体控制，让锁屏显示封面、标题和进度。第三个问题更多在内容侧：音频本身不需要高码率，可以准备较低的码率档位，同时适当加长预加载时长，网络抖动时缓冲的余量会更大。
按这个思路调整后，后台中断的反馈会减少。但效果取决于具体的码率、网络环境和机型，不能直接套用别人的数字。这也说明后台播放要靠客户端配置、播放器架构和内容编码一起配合，任何一环单独做好都不够。
落地时的实施步骤
- 先确认内容形态。纯音频和音视频的码率、转码模板差别很大，这一步定下来，后面少返工。
- 完成客户端的后台权限配置，用真机验证锁屏、切换应用、来电打断这几个场景。模拟器对后台策略的还原度有限，不能只靠它。
- 把播放器实例交给全局服务管理，页面只发送播放、暂停、切集等指令。
- 接入锁屏控制和通知栏信息，封面、标题、进度三项都要有数据，缺一项，界面就显得不完整。
- 针对弱网设置缓冲策略，并在日志里记录切后台前后的卡顿事件，出问题时能复盘到具体时刻。
几点需要注意的地方
后台播放会耗电，也会多消耗流量。产品上最好给用户留出口，比如仅Wi-Fi下载、后台限制码率，让用户自己决定代价。
系统版本对后台的管控逐年收紧，今天能跑通的策略，换个系统版本可能就失效。发布前至少在主流机型和近两个系统版本上回归一遍，别把上一次的测试结果当成长期结论。
如果内容涉及版权，授权范围也要确认清楚。是否允许后台播放、是否允许离线缓存，都可能写在合同条款里。这一步容易被忽略，出了问题再整改，成本通常比前期确认高得多。
回到开头的问题，阿里云后台播放要看的配置主要是三类：客户端的后台模式和音频会话、播放器的生命周期、内容侧的码率和缓冲。三类都顾到，播放才会稳。
