做Android音频开发这几年被问得最多的问题之一就是播放个音频到底用MediaPlayer还是AudioTrack很多新手一开始用MediaPlayer觉得简单后来看到低延迟播放、实时语音这些项目全在用AudioTrack就开始纠结。其实这两个API根本不是同一层的东西——一个是开箱即用的整车一个是给你一堆零件让你自己拼发动机。这篇文章我会顺着两条播放路径把底层流程、buffer机制、状态机和选型依据都过一遍再聊聊我在实际项目里踩过的坑帮你一次性搞明白什么时候该用哪个。1. 同一条音频链路两种完全不同的控制粒度先给结论MediaPlayer是高集成度播放器AudioTrack是裸PCM出口。这句话看着简单但你只要真正理解了后面所有选型问题都能自己推出来。1.1 一句话理解两者的定位差异MediaPlayer把很多事情替你做了它自己维护数据源读取、音频解封装、解码、声道转换、上下采样、音量平衡甚至包括播放暂停停止这些行为管理。你只需要给它一个路径或者URI它就能把mp3、aac、m4a、wav等各种格式变成声音。对开发者来说这简直是一个黑盒播放器。AudioTrack则完全不是这么回事。它不认文件格式不理解mp3的编码不知道什么叫解码。你给它的必须是最原始的PCM数据——也就是已经解码好的、纯数字的音频采样点。它只干一件事把这些PCM字节按采样率、声道数、位深这些配置送到系统音频服务让声音从扬声器或者耳机里出来。如果用生活类比MediaPlayer就像外卖你点单后厨系统解码器帮你做好送到你家音频输出就完事。AudioTrack则是给你一堆食材和一口锅你得自己做饭但它也给了你完全控制火候的权力——盐放多少、什么时候关火全由你说了算。1.2 两者在系统架构里的真实位置Android音频框架从上层往下大概是这样应用层 —— MediaPlayer / AudioTrack —— AudioFlinger系统混音与路由服务—— HAL硬件抽象层—— 声卡/DAC/扬声器MediaPlayer并不直接和底层打交道。它内部有MediaExtractor负责拆解容器格式、MediaCodec负责解码解码出来的PCM数据最终丢给一个叫AudioSink的组件而AudioSink的默认实现恰恰就是通过AudioTrack来输出声音的。这意味着你用MediaPlayer播音乐底层绕了一圈最后把PCM送出去的还是AudioTrack这条通路。AudioTrack则是直接和应用开发者面对面你用write()把PCM字节流喂给它它通过Binder把数据交给AudioFlinger进行混音再路由到合适的输出设备。明白这个位置关系后很多问题就顺了为什么MediaPlayer延迟高因为它前面多了数据提取、解码、同步这些环节而且缓冲策略偏向吞吐而非低延迟。为什么AudioTrack控制精细因为它离最终出口更近中间没有那么多替你做主的封装。对比维度MediaPlayerAudioTrack职责边界提取解码播放控制时间同步仅负责PCM数据的传输与播放输入数据文件路径/URI/流地址解码后的PCM字节支持格式mp3、aac、m4a、flac等几乎所有仅PCM或浮点PCM延迟水平较高百毫秒级非常常见可达极低几何/几十毫秒级可期控制粒度粗播放暂停等状态级控制细可控制buffer、写入节奏、模式适合场景音乐播放、流媒体、点播实时语音、音效、低延迟播放器2. 从数据源到扬声器MediaPlayer的完整播放流程拆解很多人用MediaPlayer是知其然不知其所以然照着文档new一个、setDataSource、prepare、start就出声音了。但为什么prepare不能省略为什么setDataSource之后不能立刻start为什么播放网络流推荐用prepareAsync这些全都和它内部的状态机有关。2.1 setDataSource()到底发生了什么调用setDataSource()时MediaPlayer并没有把音频文件读进内存也没有启动解码。它只是记录了这个数据源的位置并且创建好对应的MediaExtractor实例——也就是说系统此时知道了我要读一个文件/一段网络流但还没开始干活。这一点很多人会误解以为setDataSource完成了文件就解析好了。实际上解析发生在prepare阶段。2.2 状态机能调用什么方法由现在处于哪个状态说了算MediaPlayer内部维护了一套严格的状态机。简单说它从创建出来到释放资源要经历这些关键状态Idle - Initialized - Preparing - Prepared - Started - Paused/Stopped | PlaybackCompleted / Error刚new出来的MediaPlayer处于Idle状态。调用setDataSource()后进入Initialized状态。调用prepare()或prepareAsync()后进入Preparing准备完成到Prepared。在Prepared状态下调用start()进入Started开始播放。播放中被pause()就是Paused被stop()就是Stopped播放到结尾就是PlaybackCompleted。任何时候出错就进入Error状态错误状态下很多调用会直接抛IllegalStateException。为什么这个状态机这么重要因为MediaPlayer不允许你在错误状态下调用错误的操作。比如你没prepare就调start()会崩溃你release之后再去setDataSource一样是IllegalStateException。这就是为什么很多新手崩溃日志里全是这个异常——本质上是还没把状态流转搞明白。一个非常容易踩的实际坑在Paused状态下立即调用start()一般没问题但如果你在Stopped状态下直接start()有些机型会报错因为从Stopped回到可以播放的状态需要重新prepare。所以老练的开发者播放音频前都会做一个状态判断而不是无脑start()。2.3 同步prepare还是异步prepareAsyncprepare()是同步的也就是说它要等文件解析完成才返回。本地小文件问题不大但如果数据源是网络流或者是个几百MB的音频文件prepare()会卡住调用线程轻则ANR弹窗重则直接被系统杀掉。所以网络音频和较大文件一律推荐prepareAsync()然后通过OnPreparedListener回调来确认准备完成mediaPlayer.setDataSource(url) mediaPlayer.prepareAsync() mediaPlayer.setOnPreparedListener { mp - mp.start() }这里有个细节在onPrepared回调里start()只是常规做法。如果你要做封面加载、播放进度初始化、显示播放控件之类的操作都应该在Prepared之后做因为只有到了这个状态时长、专辑信息、缓冲状态这些才是有意义的。2.4 解码之后PCM最终流向AudioSinkMediaPlayer准备完成后播放才真正开始。此时MediaExtractor按容器格式读取音频帧丢给MediaCodec解码器解出PCM数据。这段PCM经过必要的采样率转换、声道映射、音量调节后被送到AudioSink组件。AudioSink和AudioTrack的关系可以理解成AudioSink是一个内部接口它管理着音频输出策略但实际干活时绝大多数情况就是创建一个AudioTrack实例把解码后的PCM数据通过write()写进去。这也是网上讲MediaPlayer最终也要走AudioTrack的直接原因。所以为什么MediaPlayer的延迟高数据链路太长MediaExtractor读帧 - MediaCodec解码 - AudioSink - AudioTrack - AudioFlinger - HAL - 硬件每一环都有缓冲而且为了播放流畅系统倾向于多积累一些数据再放出去延迟自然就上去了。你暂停再播放啪的一下可能有几百毫秒的停顿这就是缓冲在作祟。3. AudioTrack的数据通路buffer计算、模式选择与线程模型AudioTrack看着API简单new一下、play()、write()循环就完事但它真正复杂的地方全在细节里buffer开多大合适、MODE_STREAM和MODE_STATIC到底怎么选、write()怎么调用才能不卡顿。3.1 数据直接交给AudioFlingerAudioTrack通过write()方法把PCM字节送进系统服务AudioFlinger。AudioFlinger在Android里就是混音器它接收所有应用的音频流按音量、声道、焦点策略混合后交给HALHAL再驱动声卡DAC出声。这个过程中AudioTrack的创建参数极其重要。采样率、声道掩码、位深任何一个和PCM数据本身不匹配轻则变调采样率错、重则直接无声或者噪音声道布局错。3.2 getMinBufferSize()到底在算什么AudioTrack要求你告诉它buffer至少多大这里先别乱拍脑袋系统给了个标准方法val minBuf AudioTrack.getMinBufferSize( 44100, AudioFormat.CHANNEL_OUT_STEREO, AudioFormat.ENCODING_PCM_16BIT )这个值读出来代表的是在指定采样率、声道、位深下为避免播放卡顿系统建议的最小缓冲字节数。它不是随便给的而是按最低延迟要求下的最小安全buffer来算的底层会考虑到AudioFlinger处理周期、HAL硬件设备帧大小等因素。简单估算一下44100Hz采样率、双声道、16bit2字节时一秒钟的PCM数据量是 44100 × 2 × 2 ≈ 176400字节也就是约172KB。如果minBuf算出来大约17640字节那就相当于约100ms的数据量——低于这个值CPU或者写入节奏稍微抖动一下就会发生underrun数据喂不及听到的就是断断续续的杂音。3.3 MODE_STREAM和MODE_STATIC之间的区别AudioTrack有两种传输模式这个也是新手最容易忽略的。MODE_STREAM数据流式写入。你建立AudioTrack之后可以持续地把PCM数据write进去。它适合长时间播放、实时产生的音频数据比如通话、录音回放、长音频播放。代价是多了一层buffer复制和更复杂的数据调度。MODE_STATIC一次性把数据全部载入。你创建一个固定大小的AudioTrack把PCM一次性写入然后直接用静态buffer播放。它适合短促、一次性音效比如点击音、提示音、枪声。因为数据已经躺在那个buffer里了播放时几乎不需要动态调配延迟更低开销也更小。切换模式的代码差异很小思路差异很大如果你的音频数据是持续产生的却用了STATIC那你只能先攒完所有数据再放这在实时场景是不可能做到的反过来一段很短的提示音你还用STREAM流式写每次都要经历对象创建、数据搬运、释放纯属浪费。3.4 write()阻塞与线程节奏AudioTrack的write()在默认情况下是阻塞的如果内部buffer满了它会等。audioTrack.play() while (playing) { val written audioTrack.write(pcmData, offset, length) offset written if (written 0) { // 底层buffer满了或者写入失败建议短暂让出CPU Thread.sleep(5) } }如果你用一个固定的数据源文件循环喂AudioTrack一定要注意写入节奏。比较稳妥的做法是每次写入20~50ms时长的PCM这样即使某个瞬间系统调度慢了一拍也不至于瞬间打满底层buffer导致播放断续。我见过有人粗暴地一次性写入几百毫秒的数据结果播放卡顿反而更明显因为底层buffer被撑爆之后write()长时间阻塞时序全乱了。此外AudioTrack这种流式对象尽量复用不要每次播放都new一个再释放。一次实际项目里一个通知音效每秒触发一次我一开始没复用AudioTrack结果不仅卡顿还出现多个AudioTrack实例同时在响的情况。后来改成初始化一个MODE_STATIC的AudioTrack每次播放前play()一下完事后再pause()并把播放位置重置到开头彻底干净了。4. 按场景反推什么时候该放弃MediaPlayer理解了原理之后选型其实是个很简单的反推题看你的音频来源是什么形态、对实时性有多高的要求。4.1 一张场景决策表直接抄作业具体场景推荐方案原因播放本地mp3、aac、m4a文件MediaPlayer 或 ExoPlayer需要解封装和解码MediaPlayer全都封装好了网络流媒体点播MediaPlayer/ExoPlayer自带缓冲策略和网络源处理AudioTrack完全不适合实时语音通话、对讲AudioTrack音频是一帧一帧实时产生延迟必须短游戏打击音效、UI音AudioTrack/MODE_STATIC 或 SoundPool低延迟、一次性短音效低延迟本地音乐播放器AudioTrack播放引擎自己管理解码最后用AudioTrack低延迟输出录音同时回放耳返AudioTrack需要和录音线程精确同步MediaPlayer插不进来4.2 为什么语音通话绝对不能碰MediaPlayer语音通话场景里你拿到的通常是一段段实时编码或解码出来的PCM数据比如Opus解码后的裸流。MediaPlayer根本没有直接喂PCM的接口——它的数据源是文件路径、URI或者流地址它自己能拉数据但你没法按帧精确控制现在播放这一包声音。更关键的是实时性。通话场景的延迟需求是几十毫秒级超过200ms人就能感觉到对不上嘴型了MediaPlayer那种先缓冲再播放的机制完全扛不住。你想象一下电话那头说了一句话你这边慢半拍才听到还能愉快聊天吗所以通话类应用App拿到解码后的PCM直接交AudioTrack按帧播放是最低延迟的路径。4.3 游戏音效用AudioTrack还是SoundPoolAudioTrack用于游戏音效时要小心资源开销。MODE_STATIC虽然延迟低但每个音效就要占一份buffer内存同时开几十个AudioTrack实例在AudioFlinger层面也不便宜。所以纯短音效爆发场景SoundPool更合理它内部会管理一组SoundPool声音ID并发播放同一个音效时开销也更小。但如果你的引擎对延迟极其敏感自己管理资源没问题用AudioTrack也不是不行。我见过自研引擎用一组预分配的AudioTrack池每个音效实例绑定一个MODE_STATIC的AudioTrack播放速度快到几乎是按下就响这效果SOundPool在某些老设备上反而做不到。4.4 流媒体场景别自己造轮子有人问既然AudioTrack延迟低我是不是可以用它播网络音频自己搞定缓冲和Jitter理论可行现实很骨感。网络流本身会有抖动、拥塞、重传一个成熟的播放器需要的缓存策略、码率切换、错误重试AudioTrack一个都不提供全要你手写。而MediaPlayer/ExoPlayer这一层已经成熟多了缓冲、超时、重试都处理得不错。所以只要不是实时通话电平老老实实用MediaPlayer或ExoPlayer。5. 同一段PCM两种实现的实测体验与填坑记录理论说完了讲讲实际体验。我做过一个简单的实验同一段PCM数据分别存成文件用MediaPlayer播和直接用AudioTrack播测两者的启动延迟和可感知的操控延迟。5.1 延迟实测最简单的方法MediaPlayer没有直接暴露当前播放位置对应音频时间戳的低延迟查询方式所以粗略测量可以这样点击按钮触发播放时记录System.currentTimeMillis()然后通过AudioManager查询当前是否有音频正在播放或者更简单粗暴——用分贝仪或直接在扬声器旁边用录音设备记录声音发出的时刻。这个实验精度不高但能看出数量级差异。AudioTrack则更直接新版本API里有getTimestamp()可以拿到当前播放到哪个音频帧配合采样率可以算出当前播放位置对应的时间误差极小。如果你在做节奏类应用一定要用这个方法来做节拍校准而不是在主线程用System.currentTimeMillis()硬算——系统调度抖动会把你坑哭。5.2 第一个坑采样率、声道、位深必须和PCM严格一致从MediaPlayer切到AudioTrack很多人第一件事就是踩这个坑PCM是44100Hz单声道16bit你在AudioTrack里配置成48000Hz双声道结果要么不出声要么全是吱吱啦啦的噪声要么声音明显变快变尖。AudioTrack不会帮你做采样率转换和声道重映射。它收到数据后按你给的参数解释这些字节参数错了声音就废了。而且很多国产设备在参数非法时不会报错只是静音排查起来特别痛苦。所以我在代码里会强制加一个日志val sampleRateInHz 44100 val channelConfig AudioFormat.CHANNEL_OUT_MONO val encoding AudioFormat.ENCODING_PCM_16BIT Log.d(AudioTrackInit, sampleRate$sampleRateInHz channel$channelConfig encoding$encoding)别嫌啰嗦线上问题排查时这段日志能救你的命。5.3 第二个坑setVolume不生效可能是stream type的问题AudioTrack构造时可以指定音频流类型常规用USAGE_MEDIA对应媒体音量或USAGE_VOICE_COMMUNICATION对应通话音量。如果你建AudioTrack时用的USAGE_VOICE_COMMUNICATION然后想让系统媒体音量键控制它那多半不行——因为系统音量调整走的是按流类型的路由你走的不是媒体流音量键当然调不到它。另外AudioTrack.setVolume(0f)做静音在有些设备上因为底层混音策略的问题短时间听不到效果甚至要等当前buffer里的数据播完。我做静音时习惯在写入端同时处理真正需要静音时直接把写入的数据改为静音PCM全0而不是单纯依赖setVolume()这样最保险。5.4 第三个坑卡顿underrun排查清单AudioTrack播放出现哒哒哒或者滋啦滋啦的断续声优先查这几项buffer太小。getMinBufferSize()拿到的只是下限实际用建议1.5到2倍。写入节奏不均匀。主线程里写数据大概率卡出天际必须单独开线程。AudioTrack对象频繁创建。每次new都要重新连接AudioFlinger建立通道开销大容易在创建间隙漏数据。没有设置performance mode。用Builder模式的时候可以.setPerformanceMode(AudioTrack.PERFORMANCE_MODE_LOW_LATENCY)低延迟模式下系统会尽可能缩短buffer路径。不过要有个心理准备LOW_LATENCY模式在某些老旧设备上可能会因为设备不支持而导致播放失败所以一个稳健的播放管线会把创建失败回退到普通模式的逻辑写进去。6. 架构层面再想一层MediaPlayer和AudioTrack其实不用二选一到了项目后期你会发现真正复杂的音频播放器很少在MediaPlayer和AudioTrack之间非此即彼地选一个。它们更像是外层引擎和最终出口的配合关系。6.1 播放器引擎里的分层思路一个自研播放引擎通常是这样的分工解封装层MediaExtractor或者FFmpeg负责把容器拆成音频帧。解码层MediaCodec或者FFmpeg软解输出PCM。渲染层AudioTrack或自定义的AudioSink负责把PCM按精确的时钟节奏送到底层。控制层管理播放暂停、seek、缓冲水位、音量和多音轨切换。这条链路里你可以用MediaPlayer来做前面所有事但如果你想精细控制缓存预载、无缝循环、声道映射就必须把解码和渲染攥在自己手里——这时候AudioTrack就是那个渲染出口。很多音乐播放器的无缝播放低延迟耳机返听功能都是通过替换渲染层做出来的。6.2 ExoPlayer底层也离不开AudioTrack顺着往下说ExoPlayer这个现在更主流的播放引擎底层同样有AudioSink的概念。它内部可以配置不同的rendererDefaultAudioSink在大部分音频输出路径上最终就是创建一个AudioTrack。所以你看无论高层API怎么封装Android上PCM最终触达硬件的那一段路名字就叫AudioTrack。这也是为什么我建议做音频开发的人哪怕平时用MediaPlayer顺手了也一定要把AudioTrack机制吃透。因为将来你做低延迟、做耳返、做音频可视化、做变速不变调都绕不开它。理解了AudioTrack等于把Android音频最核心的那段通路摸清了。6.3 硬件抽象层那点事再往下一层AudioFlinger混音之后的数据交给HALHAL驱动具体声卡。不同设备对采样率的支持不一样有的设备原生支持192kHz有的只支持48kHz。AudioTrack在创建时系统会进行必要的重采样或直通处理。低延迟场景下你最好先查询一下设备推荐的采样率val am getSystemService(Context.AUDIO_SERVICE) as AudioManager val recommendedRate am.getProperty(AudioManager.PROPERTY_OUTPUT_SAMPLE_RATE).toInt()我在做乐器类App时建AudioTrack前都会先拿这个推荐采样率而不是死写44100。因为按设备原生采样率播放绕过了不必要的重采样延迟能再低一点码率也更稳。6.4 一个实际项目里我踩过的双开坑最后分享一个具体教训。我做过一款带录音伴奏的K歌Demo伴奏用MediaPlayer播MP3人声用AudioRecord实时采集再立即送入AudioTrack做耳返。听起来很自然一个负责文件播放一个负责人声实时回放。结果一跑就出现回声和伴奏延迟不同的怪异感受。排查下来原因很简单MediaPlayer的伴奏缓冲很大、延迟很高而AudioTrack耳返延迟极低人声和伴奏就很难严丝合缝。最后改法是把伴奏也改成AudioTrack播放——先用MediaExtractorMediaCodec把伴奏解码成PCM存到内存再用AudioTrack按同一条低延迟链路播。两边时钟同步了体验瞬间正常。这个案例特别适合说明不是MediaPlayer不好在某些需要和其他AudioTrack流严格对齐的场景里它就是插不进来。这些经验希望你在做同类需求的时候用得上——先想清楚音频链路的最关键环节再选API比我当初踩完坑再回头改要省力得多。