AudioFlinger 在 Android 音频系统中负责什么？
AudioFlinger 是 Android 音频系统里的核心服务之一。它接收多个应用提交的音频数据，完成线程调度、混音、音量处理、设备路由，再把最终 PCM 数据送到 Audio HAL 和硬件设备。
如果把 Android 音频链路简化成一句话：应用负责生产音频数据，AudioFlinger 负责把这些数据按时、按策略、按设备播放出去。
从 AudioTrack 到 AudioFlinger
应用播放声音时，常见入口有 AudioTrack、MediaPlayer、ExoPlayer、AAudio 或 OpenSL ES。上层 API 不同，但底层都会和系统音频服务建立连接，把 PCM 数据写入共享缓冲区，AudioFlinger 的播放线程再从这些缓冲区取数据。
AudioTrack 更接近底层，适合游戏、音频处理、低延迟播放。MediaPlayer 和 ExoPlayer 处理解码、缓冲、网络等更复杂的问题，最终解码后的音频同样要进入系统播放链路。AAudio 主要服务低延迟场景，路径会尽量绕开不必要的中间层，但仍然要和系统音频策略、设备路由协作。
AudioFlinger 具体负责什么
第一是混音。多个应用可以同时播放声音：音乐、导航、通知、游戏音效、通话提示。AudioFlinger 会把不同 track 的 PCM 数据按采样率、声道、音量策略混合成最终输出流。
第二是线程模型。AudioFlinger 内部有不同类型的播放线程，例如 MixerThread、DirectOutputThread、OffloadThread。普通播放走混音线程；低延迟或硬件直通场景可能走 direct 或 offload 路径。不同线程决定了延迟、功耗和可混音能力。
第三是音量和效果。应用设置的 stream volume、系统音量策略、音效处理、左右声道、设备增益都会在这条链路上发生。音频问题排查时，不能只看应用写了什么数据，还要看系统最终如何处理。
第四是设备路由。耳机、扬声器、蓝牙、USB、HDMI、听筒都可能成为输出设备。路由策略通常由 AudioPolicyService 决定，但 AudioFlinger 要根据结果创建或切换实际输出线程。
为什么音频延迟会变高
音频延迟来自多个缓冲区叠加：应用缓冲、共享内存缓冲、AudioFlinger 混音缓冲、HAL 缓冲、硬件缓冲。任何一层变大，整体延迟都会上升。
普通音乐播放更关心稳定，不太在意几十毫秒延迟；游戏、乐器、实时语音更关心低延迟。低延迟路径通常要求采样率、声道数、buffer size 更接近硬件原生配置，否则系统需要重采样和额外混音，延迟就会上来。
排查低延迟问题时，可以先确认：
- 使用的 API 是否适合低延迟，AAudio 或低延迟 AudioTrack 优先。
- 采样率是否匹配设备原生输出。
- buffer size 是否过大。
- 是否走了混音线程而不是 fast track。
- 蓝牙设备是否引入不可避免的编码和传输延迟。
常见线上问题怎么定位
无声问题先看路由和焦点。应用可能写了数据，但音频焦点被抢，输出设备切到了蓝牙，或者 stream type/usage 配置不符合预期。
卡顿问题先看 underrun。应用生产数据不及时，AudioFlinger 读不到足够数据，就会出现断续。游戏和实时音频里，写入线程优先级、GC、锁竞争都会导致 underrun。
延迟问题要看缓冲和路径。普通混音路径、重采样、蓝牙编码、系统音效都可能增加延迟。
音量异常要看 AudioAttributes、stream type、设备音量曲线和系统策略。Android 新版本越来越强调用 AudioAttributes 表达用途，而不是只依赖旧 stream type。
理解 AudioFlinger 的价值
大多数业务开发不需要直接修改 AudioFlinger，但理解它能帮助你判断问题边界。应用写入慢，是应用线程问题；混音线程 underrun，是系统播放链路问题；蓝牙延迟，是设备和协议问题；焦点丢失，是策略问题。
音频系统的问题很少只在一层发生。AudioFlinger 是连接应用、系统策略、HAL 和硬件的中间层，看懂它，才能把“没声音”“卡顿”“延迟高”这些模糊现象拆成可定位的工程问题。