音频路由与策略：音频焦点竞争、蓝牙音频通道切换、CarPlay有线/无线音频
音频路由，说白了就是车机系统里最让人头疼的那根「水管」怎么走。我做了这么多年车载开发，遇到最多的线上问题，十有八九都跟音频打架有关。你想想看，导航要说话、音乐要播放、电话要接通、CarPlay还要投声音——这么多路音频同时涌进来，谁先谁后？谁该被掐掉？这就是我们今天要聊的核心。
音频焦点竞争：谁说了算？
Android系统里有个机制叫「音频焦点」（Audio Focus）。嗯，这名字起得挺形象——谁拿到焦点，谁就能出声。但车机环境比手机复杂得多。
我在项目中遇到过这样一个场景：用户正在用CarPlay听歌，突然手机导航播报「前方300米右转」，结果CarPlay音乐直接被静音了。用户投诉说「我明明在用CarPlay，为什么手机导航能抢走声音？」
这就是典型的焦点竞争问题。Android Auto和CarPlay作为外部投屏系统，它们的音频流在车机端其实是被当作一个「外部输入源」来处理的。车机系统需要自己维护一套焦点管理策略。
核心原则：车机端的音频焦点优先级应该高于投屏系统的内部焦点。也就是说，车机自己的导航、警告音、电话，应该能打断CarPlay/Android Auto的音频。
我建议的焦点分配策略是这样的：
| 优先级 | 音频类型 | 行为 |
|---|---|---|
| 1（最高） | 紧急警告音（碰撞预警、ADAS） | 完全抢占，其他音频静音 |
| 2 | 电话通话 | 暂停音乐/导航，通话结束后恢复 |
| 3 | 车机导航播报 | 降低音乐音量（Ducking），播报结束后恢复 |
| 4 | CarPlay/Android Auto媒体 | 正常播放，可被高优先级打断 |
| 5（最低） | 系统提示音、按键音 | 仅在无其他音频时播放 |
为什么要把CarPlay媒体放在第4级？说白了，CarPlay本身也有自己的焦点管理，但车机作为底层硬件控制者，必须拥有最终决定权。我曾经见过一个方案，车机完全把音频控制权交给了CarPlay，结果用户按方向盘上的「静音」键，CarPlay音乐停了，但车机导航还在大声播报——这显然不合理。
蓝牙音频通道切换：那条看不见的「管道」
蓝牙音频通道，是车载系统里最容易出幺蛾子的地方。你想想看，手机通过蓝牙连上车机，可以走A2DP（立体声音乐）、HFP（免提通话）、AVRCP（媒体控制）等多条通道。问题在于——这些通道不是同时都能用的。
我记得有一次调试，用户反馈说「连上蓝牙后，微信语音听不到」。查了半天，发现是HFP通道被占用了，而微信语音走的是A2DP通道。车机在建立蓝牙连接时，默认只开了HFP，没开A2DP。
我的习惯做法：在蓝牙连接建立后，主动检查并确保A2DP和HFP两条通道都处于可用状态。代码里可以这样处理：
// 蓝牙音频通道管理示例
BluetoothAdapter adapter = BluetoothAdapter.getDefaultAdapter();
BluetoothDevice device = adapter.getRemoteDevice(address);
// 检查A2DP连接状态
BluetoothA2dp a2dp = new BluetoothA2dp(context);
if (a2dp.getConnectionState(device) != BluetoothProfile.STATE_CONNECTED) {
// 主动发起A2DP连接
a2dp.connect(device);
}
// 检查HFP连接状态
BluetoothHeadset headset = new BluetoothHeadset(context);
if (headset.getConnectionState(device) != BluetoothProfile.STATE_CONNECTED) {
headset.connect(device);
}这里有个坑：不同手机厂商对蓝牙协议栈的实现有差异。有些手机在连接A2DP时，会自动断开HFP。我建议在切换音频通道时，加一个「延迟重连」机制——比如先断开A2DP，等200ms后再重新建立HFP连接。
注意：蓝牙音频通道切换时，一定要处理好「音频路由」的瞬断问题。我曾经遇到过切换通道时出现「噗」的一声爆音，后来发现是音频路由切换没有做淡入淡出处理。
CarPlay有线/无线音频：两种模式，一套逻辑
CarPlay的音频路由，说白了就是「数据走哪条路」的问题。有线CarPlay通过USB传输音频数据，无线CarPlay则走Wi-Fi。但不管哪种方式，最终都要经过车机的音频处理单元。
我画了一张图，帮你理清CarPlay音频的路由逻辑：
有线CarPlay的音频延迟更低，因为USB的带宽稳定、延迟可控。无线CarPlay虽然方便，但音频延迟会高一些——我实测过，大概在100-150ms左右。这个延迟对听歌影响不大，但如果你在做卡拉OK或者游戏类应用，就得注意了。
关键点：无论有线还是无线，CarPlay的音频数据到达车机后，都要经过车机的音频处理单元。车机需要根据当前的音频焦点状态，决定是否播放、是否混音、是否降低音量。
我建议在车机端实现一个「音频路由管理器」，专门处理这些逻辑：
// 音频路由管理器核心逻辑
public class AudioRouteManager {
private int currentFocusOwner = FOCUS_NONE;
private boolean isCarPlayActive = false;
private boolean isBluetoothActive = false;
public void onCarPlayAudioStart() {
// 检查当前焦点状态
if (currentFocusOwner == FOCUS_NAVIGATION) {
// 导航正在播报，CarPlay音频做Ducking处理
applyDucking(0.3f); // 降低到30%音量
} else if (currentFocusOwner == FOCUS_PHONE_CALL) {
// 电话进行中，拒绝CarPlay音频
rejectAudio("Phone call in progress");
return;
}
// 正常播放CarPlay音频
startCarPlayAudio();
currentFocusOwner = FOCUS_CARPLAY;
}
public void onBluetoothAudioRequest(int channelType) {
// 蓝牙音频通道切换逻辑
if (channelType == CHANNEL_A2DP) {
// 切换到立体声音乐通道
switchToA2DP();
} else if (channelType == CHANNEL_HFP) {
// 切换到免提通话通道
switchToHFP();
}
// 注意：切换时做淡入淡出
applyFadeIn(200); // 200ms淡入
}
}避坑指南：我曾经在无线CarPlay的音频路由上踩过一个坑——手机连着Wi-Fi，车机也连着Wi-Fi，结果音频数据走了两条路，出现了回声。后来发现是Wi-Fi Direct和车机Wi-Fi的IP路由冲突。解决方案是：在无线CarPlay连接时，强制车机断开其他Wi-Fi连接，只保留CarPlay的Wi-Fi通道。
嗯，音频路由这块，说白了就是「谁先来、谁后到、谁让谁」的问题。你只要把焦点管理、通道切换、有线/无线统一处理这三件事做好了，大部分音频问题都能解决。我个人习惯是在项目初期就把音频路由的架构设计好，不然后期改起来，那叫一个痛苦。