1. 先搞懂AAudio到底在管什么1.1 从一次卡顿说起做Android音频开发的兄弟大概率都遇到过这种场景你兴致勃勃地把录音或播放链路切到了AAudio一跑起来声音倒是出来了可放不了几秒钟就“咔哒”一声然后就是断断续续的爆音、迟缓、跟手度全无。更郁闷的是同一段代码在A设备上跑得很稳换到B设备上卡成幻灯片在C设备上又完全正常。这种玄学问题十有八九不是解码器出Bug也不是硬件坏了而是音频流的流控机制没有吃透。AAudio是Android 8.0开始推出的原生音频API目标很明确用更低的延迟、更稳定的调度替代老牌的OpenSL ES让做乐器App、K歌、实时音效、专业录音的人能有接近iOS那套AudioUnit的体验。但“低延迟”这件事本身就是把双刃剑——延迟越低缓冲区就越小缓冲区越小系统稍微抖一下卡顿就来了。这篇文章我不打算念文档而是站在实际调过的项目角度把AAudio的流控机制拆开讲清楚数据到底怎么流动、缓冲区和underrun之间的关系、卡顿出现时怎么定位以及最后能直接抄作业的解决方案。无论你是在写播放器、录音器还是做低延迟音效引擎这套思路基本通用。1.2 AAudio在音频链条中的位置先对齐一下基础位置。Android的音频链路从上到下大概是这样的你的App代码Java层AudioTrack/AudioRecord或者NDK层的AAudio→ AudioFlinger系统混音服务→ Audio HAL硬件抽象层→ 底层驱动 → 声卡或DSP。AAudio虽然挂在NDK层但它和AudioTrack最大的区别是AAudio支持“不受混音影响”的独占路径。默认情况下App的声音都要进AudioFlinger的Mixer里跟其他声音混在一起再统一送到底层。这个过程很方便但混音、重采样、通道转换都会有额外开销和延迟。AAudio开启低延迟模式、占上独占模式之后它会尝试走一条更短的路径——相当于从你家小区门口直接上高速不再绕到市区转一圈。最终能不能走上快捷路径由系统根据硬件能力、当前设备状态决定但只要你把参数设对了大多数现代设备都会给你走MMAP这条相对直接的通道。理解了它在链条中的位置后面所有流控概念都好解释了。2. 流控机制的核心数据是怎么流动的2.1 frames、burst和缓冲区AAudio里你打交道最多的是frames这个概念。一个frame在音频里不是“一帧画面”而是“一次采样周期内所有声道分别采一个样本”的集合。比如双声道16bit的音频一个frame就是2个采样点4个字节。你用采样率44100就代表每秒要输送44100个frame给硬件。AudioStream建立之后系统会告诉你两个关键值framesPerBurst每次硬件中断或者说一次burst期望接收的frame数量可以理解成“水管每次喷水的颗粒度”。bufferCapacityInFrames缓冲区最多能装的frames数量相当于水管的缓存池。但capacity只是上限真正决定延迟大小的是实际使用多少缓冲区。很多人在调低延迟时犯的错误是只改了capacity没改buffer size导致缓冲区仍然很大延迟没降下来卡顿倒是依然存在。一个比较经典的目标如果你的采样率是48000每burst是192帧常见的FastMixer/MMAP里burst通常192或240帧那么一次burst持续的时间就是192÷480004ms。缓冲区如果设置成2个burst左右约384帧端侧延迟大概8ms加上路径上的固定开销整体能在20ms上下——人耳对延迟能感知的阈值一般在20~30ms附近所以这个水平已经相当可用。2.2 两种数据读写模式回调与阻塞AAudio提供了两种数据交互方式流控行为完全不同。第一种是数据回调模式callback。你给stream注册一个回调系统每个burst周期会调用你一次让你往缓冲区里填数据播放或读数据录音。aaudio_data_callback_result_t myDataCallback( AAudioStream *stream, void *userData, void *audioData, int32_t numFrames) { // 把numFrames个frame的数据填充到audioData中 fillFrames(audioData, numFrames); return AAUDIO_CALLBACK_RESULT_CONTINUE; }回调模式的好处是回调线程由AAudio内部管理优先级高而且节奏跟硬件中断对齐你不需要自己熬夜算延迟。坏处也很明显回调里不能做任何可能阻塞的事否则就会拖垮整个管线。第二种是阻塞读写模式Blocking Read/Write。你主动调AAudioStream_write()或者AAudioStream_read()就像往水管里手动灌水。这种方式使用起来更直观尤其是已经有现成音频处理代码的人迁移成本低。int64_t written AAudioStream_write(stream, buffer, framesToWrite, timeoutNanos);阻塞模式下缓冲区大小、当前水管里有多少积水是可以主动感知的。如果写入太快会“憋住”写入太慢就会断流。那该选哪种我的习惯是做播放器且没有复杂实时处理需求可以用阻塞写做乐器、实时耳返、变声这种对时序敏感的必须上回调。2.3 独占/共享低延迟/省电AAudio builder里有几个“命运开关”它们组合出来的流控行为差异非常大。共享模式AAUDIO_SHARING_MODE_SHARED会让你的流跟其他App混流兼容性好但延迟高且可能被其他声音干扰AAUDIO_SHARING_MODE_EXCLUSIVE试图独占硬件通道延迟低但并不是所有设备都能拿到独占权限拿不到时系统会自动降级为共享。性能模式AAUDIO_PERFORMANCE_MODE_LOW_LATENCY是低延迟模式系统会尽量用小缓冲区、高优先级调度AAUDIO_PERFORMANCE_MODE_NONE是功耗优先延迟相对高适合后台播放这种不敏感场景。实际项目里低延迟音乐应用一般都这样组合性能模式选LOW_LATENCY共享模式先请求EXCLUSIVE拿到好评测拿不到也接受SHARED。要注意的是这俩参数主要是“请求”不是“保证”。系统会根据硬件和当前负载决定最终形态所以你以为自己在独占低延迟运行时的实际参数可能已经不是那么回事了。判断最终值最简单的方式就是在stream打开之后主动查一遍AAudioStream_getSharingMode(stream); AAudioStream_getPerformanceMode(stream);如果拿到的结果和你预期的差距很大后面调优方向就要跟着变。3. 卡顿是怎么产生的流控链路中的瓶颈排查3.1 underrun与overrun音频流的“断粮”和“积压”音频流卡顿最直接的原因永远是同一个缓冲区里没有足够的frame可送或者送的频率不稳定。播放场景里硬件按固定节奏消费数据你负责往缓冲区里填数据。如果你填的速度跟不上硬件消费的速度缓冲区就被掏空了这时候就是underrun下溢。硬件发现没数据可播只能中断输出你听到的就是爆音、咔哒声严重时整段丢音频。录音场景反过来硬件不停往缓冲区里塞数据如果你不及时读走缓冲区满了还继续塞新的数据没地方放只能丢掉这就是overrun上溢。录音结果听起来像是掉了几个字、节奏忽快忽慢。这两个概念一定得刻在脑子里。凡是碰到AAudio卡顿第一步不是猜设备而是确认到底是哪种情况。3.2 真正让音频流卡顿的五个常见原因缓冲区设置过小。很多人一味追求低延迟把buffer size压到1个burst甚至更低。设备调度稍微波动一次立刻underrun。低延迟和稳定性之间必须有妥协点。回调里干了重活。在onAudioStreamReady回调里做解码、网络读取、内存分配、加锁、打日志都会让回调执行时间超过一个burst周期。这样做导致的后果是你的处理逻辑变成串行某个周期来不及供货缓冲区就空了。系统调度抖动。Android不是硬实时系统。DDL、动画、GC、其他App抢占CPU、系统服务突发访问I/O都会让你的音频回调线程偶尔得不到CPU。如果缓冲区只有一个burst的余粮一小下抖动就能引爆卡顿。路径未走低延迟快速通道。参数没设对或设备不支持流走的是普通混音通道中间多了混音、重采样、通道转换环节。延迟变大卡顿感知也会放大尤其是在做一些对时序要求较高的交互时。并发音频场景互相抢资源。比如你在用AAudio播放的时候系统来了一条通知音或者另一个App在录屏、播放视频、开沉浸式导航语音这时硬件资源被抢占stream也容易出问题。录屏时掉帧、声音卡顿一起出现已经不是音频单点问题了而是整机CPU和总线带宽都紧张。4. 定位问题的实操流程4.1 先用日志和数据判断是否真的underrun很多同学一遇卡顿就想着调大缓冲区但调大多少、往哪个方向调都凭感觉。正确做法是先量化。AAudio有一个很实用的查询AAudioStream_getFramesWritten()和AAudioStream_getFramesRead()。播放场景里written表示应用累计写入的frames数read表示硬件累计消费的frames数。两者的差值就是当前缓冲区里滞留的frames数量。我通常会在一个专门的调试线程里每500ms采样一次这两个值。写一个小探测函数int64_t framesWritten AAudioStream_getFramesWritten(stream); int64_t framesRead AAudioStream_getFramesRead(stream); int64_t bufferedFrames framesWritten - framesRead; int32_t bufferSize AAudioStream_getBufferSizeInFrames(stream); int32_t capacity AAudioStream_getBufferCapacityInFrames(stream);观察一段时间之后你就能得出三个结论bufferedFrames经常掉到0附近说明underrun频繁缓冲区余量不足。bufferedFrames长期接近capacity说明写入太激进或者消费速度跟不上需要加快读或者减小写入节奏。bufferedFrames稳定在buffer size的一半左右且波动小说明供需平衡这个状态最健康。音频框架本身也可能有性能计数器。AAudio在logcat里会在出现underrun时打印类似UNDERRUN、overrun的日志但不同厂商ROM日志格式差异很大有的根本不打。所以不能只依赖logcat自己做的监测才是最可靠的。4.2 用时间戳和frames计算延迟抖动除了数量上的监控还要看时序稳定性。AAudio提供了时间戳接口返回一组framePosition和对应的timeNanoseconds可以理解成“某个时间点硬件处理到第几个frame”。AAudioStream_getTimestamp(stream, CLOCK_MONOTONIC, framePosition, timeNanoseconds);通过连续取两次时间戳可以估算出硬件的实际消费速度和间隔。间隔稳定说明调度平稳间隔忽大忽小说明系统调度有抖动这时候即使平均下来不卡也会偶发爆音。延时抖动是比underrun更难查的问题。建议做法是在回调入口和出口各记录一次时间戳连续跑一分钟统计回调周期的均值、最大值和标准差。如果最大周期经常超过中位数的两倍以上这系统调度就很不稳必须从优先级和缓冲区余量两个方向补强。5. 解决卡顿的完整方案5.1 参数调整合理设置buffer capacity参数是能最快见效的部分。调优时按这个顺序来先确认帧率和burst大小。以48000Hz、burst为192帧的设备为例理论上1个burst是4ms。如果目标是低延迟建议buffer size从2个burst起跳也就是384帧左右。跑起来之后观察underrun情况再每次增加64或96帧直到卡顿消失。这一步我用的是“最小稳定值”思路从能接受的最低延迟开始逐步加缓冲区直到连续跑5分钟无underrun为止。不要一上来就贪大缓冲区过大延迟就上来了交互类应用会明显觉得声音发“木”。capacity的设定则要预留余量。一般设成buffer size的2到4倍这样系统在极端抖动时还能通过临时扩buffer来救场。不过capacity本身只是上限能不能在运行时扩容还要看driver是否支持代码里可以先查询bool isDynamic; AAudioStream_isBufferSizeRangeSupported(stream, isDynamic); if (isDynamic) { AAudioStream_setBufferSizeInFrames(stream, targetSize); }不支持运行时调整的设备只能关闭stream重新以目标size打开。5.2 代码侧优化别在回调里捅娄子回调函数是流控的心脏。我在代码审查里最常说的话就是回调里只能有一类操作——把数据从这个地址搬去另一个地址。具体来说这几个行为是绝对不能出现在回调里的内存分配malloc、new、std::string都不行锁操作pthread_mutex_lock、std::mutex都要避开文件I/O、网络I/O过度复杂的算法或浮点运算密集操作例如高频FFT如果做不过来就分包到普通工作线程打日志__android_log_print是有开销的还可能导致线程阻塞如果数据处理很重正确姿势是在回调里只做轻量拷贝或队列写入然后在另一个优先级合适的线程里做解码、重采样、特效计算。数据交接用无锁环形缓冲经典的SPSC Queue就行。另外stream里的参数设置也值得留意。如果Builder默认sample rate、channel count和format与你源数据不一致AAudio会专门开一个转换器。重采样和通道转换是CPU开销也是潜在的卡顿隐患。能提前把数据转成与stream一致的格式比在回调里让系统动态转要稳妥。5.3 架构级调整切换路径、线程、插拔保护代码级优化之后卡顿问题通常能解决百分之七八十。剩下的属于架构和外围问题需要在更高层面做保护。请求低延迟路径但做好降级预案。设备不支持独占模式时系统会退回共享模式。代码里要监听实际状态如果发现实际性能模式或共享模式不符合预期提醒自己当前是“降级”状态不要再用最高规格的假设做性能调优。管理App的音频焦点。有通知进来、有电话、有其他播放器启动时AAudio并不自动帮你停流。不做焦点处理的App会出现声音突然变杂、被混叠、忽大忽小的情况。监听焦点的丢失及时暂停、清理或降低音量保证卡顿感知不明显。设备插拔和路由变化保护。插入耳机、拔出耳机、连接蓝牙音频链路会重建stream状态会变化。要对AAudioStream_state变化做监听链路断开时及时重启stream否则可能出现采集不到声音或播放半天什么都没出来。线程优先级调整。有些设备上回调线程虽然不低但你自己创建的工作线程默认优先级不够高数据处理不及时也会饿着回调。工作线程可以用最朴素的setPriority提高优先级但不能滥用否则干扰到系统调度反而会加剧抖动。6. 常见问题速查与避坑经验6.1 卡顿场景速查表现象大概率原因排查方向解决手段播放出现周期性“咔哒”声缓冲区过小导致underrun查看framesWritten-framesRead是否常为0逐步增大buffer size找到最小稳定值录音随机丢字、掉时长overrun缓冲区满了新数据被丢弃查看录音侧的framesRead是否追不上written增大录音buffer或减少回调内处理时间一按屏幕/开始动画就卡系统调度抖动对比回调周期与动画时段增加buffer余量优化回调内耗时插拔耳机后卡顿路由变化导致stream状态异常检查state和logcat的route切换日志监听状态变化重建设备恢复stream锁屏后一段时间再解锁声音变糊设备进入低功耗模式检查性能模式与system suspend锁屏期间暂停播放解锁后重建或者使用WAKE_LOCK录屏同时播放声音卡顿掉帧CPU/总线竞争整机负载过高看系统负载和线程调度统计降低屏幕录制码率、限制后台任务、增加音频buffer余量后台有App播放另一个流时被混音干扰共享模式下与其他AudioTrack混流确认sharing mode是否为EXCLUSIVE请求独占模式无法独占时降低本App的延迟预期6.2 我踩过的几个坑第一个坑是盲目相信系统日志。曾经有个项目在低端机上产生大量underrunlogcat却干干净净查了一天没结果。后来自己做了frames差值统计才发现underrun确实存在只是厂商ROM把日志打到了别的地方。现在我的习惯是日志只做参考自己主动统计才作数。第二个坑是在回调里顺手做了一次数据拷贝和格式转换当时觉得就几十个KB不至于出问题。结果在负载高的场景下偶尔一次耗时飙到十几毫秒一个burst才4毫秒直接连续丢了好几个burst。后来把格式转换挪到了初始化阶段同时用查表代替了部分计算卡顿立竿见影地消失了。第三个坑是关于蓝牙设备。蓝牙音频的burst和帧率跟有线完全不一样SBC/AAC/LC3编码器的引入让延迟和buffer需求都有变化。同一套buffer参数有线耳机不卡蓝牙耳机卡到怀疑人生。处理这类场景至少要判断当前输出设备给蓝牙单独准备一套buffer策略不要把有线场景的参数拿过来硬套。6.3 我还想多说一句的调优心法AAudio流控调优本质上是在延迟和稳定性之间找平衡。你压得越低风险越大你给得越多延迟越高。没有一个参数能同时满足所有设备、所有场景。我个人在实际项目里会把设备分成三档旗舰机用最小buffer跑低延迟中端机稍微放宽低端机再进一步放宽同时根据是否插耳机、是否录屏、是否在充电等状态动态调整。拿一个固定的参数值跑天下最后一定会在某些设备上翻车。再分享一个招上线前用自动压力脚本跑混合场景——播放音频的同时开动画、循环切后台、持续读文件、模拟消息通知弹出连续跑一小时把underrun次数作为性能基线。如果这个基线的触发频率能控制在极低水平再上真机体验基本都不会太差。这套方法比我见过的大部分所谓“优化方案”都实用因为音频卡顿最大的敌人不是某一项配置而是突发的系统不确定性。你能做的就是给不确定性留够缓冲。