8、音频策略与 AudioFlinger：音频 HAL 层、混音器（Mixer）、音频输出设备管理
好，咱们今天聊点硬核的。音频策略和 AudioFlinger，这两个东西是 Android 音频系统的骨架。说白了，上层 App 怎么发声、声音怎么混在一起、最后从哪个喇叭出来，全归它们管。
我个人习惯把 AudioFlinger 比作一个「音频大管家」。你想想看，手机里同时跑着音乐、通知、导航语音，这些声音不能乱成一锅粥吧？谁大声谁小声，谁该被掐掉，都得有个规矩。这个规矩，就是音频策略。
8.1 音频 HAL 层：硬件与系统的桥梁
先说说最底层的东西——HAL 层。HAL 的全称是 Hardware Abstraction Layer，硬件抽象层。它的作用很简单：让 AudioFlinger 不用关心你用的是高通还是联发科的芯片，也不用管喇叭是哪个厂家生产的。
我在项目中遇到过一件事：某款手机换了音频 Codec 芯片，上层代码一行没改，只换了 HAL 层的动态库就搞定了。这就是 HAL 的价值——隔离变化。
核心接口：Android 音频 HAL 定义了一套标准接口，主要包括：
open_output_stream：打开输出流，比如喇叭、耳机open_input_stream：打开输入流，比如麦克风set_parameters：设置硬件参数，比如音量、采样率standby：让硬件进入低功耗待机状态
嗯，这里要注意：HAL 层是运行在独立进程里的（mediaserver），不是内核驱动。它通过 Binder 和 AudioFlinger 通信。这样做的好处是，即使 HAL 崩溃了，也不会直接拉垮整个系统。
8.2 AudioFlinger 的核心职责
AudioFlinger 是 mediaserver 进程里的核心服务。它负责三件事：
- 管理音频输出设备——哪个设备在用，哪个设备空闲
- 混音（Mixer）——把多个音频流合成一路 PCM 数据
- 与 HAL 层交互——把混好的数据送出去
说白了，AudioFlinger 就是个「音频路由器」。它从各个 App 接收音频数据，按策略混音，然后发给正确的硬件设备。
我曾经调试过一个 Bug：播放音乐时突然插拔耳机，声音从喇叭出来但音量没变，差点把喇叭烧了。查到最后，是 AudioFlinger 的设备切换回调没处理好音量映射。从那以后，我特别关注设备切换时的状态同步。
8.3 混音器（Mixer）的工作原理
混音器是 AudioFlinger 里最核心的模块。它的任务很简单：把多个音频流叠加到一起。
你想想看，如果两个 App 同时播放 16 位 PCM 数据，每个采样点都是 0~65535 之间的整数。直接相加会怎么样？会溢出！所以混音器必须做饱和处理。
// 简化版混音逻辑
int32_t mixed = 0;
for (int i = 0; i < num_tracks; i++) {
mixed += track_samples[i];
}
// 饱和裁剪到 16 位范围
if (mixed > 32767) mixed = 32767;
if (mixed < -32768) mixed = -32768;
output_sample = (int16_t)mixed;当然，真实的 Mixer 比这复杂得多。它还要处理：
- 音量缩放：每个音轨有自己的音量，混音前先乘系数
- 重采样：不同音轨的采样率可能不同，得统一成输出设备的采样率
- 声道映射：单声道音轨要映射到立体声输出
我的经验：混音器的性能瓶颈往往不在加法运算，而在重采样。如果多个音轨的采样率差异很大，CPU 开销会暴涨。我建议尽量让所有音轨使用相同的采样率，比如 48000Hz。
8.4 音频输出设备管理
设备管理这块，AudioFlinger 维护了一张设备列表。每个设备都有一个唯一的 audio_devices_t 类型标识。
| 设备类型 | 标识值 | 说明 |
|---|---|---|
| 喇叭 | AUDIO_DEVICE_OUT_SPEAKER |
内置扬声器 |
| 耳机 | AUDIO_DEVICE_OUT_WIRED_HEADSET |
带麦克风的耳机 |
| 蓝牙 A2DP | AUDIO_DEVICE_OUT_BLUETOOTH_A2DP |
蓝牙立体声输出 |
| USB 音频 | AUDIO_DEVICE_OUT_USB_DEVICE |
USB 声卡或耳机 |
设备切换的逻辑是这样的：当音频策略引擎检测到新设备插入（比如插耳机），它会通知 AudioFlinger。AudioFlinger 会做以下几件事：
- 暂停当前输出线程
- 关闭旧设备的 HAL 输出流
- 打开新设备的 HAL 输出流
- 恢复输出线程，开始向新设备发送数据
这个切换过程必须非常快，否则用户会听到「啪」的一声爆音。我见过一些低端手机，切换时会有明显的 Pop Noise，就是因为 HAL 层的 standby 和 resume 没处理好。
8.5 音频策略引擎
音频策略引擎（Audio Policy Engine）是 AudioFlinger 的「大脑」。它决定：
- 哪个 App 的声音该走哪个设备
- 多个 App 同时播放时，谁该被抑制
- 音量按键应该调节哪个流的音量
策略引擎的核心是一个规则引擎。规则定义在 audio_policy_configuration.xml 文件里。举个例子：
<!-- 电话来电时，音乐音量应该被降低 -->
<rule>
<source>AUDIO_STREAM_MUSIC</source>
<sink>AUDIO_STREAM_VOICE_CALL</sink>
<action>DUCK</action>
<duck_level>0.2</duck_level>
</rule>这个规则的意思是：当语音通话流激活时，音乐流的音量降到 20%。这就是所谓的「音频焦点」机制。
避坑指南：我曾经遇到过一个 Case：某个第三方 App 播放音乐时，电话来了音乐没降音量。查了半天，发现是那个 App 用了 AudioAttributes.USAGE_GAME，而策略文件里只对 USAGE_MEDIA 做了 DUCK 处理。所以，写策略文件时一定要覆盖所有使用场景。
8.6 知识体系总览
下面这张图，是我梳理的音频策略与 AudioFlinger 的核心逻辑。你可以把它当作本章的「地图」：
从这张图可以看得很清楚：App 把音频数据交给 AudioFlinger，AudioFlinger 内部经过混音、策略判断、设备路由，最后通过 HAL 层送到硬件。每一层各司其职，缺一不可。
8.7 实战中的几个关键点
最后，我分享几个实际开发中容易踩的坑：
- 混音器溢出：多个音轨叠加时，如果音量都开到最大，输出会削波失真。建议在 HAL 层做一次软限幅（Soft Clipping）。
- 设备切换时序：插拔耳机时，AudioFlinger 和 HAL 层的状态机必须严格同步。我见过一个 Bug，切换时 HAL 层还在往旧设备写数据，导致内核崩溃。
- 策略文件热加载：
audio_policy_configuration.xml修改后需要重启 mediaserver 才能生效。调试时可以用adb shell killall mediaserver重启。
调试小技巧：用 adb shell dumpsys media.audio_flinger 可以查看当前所有音轨的状态、混音器参数、设备列表。这是排查音频问题的第一利器。
好了，关于音频策略和 AudioFlinger 的核心内容就这些。说白了，它就是一套「收数据 → 混音 → 送硬件」的流水线。理解了这个流程，你就能在 Android 音频开发中游刃有余。
公众号:蓝海资料掘金营，微信 deep3321