7、音频焦点管理：AudioFocus请求与释放、多应用音频冲突处理
音频焦点，说白了就是车载系统里音频资源的“通行证”。
你想想看，车上那么多应用——导航、音乐、电话、语音助手——它们都想用喇叭。如果没有一套规则，那不就乱套了？导航播报时音乐还在炸，电话进来两边一起响，这体验谁受得了。
Android 的 AudioFocus 机制，就是来解决这个问题的。我做了这么多年车载开发，可以负责任地告诉你：音频焦点管理做得好不好，直接决定了用户对这套系统的第一印象。
7.1 音频焦点的基本概念
AudioFocus 是 Android 系统提供的一套音频资源协调机制。它不像锁那样强制，更像是一种“绅士协议”——应用之间通过请求和释放焦点来协商音频的使用权。
焦点类型主要有这么几种：
| 焦点类型 | 常量 | 说明 |
|---|---|---|
| 长期焦点 | AUDIOFOCUS_GAIN | 完全占用音频通道，其他应用应停止播放 |
| 短暂焦点 | AUDIOFOCUS_GAIN_TRANSIENT | 临时使用，比如导航播报，播完就释放 |
| 短暂可闪避焦点 | AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK | 临时使用，但允许其他应用降低音量继续播放 |
核心要点：车载场景下，导航播报通常用短暂焦点，音乐播放用长期焦点。电话进来时，音乐必须暂停——这是硬性要求。
7.2 请求与释放焦点的标准流程
先看一个最基础的请求示例。我个人习惯把焦点管理封装成一个工具类，这样各个模块调用起来都方便。
// 请求音频焦点
AudioManager audioManager = (AudioManager) context.getSystemService(Context.AUDIO_SERVICE);
AudioAttributes attrs = new AudioAttributes.Builder()
.setUsage(AudioAttributes.USAGE_MEDIA)
.setContentType(AudioAttributes.CONTENT_TYPE_MUSIC)
.build();
AudioFocusRequest focusRequest = new AudioFocusRequest.Builder(AudioManager.AUDIOFOCUS_GAIN)
.setAudioAttributes(attrs)
.setAcceptsDelayedFocusGain(true)
.setOnAudioFocusChangeListener(focusChangeListener)
.build();
int result = audioManager.requestAudioFocus(focusRequest);
if (result == AudioManager.AUDIOFOCUS_REQUEST_GRANTED) {
// 焦点获取成功，开始播放
startPlayback();
}释放焦点就更简单了：
// 释放音频焦点
audioManager.abandonAudioFocusRequest(focusRequest);我的经验：释放焦点一定要在 onPause 或 onStop 里做，别等到 onDestroy。我曾经遇到过一个 bug，应用切到后台后音乐还在响，查了半天发现是焦点没释放干净。
7.3 焦点变化的监听与处理
焦点不是申请了就完事了。其他应用随时可能抢走你的焦点。这时候你需要监听焦点变化事件。
private AudioManager.OnAudioFocusChangeListener focusChangeListener = new AudioManager.OnAudioFocusChangeListener() {
@Override
public void onAudioFocusChange(int focusChange) {
switch (focusChange) {
case AudioManager.AUDIOFOCUS_GAIN:
// 重新获得焦点，恢复播放
resumePlayback();
break;
case AudioManager.AUDIOFOCUS_LOSS:
// 永久失去焦点，停止播放
stopPlayback();
break;
case AudioManager.AUDIOFOCUS_LOSS_TRANSIENT:
// 暂时失去焦点，暂停播放
pausePlayback();
break;
case AudioManager.AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK:
// 暂时失去焦点，但可以降低音量继续
duckPlayback();
break;
}
}
};嗯，这里要注意：AUDIOFOCUS_LOSS 和 AUDIOFOCUS_LOSS_TRANSIENT 的区别。前者是永久性的，比如用户切到了另一个音乐应用；后者是临时性的，比如导航播报一下，播完就还给你。
7.4 多应用音频冲突处理策略
车载场景下，音频冲突比手机复杂得多。手机通常只有一个前台应用在出声，但车上可能同时有导航、音乐、电话、语音助手在运行。
我总结了一套处理策略，直接上表格：
| 场景 | 音乐应用 | 导航应用 | 电话应用 |
|---|---|---|---|
| 导航播报 | 降低音量（duck） | 正常播报 | 无影响 |
| 电话来电 | 暂停 | 暂停 | 响铃/通话 |
| 语音助手唤醒 | 暂停或降低音量 | 暂停 | 保持通话 |
| 音乐切换 | 新应用获得焦点 | 无影响 | 无影响 |
避坑指南：我曾经在某个项目中，导航播报时音乐 duck 了，但导航播完音乐音量没恢复。原因是导航应用释放焦点时没通知音乐应用。后来我们在焦点监听里加了音量恢复的逻辑，才彻底解决。
7.5 车载场景下的特殊处理
车载系统和手机有个很大的不同：车上有很多物理按键和旋钮。用户可能通过方向盘按键切歌，或者通过中控旋钮调节音量。这些操作也会触发音频焦点的变化。
我个人建议的做法是：
- 物理按键事件：统一由系统服务分发，应用层只监听焦点变化
- 多音区支持：有些高端车型前后排有独立的音频区域，焦点管理要区分音区
- 紧急音频：比如倒车雷达、碰撞预警，这些音频优先级最高，应直接抢占焦点
// 紧急音频的焦点请求，使用最高优先级
AudioAttributes emergencyAttrs = new AudioAttributes.Builder()
.setUsage(AudioAttributes.USAGE_EMERGENCY)
.setContentType(AudioAttributes.CONTENT_TYPE_SONIFICATION)
.build();
AudioFocusRequest emergencyRequest = new AudioFocusRequest.Builder(AudioManager.AUDIOFOCUS_GAIN)
.setAudioAttributes(emergencyAttrs)
.setForceDucking(true) // 强制其他应用闪避
.build();7.6 知识体系总览
下面这张图是我自己梳理的音频焦点管理知识体系，你可以对照着看：
7.7 实战中的避坑指南
最后，分享几个我踩过的坑：
- 不要滥用长期焦点：有些应用一启动就申请长期焦点，导致其他应用没法出声。正确的做法是只在需要播放时才申请。
- 注意焦点延迟：
setAcceptsDelayedFocusGain(true)这个设置很重要。如果系统暂时无法分配焦点，你的应用可以排队等待。 - 测试多应用场景：我建议至少同时开三个音频应用来测试焦点切换。很多问题在单应用测试时根本发现不了。
- 日志要打全：焦点变化、请求结果、释放时机，这些关键节点都要打日志。线上问题排查全靠它。
一个小技巧：在开发阶段，可以写一个简单的测试工具，模拟各种音频焦点抢占场景。这样能提前发现大部分冲突问题，省得后期返工。
音频焦点管理，说白了就是一套“礼貌”的规则。你尊重别人的焦点，别人也会尊重你的。车载系统里应用多、场景复杂，但只要把这套机制理解透了，多应用音频冲突其实没那么可怕。
公众号:蓝海资料掘金营，微信deep3321