15、低延迟同步方案：音视频低延迟场景分析、优化策略、Android O上下的差异
低延迟同步，说白了就是让声音和画面「几乎同时」到达你的耳朵和眼睛。我这些年做直播、K歌、远程会议，几乎每个项目都被延迟问题折磨过。你想想看，用户对着摄像头说话，结果半秒后才听到自己的回声——这种体验谁受得了？
今天我们就来拆解低延迟同步的核心问题。我会结合我踩过的坑，聊聊Android O前后到底发生了什么变化。
15.1 低延迟场景分析：哪些场景最敏感？
不是所有场景都需要低延迟。但有些场景，延迟高了就是灾难。
- 直播连麦：两个人对话，延迟超过200ms就会感觉「抢话」。我做过一个海外直播项目，用户反馈说「像在打卫星电话」——其实就是延迟到了400ms。
- K歌/实时合唱：这个更夸张。伴奏和歌声不同步，歌手直接跑调。我记得有一次测试，延迟只有150ms，但歌手说「我听着自己声音慢了半拍」。
- 远程会议：唇音同步要求极高。画面和声音错位超过100ms，观众就会觉得「口型对不上」。
- 游戏语音：尤其是FPS游戏，队友喊「左边有人」，你听到时已经凉了。
核心指标：业界公认的「可接受延迟」阈值如下：
| 场景 | 目标延迟 | 容忍上限 |
|---|---|---|
| 直播连麦 | < 150ms | 300ms |
| K歌/合唱 | < 80ms | 150ms |
| 远程会议 | < 200ms | 400ms |
| 游戏语音 | < 100ms | 200ms |
15.2 延迟从哪里来？—— 三大瓶颈
我习惯把延迟拆成三块：采集、处理、渲染。每一块都可能成为瓶颈。
15.2.1 采集端延迟
摄像头和麦克风都有自己的缓冲区。Android上，Camera2默认的预览回调延迟可能在30-50ms。麦克风更麻烦——AudioRecord的缓冲区大小直接影响延迟。我曾经在某个低端机上，发现麦克风缓冲区默认是4096帧，44.1kHz采样率下，光采集就延迟了93ms。
15.2.2 处理链路延迟
编码、解码、网络传输、音画同步算法——每一步都在吃时间。H.264编码一帧可能花10-30ms，解码差不多。网络抖动缓冲区（jitter buffer）更是延迟大户。我见过有人为了抗抖动，把缓冲区设到500ms——画面倒是稳了，但延迟也炸了。
15.2.3 渲染端延迟
AudioTrack的写入延迟、SurfaceView的VSync等待，都是隐藏的坑。Android O之前，AudioTrack的延迟很难精确控制，因为底层用的是AudioFlinger的混音线程，调度不可预测。
15.3 优化策略：我常用的三板斧
低延迟优化没有银弹。我一般从三个方向同时下手：
15.3.1 缩短缓冲区
这是最直接的方法。AudioRecord和AudioTrack都支持设置缓冲区大小。我建议用getMinBufferSize()获取最小值，然后手动调小。但注意——缓冲区太小会导致音频断断续续（Xrun）。
// 获取最小缓冲区
int minBufSize = AudioRecord.getMinBufferSize(
sampleRate, channelConfig, audioFormat);
// 实际使用可以比最小值略大，比如 1.5 倍
int actualBufSize = (int)(minBufSize * 1.5f);
audioRecord = new AudioRecord(
MediaRecorder.AudioSource.MIC,
sampleRate, channelConfig, audioFormat,
actualBufSize);
我的经验：在Android 8.0以上，可以尝试使用AudioAttributes的FLAG_LOW_LATENCY标志。这个标志会让AudioFlinger走低延迟路径，缓冲区更小，调度更积极。但注意——不是所有设备都支持。
15.3.2 音画同步时钟对齐
音频和视频各自有自己的时间戳。低延迟场景下，我建议用音频时钟作为主时钟。为什么？因为人耳对音频抖动的敏感度远高于视频。视频稍微跳一帧可能看不出来，但音频卡一下立马能感觉到。
具体做法：
- 音频渲染时，记录当前播放位置（通过
AudioTrack.getPlaybackHeadPosition()）。 - 视频渲染时，根据音频时钟计算应该显示哪一帧。
- 如果视频落后了，直接丢帧追赶上。
15.3.3 减少VSync等待
Android的SurfaceFlinger默认每16.67ms（60Hz）刷新一次。如果你在VSync信号到来前没准备好帧，就得等下一个周期。低延迟场景下，我建议使用Choreographer的postFrameCallback来精确控制渲染时机，而不是盲目等待。
15.4 Android O上下的差异：一个分水岭
Android 8.0（API 26）是一个重要的分水岭。我当年从Android N升级到O时，发现很多低延迟方案突然「变简单了」。为什么？
15.4.1 Android O 之前（API < 26）
- 音频延迟不可控：AudioFlinger的混音线程是全局的，你的App无法控制优先级。缓冲区大小只能通过
getMinBufferSize()获取，但实际延迟可能比理论值大很多。 - 视频渲染依赖SurfaceView：SurfaceView有自己的缓冲区队列，你无法精确控制帧的显示时间。我曾经在Android 7.1上做过测试，从编码完成到画面显示，平均延迟在80-120ms。
- 没有AAudio：那时候只有AudioTrack，延迟通常在50-100ms。想做到30ms以下？基本不可能。
15.4.2 Android O 之后（API >= 26）
- AAudio 来了：这是Google专门为低延迟音频设计的API。它绕过了AudioFlinger的混音线程，直接与音频驱动通信。延迟可以降到10ms以下。我亲自测过，在Pixel 2上，AAudio的往返延迟（采集+渲染）只有15ms。
- AudioTrack 支持低延迟模式：即使不用AAudio，AudioTrack也支持
PERFORMANCE_MODE_LOW_LATENCY。底层会使用更小的缓冲区，调度更积极。 - SurfaceView 改进：Android O引入了
SurfaceControl，允许更精细的帧控制。配合Choreographer，视频延迟可以降到40ms以内。
注意：AAudio虽然好，但有个坑——它不支持所有设备。尤其是某些国产ROM，可能没有正确实现AAudio HAL层。我建议在代码中做降级处理：优先使用AAudio，如果初始化失败，回退到AudioTrack。
15.5 一张图看懂低延迟同步方案
下面这张SVG图，是我梳理的低延迟同步核心流程。你可以看到音频和视频各自走不同的路径，但在渲染前通过「同步控制器」对齐。
15.6 实战建议：如何选择方案？
根据你的目标API级别，我建议这样选：
| 目标API | 音频方案 | 视频方案 | 预期延迟 |
|---|---|---|---|
| API < 26 | AudioTrack + 最小缓冲区 | SurfaceView + Choreographer | 80-150ms |
| API >= 26 | AAudio (首选) / AudioTrack低延迟模式 | SurfaceView + SurfaceControl | 20-50ms |
| API >= 29 | AAudio + 共享内存模式 | SurfaceView + 帧回调 | < 20ms |
我的建议：如果你的App需要支持Android 7.0以下设备，别想着极致低延迟了。老老实实用AudioTrack，把目标定在100ms以内。对于Android O以上，大胆上AAudio，配合视频丢帧策略，做到30ms以内完全可行。
嗯，低延迟同步这块内容不少。核心就是一句话：音频做主时钟，视频主动追赶，缓冲区能小就小。Android O带来的AAudio和低延迟模式，确实让事情简单了很多。但别忘了——底层硬件差异永远存在，测试覆盖所有目标设备才是王道。