前言

做语音通话、音视频会议、直播连麦这类功能时，真正容易出问题的，往往不是播放和录制本身，而是音频路由。用户已经连上蓝牙耳机，录音却还在走机身麦克风。播放本来应该切到指定设备，最后还是交给系统自己判断。很多时候，问题不在接口失效，而在于我们一开始就把 API 20 的能力边界想得太大了。

鸿蒙 6 在音频设备管理上已经开始补齐关键能力，但输入路由和输出路由的开放程度并不一致，而且 API 20 和 API 21 之间有一条很明显的分界线。这个分界线不看清，后面的判断就很容易跑偏。

一、版本边界看清楚

很多人在写音频设备路由时，会直接把输入设备切换当成现成能力来讲，好像在 API 20 里已经可以随手调用 selectMediaInputDevice。这个写法不够严谨。顺着版本变化往下看，会发现 AudioSessionManager.selectMediaInputDevice 是在 API 21 才补进来的能力，不属于 API 20 的既有接口。

这件事带来的影响很直接。如果项目基线就是鸿蒙 6 API 20，那输入路由不能按应用侧自由切换来设计。你可以做设备发现，可以做设备选择入口，但不能把应用主动指定输入设备这件事，写成已经完全可用的能力。

不过这也不意味着 API 20 对输入设备完全没有支持。更接近实际的情况是，API 20 已经开始提供录音设备选择入口，思路偏向由系统统一承接设备发现和连接，再把选择动作交给用户完成。等到 API 21，输入路由才进一步开放到应用侧，可以直接在代码里改当前应用的输入设备。

所以，API 20 的重点不是自由切输入，而是围绕设备发现、系统选择入口和场景降级把体验做好。把这一层写清楚，整篇文章的判断才站得住。

二、输入路由真正复杂的在于场景约束

很多人一看到输入设备路由，就会下意识把它理解成设备选择问题。实际上，在鸿蒙的音频体系里，输入设备能不能切、切完之后系统会不会照着你的预期去工作，还和录音源类型强相关。

比如 SOURCE_TYPE_VOICE_COMMUNICATION，它天然就是给语音通话和视频会议这种实时通信场景准备的。这个源类型本身不是普通录音，它通常要和通话类渲染流一起工作，整个链路才会进入通话模式下的低时延和 3A 处理状态。这样一来，输入路由讨论的就不只是设备本身，还包括当前是不是已经进入通话链路。

这意味着，通话场景和普通采集场景不能混着谈。你做标准 VoIP 或会议，优先级应该是把通话链路跑通，拿到稳定的低时延、回声消除和噪声抑制。你做直播采集、专业录音或者更强调外设自由度的场景，再考虑普通麦克风采集和更灵活的设备管理方案。

很多项目之所以会觉得音频路由别扭，不是系统完全不行，而是一边想要通话模式的系统优化，一边又想要专业音频工具那种自由路由能力。这两套目标本来就不完全一致，放在同一个实现路径里，最后一定会拧巴。

三、输出路由可控范围没有想象中那么大

和输入侧相比，输出路由的控制能力开放得更早。应用已经可以通过 AudioRenderer.setDefaultOutputDevice 去调整当前应用的默认输出设备。不过这套能力的可控范围要看清楚，它更接近应用级默认输出切换，而不是设备级精确路由。

实际能控制的目标，主要还是听筒、扬声器和系统默认这一层。也就是说，应用可以决定当前声音优先走哪一类输出路径，但这不等于你已经拿到了任意指定某个蓝牙耳机、某个 USB 声卡、某个具体外接设备的能力。

这里很容易出现一个误判。接口已经开放了，于是就默认它应该支持所有外设精确控制。可真正落到能力边界上，会发现它解决的是应用级输出方向问题，而不是完整的多设备精细路由问题。

如果你的需求是语音消息外放、通话听筒切换、媒体播放在扬声器和默认设备之间切换，这套能力已经够用了。

但如果你的目标是多个外设同时连接后，程序自己精确决定到底走哪一个具体端点，那这就不是当前这一层接口能完整承担的事情。

四、不要把系统选择组件和底层路由接口混成一件事

鸿蒙在音频设备管理上，其实是两条思路同时在走。

一条是应用直接调接口。比如输入侧后续新增的 selectMediaInputDevice，以及输出侧已有的 setDefaultOutputDevice。这类能力强调的是程序控制，适合应用自己有一套明确的状态机，知道什么时候切、切给谁、失败后怎么回退。

另一条是统一的设备选择入口。录音设备有对应的选择组件，投播和外部设备连接也有统一入口。这类能力更强调系统一致性，重点不在于让应用完全接管设备管理，而在于给用户一个统一、稳定、可预期的选择过程。

很多项目的问题，不是某个接口不好用，而是本来更适合走系统选择入口，最后却硬要在应用层自己接管全部逻辑。结果是设备发现、连接状态、切换时机、失败回退，全都要自己兜。代码当然能写，但维护成本会迅速上升。

五、真正有效的优化，是顺着边界设计方案

音频设备路由最怕的，不是能力少，而是预期错位。你以为自己拿到的是专业级、可精确编排的多设备控制接口，结果系统给你的其实只是应用级默认路由，或者一个标准化的设备选择入口。只要这一点没想清楚，后面无论做通话、会议、直播还是语音消息，都会不断遇到设计上的别扭感。

站在工程落地的角度，更靠谱的思路通常有三层。

先把 API 20 和 API 21 的能力边界分清楚，不要把后续新增的接口提前写进旧基线。通话模式和普通录音模式分清楚，不要把 3A、低时延和自由设备切换混成一个话题。把系统组件和底层控制接口分清楚，适合交给系统的部分，就不要在应用层硬接管。

这种做法看起来不激进，但它能显著减少兼容性问题，也能让项目后续升级时更顺滑。很多时候，真正决定体验的不是你写了多少控制逻辑，而是你有没有按系统当前给出的边界去设计。

总结

如果只用一句话来概括鸿蒙 6 的音频设备路由现状，那就是基础能力已经有了，但输入路由的细粒度控制还没有完全下放到应用侧。API 20 更像一个过渡节点，系统已经开始提供录音设备选择入口；到了 API 21，应用对输入设备的程序化切换才进一步落地。输出侧开放得更早，但控制范围主要还是听筒、扬声器和系统默认这一层，而不是任意指定具体外设。

所以，我真正想说的，不是鸿蒙在音频路由上限制很多，而是做这类功能时，必须先把系统当前能做什么、不能做什么想清楚。该走系统入口的时候走系统入口，该走应用级路由的时候走应用级路由，还没开放到那一步的能力，就不要硬写成已经具备。