10、音频路由动态切换：场景触发路由切换（插拔耳机、蓝牙连接）、路由切换延迟优化、路由切换回调机制
音频路由的动态切换，说白了就是系统在运行时，根据外部事件自动把声音从一个设备转到另一个设备。你插上耳机，声音从扬声器切到耳机；你连上蓝牙音箱，声音自动切过去。这个机制如果做不好，用户就会听到「噗」的一声爆音，或者声音断断续续，体验极差。
我个人习惯把路由切换分成三个核心问题：什么时候切、怎么切得快、切完之后怎么通知上层。今天我们就一个一个掰开来讲。
10.1 场景触发路由切换
触发路由切换的场景，最常见的就是插拔耳机和蓝牙连接。我做过一个项目，用户反馈「插上耳机后，声音还在扬声器里放了两秒才切过来」。你想想看，这种体验有多糟糕。
10.1.1 插拔耳机
耳机插拔的检测，底层依赖 WiredAccessoryManager 和 AudioService 的配合。当耳机插入时，内核会通过 uevent 上报事件，WiredAccessoryManager 解析后调用 AudioService.setWiredDeviceConnectionState()。
这里有个关键点：插拔检测的时机。我曾经遇到过一个 case，耳机插入后系统检测到了，但路由切换却延迟了 800ms。后来发现是 AudioPolicyService 里有个锁竞争问题。
核心流程：
- 内核上报 uevent（耳机插入/拔出）
WiredAccessoryManager解析并调用AudioServiceAudioService更新设备状态，通知AudioPolicyServiceAudioPolicyService重新评估路由策略- 底层 HAL 执行设备切换
10.1.2 蓝牙连接
蓝牙音频设备的连接，比有线耳机复杂得多。因为蓝牙有 A2DP、HFP、AVRCP 等多个 profile，每个 profile 的连接状态变化都可能触发路由切换。
我记得有一次，用户连上蓝牙耳机后，音乐播放正常，但微信语音却走的是听筒。排查下来发现，是 BluetoothDevice 的 profile 连接顺序问题——A2DP 先连上了，但 HFP 还没连好，系统就提前做了路由决策。
我的建议：蓝牙路由切换不要只监听 ACTION_ACL_CONNECTED，要等 ACTION_A2DP_STATE_CHANGED 和 ACTION_HFP_STATE_CHANGED 都稳定后再触发路由切换。否则很容易出现「半连接」状态下的错误路由。
10.2 路由切换延迟优化
延迟优化，是音频路由里最考验功底的地方。用户能感知到的延迟，通常来自三个环节：事件检测延迟、策略决策延迟、底层切换延迟。
10.2.1 事件检测延迟
插拔耳机的检测，从内核上报到 Java 层收到回调，中间经过了好几个线程切换。我做过一个优化方案：在 native 层直接监听 uevent，绕过 Java 层的 Binder 调用，把检测延迟从 50ms 降到了 5ms 以内。
// 伪代码：native 层直接监听 uevent
void* uevent_listener(void* arg) {
int sock = uevent_open_socket();
while (1) {
char* msg = uevent_read(sock);
if (strstr(msg, "SUBSYSTEM=switch")) {
// 直接通知 AudioPolicyService
AudioPolicyService::onHeadsetPlugEvent();
}
}
}10.2.2 策略决策延迟
策略决策的延迟，往往是因为 AudioPolicyService 里做了太多不必要的计算。比如每次路由切换都要重新评估所有 stream 的路由，其实大部分 stream 的优先级根本没变。
我个人的优化思路是：缓存上一次的路由决策结果，只对受影响的 stream 做增量计算。举个例子，耳机插入时，只有 STREAM_MUSIC 和 STREAM_VOICE_CALL 需要重新评估，其他 stream 保持原样就好。
优化前后对比：
| 环节 | 优化前 | 优化后 |
|---|---|---|
| 事件检测 | 50ms（Java 层轮询） | 5ms（native 层监听） |
| 策略决策 | 30ms（全量评估） | 8ms（增量评估） |
| 底层切换 | 20ms（全量 reset） | 5ms（仅切换音频路径） |
| 总延迟 | 100ms | 18ms |
10.2.3 底层切换延迟
底层切换，说白了就是 HAL 层把音频数据从一条路径切到另一条路径。这里最容易出问题的是 音频 DSP 的重新配置。有些 DSP 在切换时需要重新加载固件，那延迟就奔着 100ms 去了。
我曾经踩过一个坑：某款芯片的 DSP 在切换路由时，会先 mute 所有音频通道，再 unmute 新通道。这个 mute/unmute 操作本身就要 30ms。后来我们改成了「交叉淡入淡出」的方式，新通道先以低音量播放，同时逐渐降低旧通道的音量，这样用户完全感觉不到切换过程。
注意：底层切换时，一定要处理好音频数据的连续性。如果旧设备的数据还没播完就切到新设备，用户会听到「咔」的一声爆音。我建议在切换前先 drain 掉旧设备的缓冲区，再开始新设备的播放。
10.3 路由切换回调机制
路由切换完成后，上层应用需要知道「现在声音走哪个设备了」。Android 提供了 AudioDeviceCallback 和 AudioManager.AudioDeviceCallback 两个回调接口。
10.3.1 AudioDeviceCallback
这个回调是在 AudioManager 层面注册的。当音频设备列表发生变化时，系统会回调 onAudioDevicesAdded() 和 onAudioDevicesRemoved()。
AudioManager audioManager = (AudioManager) getSystemService(Context.AUDIO_SERVICE);
audioManager.registerAudioDeviceCallback(new AudioDeviceCallback() {
@Override
public void onAudioDevicesAdded(AudioDeviceInfo[] addedDevices) {
for (AudioDeviceInfo device : addedDevices) {
Log.d("AudioRoute", "设备接入: " + device.getProductName());
// 这里可以判断设备类型，更新 UI 或调整播放策略
}
}
@Override
public void onAudioDevicesRemoved(AudioDeviceInfo[] removedDevices) {
for (AudioDeviceInfo device : removedDevices) {
Log.d("AudioRoute", "设备移除: " + device.getProductName());
}
}
}, null);这里有个细节：onAudioDevicesAdded 回调时，新设备可能还没完全准备好。比如蓝牙耳机刚连上时，A2DP 的音频通道可能还在初始化。我建议在回调里加一个 postDelayed，等 100ms 再真正做操作。
10.3.2 自定义回调机制
如果你需要更精细的控制，可以在 AudioPolicyService 层面注册自己的回调。比如，我想知道「路由切换的每一个阶段花了多少时间」，就可以在 AudioPolicyService 里埋点。
我的经验：在 AudioPolicyService 里加一个 IRouteCallback 接口，把路由切换的「开始-策略决策-底层切换-完成」四个阶段都回调出来。这样上层可以精确监控延迟，甚至可以做动态调优。
10.4 知识体系总览
下面这张图，把音频路由动态切换的核心逻辑串起来了。从事件触发到最终回调，每个环节的延迟优化点我都标了出来。
10.5 避坑指南
最后，分享几个我踩过的坑，希望能帮你少走弯路。
- 蓝牙设备「半连接」状态：我曾经遇到过蓝牙耳机 A2DP 连上了，但 HFP 还没连好，系统就切了路由。结果音乐播放正常，但通话没声音。解决方案是等所有 profile 都 ready 后再触发路由切换。
- 插拔检测的抖动：有些耳机的插头接触不良，会在插入瞬间产生多次插拔事件。我建议加一个 200ms 的去抖逻辑，只有状态稳定后才触发切换。
- 路由切换时的音频卡顿：如果旧设备的音频缓冲区还没清空就切到新设备，用户会听到「咔」的一声。我习惯在切换前先调用
AudioTrack.drain()或者flush()，确保数据完整。 - 回调线程问题：
AudioDeviceCallback的回调是在 Binder 线程池里执行的，不要在里面做耗时操作。如果需要更新 UI，记得 post 到主线程。
嗯，音频路由动态切换这块，说难不难，说简单也不简单。核心就是把握好「什么时候切、怎么切得快、切完怎么通知」这三个问题。只要把事件检测、策略决策、底层切换、回调通知这四个环节的延迟都优化到位，用户基本感觉不到切换过程。
公众号:蓝海资料掘金营，微信deep3321