企业官网建设流程全解析

做Android音频开发，尤其是做播放器、音效类App，几乎都绕不开MediaPlayer和AudioTrack这两个类。很多初级开发只知道“MediaPlayer能播MP3，AudioTrack也能播，一个简单一个复杂”，但真到了选型时，并不知道两者底层差在哪，一旦项目做深了，各种诡异问题就跟着冒出来。MediaPlayer是系统提供的一套“开箱即用”播放器，AudioTrack则是更贴近底层的PCM输出通道。你可以粗略理解成：前者是去餐厅点菜，后者是自家厨房备菜。这篇文章我从API设计、播放流程、延迟表现、格式支持、实际踩坑这几个维度，把这两种音频播放方式彻底捋一遍。不管是刚入门做小Demo的新手，还是准备给播放器重构的老手，都能从这里找到值得参考的东西。

1. 两种方案的定位差异：为什么Android需要两套音频播放API

1.1 MediaPlayer：系统替你打点好一切的“全能播放机”

MediaPlayer在Android多媒体框架中属于高层API，它内部集成了音频解码器选择、音效处理、音量调整、音频焦点、音频路由等一大堆系统级逻辑。你用MediaPlayer播一个MP3或者AAC，只需要给个路径或URL，剩下的事基本不用操心：系统会从硬件解码器、软件解码器里选一个合适的方案，把编码音频解成PCM后写入底层输出设备。

MediaPlayer本身就是一个“状态机”，从Idle到Initialized、Prepared、Started、Paused、Stopped、PlaybackCompleted再到Error，每个状态之间都有严格的迁移条件。你要是不按顺序来，抛IllegalStateException是家常便饭。整个播放链路从setDataSource开始，到start播放，内部实际是走NuPlayer或Stagefright这套解码管线。这套管线不光支持音频，还能处理视频，所以MediaPlayer也能播带画面的视频文件。它的好处是兼容性极强，常见的MP3、AAC、FLAC、WAV、OGG都能播，很多项目即使不需要视频，也习惯用它图省事。

但它有个绕不开的问题：链路太长，内部是黑盒。比如你做音乐播放器想精确控制播放位置，或者对延迟有几十毫秒级的要求，MediaPlayer基本没法满足。从解码到输出中间经过太多层，你根本不知道系统在哪里缓存了多少数据。延迟一般都在一两百毫秒以上，极端场景甚至能到几百毫秒。这种场景下，MediaPlayer反而成了限制你发挥的那堵墙。

1.2 AudioTrack：绕开解码链路的裸PCM通道

AudioTrack的定位和MediaPlayer完全不一样。它不负责解码，不管你是MP3还是AAC，它统统不认，只认裸PCM数据流。它的职责就是把你喂给它的PCM字节，按设定的采样率、声道数、位深，持续写到音频设备上。从应用层来看，调用链比MediaPlayer短很多：你write数据，AudioTrack内部通过AudioFlinger和Audio HAL把数据送到硬件，中间几乎不做多余加工。

正因为这样，AudioTrack给了你极大的控制权：缓冲区大小自己定、采样率自己指定，可以用static模式一次性装载数据，也可以用stream模式无限续写。你可以精确控制“什么时候往里面写多少数据”，这在做乐器类App、实时语音、音效播放时非常关键。比如一个钢琴软件，你按下一个键，希望声音在几毫秒内出来，MediaPlayer那种经过完整解码链路的播放器做不到，AudioTrack或者更底层的AAudio才有戏。

所以用一句话概括：MediaPlayer是“帮你做决定”，AudioTrack是“把决定权交给你”。如果你自己解决了解码环节，比如通过MediaCodec、FFmpeg拿到了PCM，那AudioTrack就是那个把PCM送出去的出口。

1.3 题外话：音频输出设备与驱动层的坑

社区里经常能刷到“Realtek high definition audio一直没有输出设备”“NVIDIA high definition audio右键有个叉叉”这类问题，这些和本文讲的应用层API其实是两个层面的东西。MediaPlayer和AudioTrack在应用层把PCM交给系统音频服务后，后面还要经过音频路由、声卡驱动的层层传导，最后才从耳机或扬声器出来。设备驱动一旦不对，应用层做得再对也没声音。所以排查时先分清是App层、系统服务层还是驱动层的问题，免得白忙活。后文所有的代码和排错，默认都假设底层驱动和音频设备是正常的。

2. 核心API细节与参数拆解

2.1 MediaPlayer状态机：用好这套约束，少被异常折磨

先说MediaPlayer的常规播放代码。一个最简单的本地音频播放流程是这样：

MediaPlayer player = new MediaPlayer(); try { player.setDataSource("/sdcard/test.mp3"); player.prepare(); // 准备 player.start(); // 开始 } catch (IOException e) { e.printStackTrace(); }

这段代码能跑，但它有两个问题：

一是prepare()是阻塞的，如果文件比较大、或者传的是网络地址，会卡住调用线程，在UI线程调用直接ANR。二是很多人不知道MediaPlayer有状态约束，比如你在调用setDataSource之前调prepare，或者release之后再调start，必然抛IllegalStateException。

正式项目里我习惯用异步准备：

public class PlayerWrapper { private MediaPlayer mediaPlayer; public void play(String path) { if (mediaPlayer != null) { mediaPlayer.release(); mediaPlayer = null; } mediaPlayer = new MediaPlayer(); try { mediaPlayer.setDataSource(path); mediaPlayer.prepareAsync(); mediaPlayer.setOnPreparedListener(mp -> { mp.start(); }); mediaPlayer.setOnCompletionListener(mp -> { // 播完释放，避免占用资源 mp.release(); }); } catch (IOException e) { e.printStackTrace(); } } }

这里的重点不是代码多简单，而是你要理解MediaPlayer内部各个状态的含义：setDataSource之后进入Initialized，prepareAsync之后进入Preparing，准备完成回调进Prepared，start之后才是Started。你在Prepared之前调start，就是非法操作。多状态机设计确实麻烦，但反过来想，这种约束其实保证了播放链路在并发场景下不会出现不可预期的错误。这也是Java里比较老练的设计思路，理解它比死记API更有价值。

2.2 AudioTrack核心参数：bufferSize、采样率、声道、位深

AudioTrack的构造函数有新旧版本，新版本使用Builder模式，但核心参数没变。以流模式为例：

int sampleRate = 44100; int channelConfig = AudioFormat.CHANNEL_OUT_STEREO; int audioFormat = AudioFormat.ENCODING_PCM_16BIT; int bufferSize = AudioTrack.getMinBufferSize(sampleRate, channelConfig, audioFormat); AudioTrack audioTrack = new AudioTrack( AudioManager.STREAM_MUSIC, sampleRate, channelConfig, audioFormat, bufferSize, AudioTrack.MODE_STREAM ); audioTrack.play(); short[] data = new short[1024]; while (playing) { // 把PCM数据写入data数组 audioTrack.write(data, 0, data.length); }

这里面有个非常关键的参数是bufferSize。很多人以为随便填个1024或者4096就行，实际上系统给了你一个底线：getMinBufferSize()。它是根据采样率、声道、位深算出来的最小缓冲区，低于这个值，底层驱动来不及消费数据，播放就会出现爆音、断续、UV（underrun）问题。而如果缓冲区设置得太大，延迟又会明显上升。所以性能敏感的场景里，我往往在getMinBufferSize的基础上乘以1.5到2作为安全余量，既保证不断流，又不至于延迟高到不可接受。

还有一个容易忽略的点：AudioTrack的write()是同步阻塞的，不是丢进去就立刻播。如果你在UI线程里循环write几秒钟的数据，界面一样会卡顿。正常做法是单独开一个播放线程，或者用线程池固定一个工作线程专门写数据。每次write返回的实际写入字节数也不一定等于你传入的长度，你要循环判断，直到把数据写完，后面实战章节我会再展开讲。

2.3 一张表看懂两者的核心差异

这张表基本把选型的大方向说清楚了。但实际项目里两者经常是“上下游”关系：MediaPlayer在内部其实也会创建AudioTrack来输出最终PCM，你自己用MediaCodec或FFmpeg解码拿到PCM后，再用AudioTrack播放，本质是把系统替你包办的那些环节拆开自己做。理解这层关系，对排查很多深层的播放问题特别有帮助。

3. 实战走一遍：在线播放器与低延迟音效

3.1 用MediaPlayer做在线音乐播放的完整流程

做在线播放器，最典型的坑是网络流。setDataSource传入HTTP URL，然后prepareAsync，这时候如果网络很慢，用户点击播放之后会有好几秒“没反应”，新手经常不知道去哪看进度。

线上项目一般会在UI上做“加载中”状态，并监听OnPreparedListener和OnErrorListener：

mediaPlayer.setOnPreparedListener(mp -> { progressBar.setVisibility(View.GONE); mp.start(); }); mediaPlayer.setOnErrorListener((mp, what, extra) -> { progressBar.setVisibility(View.GONE); Toast.makeText(context, "播放失败，错误码：" + what + "/" + extra, Toast.LENGTH_SHORT).show(); return true; });

如果你要支持后台播放，还要把服务跑在ForegroundService里，同时申请音频焦点。焦点处理的逻辑是：AudioManager.requestAudioFocus，如果焦点被其他App抢走，比如来电、导航，你要么暂停，要么降低音量，等焦点恢复再继续。MediaPlayer本身并不强制你做焦点处理，但你要是不做，就会出现“音乐和导航声音一起出来”的糟糕体验，这在应用商店审核时也是扣分项。

还有一个容易被忽略的点：网络流播放到一半突然断网，MediaPlayer会回调OnErrorListener，错误码通常是MEDIA_ERROR_IO或MEDIA_ERROR_UNKNOWN。这时候不能直接手动重启播放，正确的做法是先release，清空状态，重新new一个MediaPlayer再setDataSource。因为状态机可能已经进入Error状态，直接start只会让你收获一堆异常。我之前就因为偷懒，想复用同一个MediaPlayer实例做网络重试，结果反复踩IllegalStateException，后来老老实实走“销毁重建”流程，问题才消失。

3.2 用AudioTrack生成并播放正弦波

AudioTrack最纯粹的用法，是播放你自己生成或解码出来的PCM数据。下面我用一个生成正弦波的例子来说明，它不像播放文件那样需要准备一堆资源，能很直观地展示AudioTrack的工作方式。先生成数据，再把数据写入AudioTrack：

int sampleRate = 44100; double frequency = 440.0; // A4音 int bufferSize = AudioTrack.getMinBufferSize( sampleRate, AudioFormat.CHANNEL_OUT_MONO, AudioFormat.ENCODING_PCM_16BIT ); AudioTrack track = new AudioTrack( AudioManager.STREAM_MUSIC, sampleRate, AudioFormat.CHANNEL_OUT_MONO, AudioFormat.ENCODING_PCM_16BIT, bufferSize, AudioTrack.MODE_STREAM ); track.play(); Thread t = new Thread(() -> { short[] buffer = new short[bufferSize / 2]; double phase = 0.0; double delta = 2 * Math.PI * frequency / sampleRate; while (isPlaying) { for (int i = 0; i < buffer.length; i++) { buffer[i] = (short) (Math.sin(phase) * Short.MAX_VALUE * 0.3); phase += delta; if (phase > 2 * Math.PI) phase -= 2 * Math.PI; } track.write(buffer, 0, buffer.length); } track.stop(); track.release(); }); t.start();

这段代码虽然简单，但里面藏着几个关键细节。音量我乘以0.3而不是1.0，是为了给系统留一点余量，免得设备输出端削波。缓冲区大小取bufferSize/2，对44100Hz、单声道、16bit来说，意味着每轮写入约23ms的数据。这个粒度是合理的，不会因为单次写入太大而出现明显延迟，也不会因为太小导致频繁唤醒线程。

实际项目中你不会只播正弦波，可能从FFmpeg解码拿到的是float型PCM或者多声道PCM，这时候只需要对应修改audioFormat和channelConfig。只要喂给AudioTrack的PCM数据格式和构造参数一致，播放就是顺的；一旦不一致，比如16bit数据写进了声称24bit的轨道，结果就是破音或者完全噪声。这类问题排起来很费劲，先核对数据格式往往是最快的路径。

3.3 降低延迟的几个硬指标

做乐器App、节奏游戏的人最关心的就是延迟。Java层AudioTrack的延迟表现，常规优化后能做到50ms上下，想再低就要上AAudio或者OpenSL ES这类更底层的接口了。如果你只能留在Java层，建议抓住这几个点：

• 采样率尽量用设备的native采样率，不要触发重采样。可以通过AudioManager.getProperty(PROPERTY_OUTPUT_SAMPLE_RATE)拿到当前设备的原生采样率。
• bufferSize不要设置得太大，在getMinBufferSize基础上加一点余量就行。每多10ms缓冲，延迟就多10ms，这个账自己算。
• 播放线程优先级调高，让write尽量不被系统调度耽误。
• 避免在write前后做耗时计算，需要生成波形时提前用独立线程算好。
• 能用MODE_STATIC的场合尽量用static模式，一次性写入的短音效比stream模式效率更高，延迟也更稳定。

这几点看着简单，实际操作时对体验的影响非常明显。同样的音效，你把采样率从44100改成设备不支持的22050，底层就得做SRC采样率转换，声音可能变调、延迟变大，用户一听就能感觉“不对味”。

4. 场景选型决策：两条路都摆着，别走错

4.1 选MediaPlayer更稳妥的典型场景

做音乐播放器、音频播放列表、网络广播这类场景，首选MediaPlayer。这些场景需要解码的格式多，需要长时间稳定播放，还涉及后台切换、焦点处理，MediaPlayer开箱即用。你不需要去关心音频究竟是怎么被解码出来的，系统会为MP3选对应的软件解码器，为FLAC选无损解码器，为不同设备配置选择最合适的解码方案。这对绝大多数App来说已经足够了。

举个例子，你想给App加一个“播放本地MP3”的功能，用MediaPlayer大概几十行代码就搞定了。用AudioTrack的话，你得先写一个MP3解码器，或者引入FFmpeg库，再把解码出的PCM往AudioTrack里喂，光接入解码库和维护ABI适配就够你喝一壶了。这种场景还选AudioTrack，就是典型的用大炮打蚊子，开发成本高，收益却不明显。

4.2 选AudioTrack更合适的典型场景

反过来，如果你的App对音频时序有强要求，或者你已经引入了自己的解码/处理链路，AudioTrack就能发挥价值了。典型场景包括：

• 游戏打击音效，要求按下攻击键瞬间出声音
• 乐器类App，比如电子琴、架子鼓，需要快速响应
• 实时变声、K歌混音，需要把麦克风采集的数据实时播放监听
• 音频可视化，要边播放边拿频谱数据，MediaPlayer给不了你原始PCM
• 已经用FFmpeg/MediaCodec解码出PCM，需要一个出口把数据播放出来

我做过一个电子琴项目，刚开始图省事用的MediaPlayer，每个琴键都new一个MediaPlayer实例去播一个很短的音效文件。结果按下琴键到出声延迟肉眼可见，快速连续弹奏时还会出现上一次播放还没释放、下一次就已经start的异常。后来改成AudioTrack加预先加载好的PCM采样数据，延迟和稳定性立刻好了很多。有些东西只有做完对比，才知道哪个方案是为哪种场景设计的。

4.3 焦点、路由与音量：两者都躲不开的公共议题

不管选哪个API，音频焦点和音频路由都是必须处理的。Android系统的音频是共享资源，多个App可能同时在播。你如果不申请焦点，来电时你的音乐还会继续放；你不处理耳机插拔，拔出耳机后声音可能直接从扬声器轰出来，体验非常糟糕。

处理方式上，AudioManager是公共的控制中心：

AudioManager audioManager = (AudioManager) getSystemService(Context.AUDIO_SERVICE); AudioAttributes attributes = new AudioAttributes.Builder() .setUsage(AudioAttributes.USAGE_MEDIA) .setContentType(AudioAttributes.CONTENT_TYPE_MUSIC) .build(); AudioFocusRequest focusRequest = new AudioFocusRequest.Builder(AudioManager.AUDIOFOCUS_GAIN) .setAudioAttributes(attributes) .setOnAudioFocusChangeListener(this::onFocusChange) .build(); audioManager.requestAudioFocus(focusRequest);

MediaPlayer和AudioTrack在“焦点”这个层面没有本质区别，焦点是系统全局的，你的播放器需要自己根据焦点变化暂停、继续、降低音量。这也是为什么很多大型音乐App会专门封装一套“播放控制引擎”，既管理MediaPlayer/AudioTrack，又管理焦点和路由事件。把这两层分开理解之后，你对整个Android音频系统的认知才算真正完整。

5. 常见问题与排查技巧实录

5.1 高频问题速查表

这张表是平时排查问题的核心索引，下面我把几个最容易踩的坑展开细说。

5.2 MediaPlayer的错误码与重试策略

MediaPlayer的错误回调不是随便看看就完事的。MEDIA_ERROR_IO、MEDIA_ERROR_MALFORMED、MEDIA_ERROR_UNSUPPORTED，每个类型背后的处理逻辑都不同。比如MEDIA_ERROR_UNSUPPORTED是解码器不支持当前格式，你再重试一百次也没用，正确做法是提示用户格式不支持。而MEDIA_ERROR_IO多半是网络问题，可以在重试前先检查网络状态，网络恢复后再重建播放器。

经验总结下来就是：错误码返回时，MediaPlayer内部已经进入Error状态，必须release后重新创建，别想着调reset()后马上重试。reset对很多机型来说本身就是一个不稳定的操作，不如直接销毁重建干净利落。我见过不少同学在这上面纠结，代码写得又长又绕，其实核心就一句话——重建对象。

5.3 AudioTrack的静音、噪声与时序问题排查

AudioTrack出问题，很多时候是数据没喂对，而不是播放接口本身的问题。比如你从某处拿到的PCM是32bit float，而你创建AudioTrack时用的是ENCODING_PCM_16BIT，那么结果要么爆音要么失声。遇到这种情况，先确认三件事：采样率对不对、声道数对不对、位深对不对。三个参数只要有一个和实际数据不一致，输出就是垃圾数据。

另外，很多人在循环write时没考虑“返回写入字节数比传入少”的情况。如果剩下一部分没写完就继续生成下一批数据，整体节奏会乱，听起来就是一顿一顿的。正确写法是写循环，当前批没写完就接着写，直到全部写进去再生成下一帧。

关于时序问题，我额外分享一个经验：如果播放线程和生成线程不在一个线程，一定要加一个足够深度的队列。生产者生成数据的速率很可能比消费者稍快或稍慢，没有队列缓冲，就只能靠睡眠乱凑，最终要么卡顿要么堆积内存。我实践中用一个容量为2到3个buffer的环形队列，播放线程从队列取数据，生产线程把数据放进去，实测流畅很多。这种做法在实时音频处理里几乎是标配。

5.4 别再忽略release：资源泄漏的隐形炸弹

最后要提一下release。很多初学者写完demo就丢一边了，Activity销毁了也不管播放器还在跑，结果内存、解码器、音频设备资源一直被占用。MediaPlayer要release，AudioTrack也要release。而且release之后最好把引用置空，防止回调里再次调用。

特别是AudioTrack，它持有的是系统音频服务那边的句柄，不release不只是你自己App内存泄漏，还会让系统音频服务越积越多，最终影响整机音频稳定性。在测试设备上我见过连续创建AudioTrack不释放，十几分钟后整个设备的音频都罢工了，重启才恢复。这种事一旦发生在线上用户身上，问题等级就是P0。

正确姿势是在onStop、onDestroy以及其他生命周期节点做统一释放判断。项目里可以写一个AudioPlayerManager来统一管理：

public void release() { if (mediaPlayer != null) { mediaPlayer.release(); mediaPlayer = null; } if (audioTrack != null) { audioTrack.stop(); audioTrack.release(); audioTrack = null; } audioManager.abandonAudioFocusRequest(focusRequest); }

我自己项目里有个很深的感触：MediaPlayer和AudioTrack不是两个对立面，而是同一个音频系统的两个层次。MediaPlayer帮你把解码、状态管理都包了，适合快速实现常规播放；AudioTrack把最终输出通道交给你，适合做定制化、低延迟的音频处理。早期做乐器App，我一开始迷信MediaPlayer省事，被延迟折磨了一轮，换AudioTrack轻松解决；后来做视频播放器，又发现不该强行用AudioTrack去解码推流，还是回到MediaPlayer来得快。

如果你现在正纠结到底用哪个，先把你的音频数据格式列出来，再想清楚是延迟优先还是开发效率优先，答案基本就出来了。音频这条路坑很多，希望上面这些踩坑记录能让你少走几步弯路。