4、AudioFlinger引擎：混音机制、线程模型、数据流管理、延迟与性能优化
好，咱们今天聊聊AudioFlinger。这是Android音频系统的核心，说白了就是音频数据的“调度中心”。我当年刚接触这个模块时，觉得它就是个混音器，后来踩了不少坑才明白——它的线程模型和数据流管理，才是真正决定车载音频体验的关键。
4.1 混音机制：不只是“加在一起”那么简单
混音，就是把多个音频流合成一路。听起来简单？嗯，这里要注意：车载场景下，导航、电话、媒体、提示音可能同时出现。每个流的采样率、位深、声道数都可能不同。
AudioFlinger的混音核心在AudioMixer类。它做三件事：
- 重采样：把不同采样率的流统一到目标采样率。我建议用高质量的线性插值，别用简单的最近邻，否则音质会“糊”。
- 增益调整：每个流有自己的音量曲线。车载里，导航音通常要压低媒体音——这叫“闪避”（Ducking）。
- 声道映射：比如把立体声映射到5.1声道。车载音响布局复杂，这块容易出问题。
关键点：混音不是简单的加法。溢出处理、精度控制、浮点转定点，每一步都可能引入噪声。我在项目中遇到过，混音后出现“噼啪”声，最后发现是增益计算时整数溢出。
4.2 线程模型：谁在干活？
AudioFlinger的线程模型，我把它分成三类：
| 线程类型 | 职责 | 优先级 |
|---|---|---|
| MixerThread | 混音、写入HAL | 最高（URGENT_AUDIO） |
| RecordThread | 录音数据读取 | 高 |
| OffloadThread | 硬件直通（如MP3解码） | 中 |
为什么MixerThread优先级最高？因为音频数据是实时流，一旦延迟，就会出现“卡顿”或“断音”。我个人习惯，在车载项目中把MixerThread绑定到某个专用CPU核心上，避免被其他任务干扰。
线程间通信靠的是Track和RecordTrack对象。每个音频流对应一个Track，Track把数据写入共享内存，MixerThread定期去取。这里有个坑：如果Track写入太快，MixerThread来不及消费，缓冲区就会溢出。我曾经在调试车载蓝牙电话时，发现声音断断续续，最后定位到是蓝牙的写入速率比MixerThread的读取速率快了一点点。
4.3 数据流管理：从App到扬声器
数据流路径是这样的：
- App通过
AudioTrack写入数据到共享内存。 - AudioFlinger的
PlaybackThread（通常是MixerThread）从共享内存读取。 - 混音后，写入
AudioHAL的out_write接口。 - HAL把数据送到音频DSP或Codec，最终驱动扬声器。
每一步都有缓冲区。缓冲区大小直接影响延迟。车载场景下，导航提示音要求低延迟（<50ms），而媒体播放可以容忍稍高延迟（100-200ms）。
我的经验：在车载项目中，我会为导航和电话单独创建一条“低延迟通路”，绕过混音器，直接写入HAL。这样延迟能降到20ms以内。代价是失去了混音能力——但导航和电话通常不会同时播放，所以没问题。
4.4 延迟与性能优化：实战中的“硬骨头”
延迟，是车载音频的“原罪”。为什么？因为从触摸屏幕到听到声音，中间经过的路径太长了。我总结了几条优化原则：
- 减少缓冲区层级：每多一级缓冲区，就多一次拷贝和等待。能直通就直通。
- 使用FastMixer：Android 8.0引入的FastMixer，专门处理低延迟流。它运行在单独的、高优先级的线程上，缓冲区更小。
- 调整HAL的period_size和period_count：这两个参数控制HAL的缓冲区大小。period_size越小，延迟越低，但CPU开销越大。我建议从256帧开始调，逐步降低，直到出现Xrun（缓冲区欠载/过载）。
避坑指南：我曾经在某个车载平台上，把period_size从256降到128，延迟确实降低了，但导航语音偶尔出现“爆音”。最后发现是DSP的处理时间不够，导致数据没来得及处理。嗯，优化延迟不能只看AudioFlinger，还要看下游的DSP和Codec。
性能优化方面，我关注三个指标：
- CPU占用率：混音是计算密集型任务。如果CPU占用率超过30%，就要考虑优化了。比如，用NEON指令集加速重采样。
- Xrun次数：缓冲区欠载（underrun）或过载（overrun）的次数。理想情况是0。如果出现Xrun，要么增大缓冲区，要么优化线程调度。
- 调度延迟：线程被调度器挂起的时间。在车载Linux上，我会把AudioFlinger的线程设置为SCHED_FIFO策略，优先级90以上。
最后，说一个我常用的调试手段：用dumpsys media.audio_flinger查看每个线程的状态、缓冲区大小、Xrun计数。这比看日志直观多了。你想想看，如果Xrun计数一直在涨，那肯定是缓冲区配置有问题。
好了，这一章就到这里。下一章咱们聊聊AudioPolicy——它决定了“声音从哪里来，到哪里去”。