在Android开发里，音频这块一直是个容易踩坑但又绕不开的领域。我写“Android音频学习”这个系列，初衷就是把自己在项目中趟过的浑水、翻过的源码、调过的BUG记录成册，方便自己回头看，也方便后来者少走弯路。到了第十四篇，终于要碰一个既基础又关键的话题——加载音频设备。这里的“设备”不单单指扬声器和耳机，而是整个音频输入输出的硬件链路抽象。很多应用卡在无声、延迟、切换异常等问题上，根子往往就在于对“加载”这一步的理解不够透彻。这篇我尽量讲清楚Android系统里音频设备是怎么被加载、管理和切换的，以及我们在应用层该用哪些API去正确操作它们。
这篇文章适合谁看？适合那些已经在用MediaPlayer或者SoundPool做过简单播放，但想进一步了解音频底层工作方式、想解决实际设备兼容性问题的Android开发者。我会把音频设备从系统架构到应用API的使用穿成一条线，辅以代码示例和实战排查经验。不敢说面面俱到，但至少涵盖了我在项目中遇到的绝大部分真实场景。
1. 音频框架与设备加载的整体认知
1.1 理解Android音频架构的分层设计
很多人一上来就写代码，直接用AudioTrack丢PCM数据，遇到无声就一头雾水，其实是因为没理解Android音频是分层设计的。从底到顶，大致是这样一条链路：音频硬件（Codec、DSP、喇叭/麦克风）——设备驱动（Linux kernel里的ALSA）——HAL（Hardware Abstraction Layer）——AudioFlinger（系统音频服务）——AudioPolicyManager（音频策略管理）——应用层API（AudioTrack/AudioRecord/AudioManager等）。
打个生活化的比方：硬件就像一家餐厅的厨房设备，驱动是水电管线，HAL是厨房里的操作台，AudioFlinger是总厨，AudioPolicyManager是排菜员，而我们应用层就是点菜的客人。你可以直接对着后厨喊（绕过系统用底层API），但大多数情况下还是得通过排菜员（AudioPolicyManager）来决定哪个菜送到哪张桌子。这个排菜的过程，本质上就是加载音频设备、管理音频路由的过程。
自己在项目里遇到过的一个典型问题：App里的提示音总是从听筒而不是扬声器出来。一开始以为是播放代码写错了，后来追查才发现是AudioPolicyManager根据当时的“通话状态”把音频输出路由到了听筒。这不是bug，而是策略生效的结果。理解分层之后，就不会再对着错误的方向排查耗时间了。
1.2 音频设备在系统中扮演的角色
在Android系统视角里，音频设备分为输入设备和输出设备。输出设备常见的有扬声器（Speaker）、有线耳机（Wired Headset）、蓝牙A2DP设备（Bluetooth A2DP）、USB音频设备等；输入设备则包括内置麦克风（Built-in Mic）、耳机麦克风（Headset Mic）、蓝牙SCO设备、USB麦克风等。每种设备都有自己的设备地址和属性，在AudioPolicyManager里通过一个AudioDeviceDescriptor来维护。
加载音频设备这个动作，放在系统层面看，就是“发现并初始化硬件端点，建立逻辑流与物理端点之间的映射关系”。放在应用层看，其实就是通过AudioManager/AudioTrack等接口，把音频数据正确送达到当前路由所指定的物理设备。系统通常会自动处理好绝大多数设备加载工作，但开发者要想做精细控制（比如指定外放、监听耳机插拔、切换蓝牙通道），就必须了解这些底层映射规则。
这里还要提一个概念：Audio Device的Address与Type。Type决定的是设备类别，比如AudioManager.ROUTE_EARPIECE、ROUTE_SPEAKER这些；Address则是更细粒度的标识，比如蓝牙设备的MAC地址、USB设备的Card Number等。在Android 6.0之后，系统推荐用AudioDeviceInfo来枚举所有可用设备，这比早期版本里的getDevices方法更规范，能够拿到设备的类型、地址、采样率、通道数等完整信息，是加载设备时最可靠的参考依据。
2. 核心API选型：不同场景该用谁
2.1 AudioTrack与MediaPlayer的选择逻辑
很多初学者分不清AudioTrack和MediaPlayer的区别，其实一句话就能概括：如果你手里已经是PCM裸数据，想直接往音频硬件送，用AudioTrack；如果手里是音频文件或者网络流，想省事解码播放，用MediaPlayer。从“加载音频设备”的角度看，AudioTrack更贴近设备端，因为你要自己负责把数据写进缓冲区，系统只负责传输与播放。
AudioTrack的关键初始化参数有三个：采样率、声道格式、音频格式。以播放一段44.1kHz、双声道、16bit的PCM数据为例，核心代码大概长这样：
int sampleRate = 44100; int channelConfig = AudioFormat.CHANNEL_OUT_STEREO; int audioFormat = AudioFormat.ENCODING_PCM_16BIT; int bufferSizeInBytes = AudioTrack.getMinBufferSize(sampleRate, channelConfig, audioFormat); AudioTrack audioTrack = new AudioTrack.Builder() .setAudioAttributes(new AudioAttributes.Builder() .setUsage(AudioAttributes.USAGE_MEDIA) .setContentType(AudioAttributes.CONTENT_TYPE_MUSIC) .build()) .setAudioFormat(new AudioFormat.Builder() .setSampleRate(sampleRate) .setChannelMask(channelConfig) .setEncoding(audioFormat) .build()) .setBufferSizeInBytes(bufferSizeInBytes) .setTransferMode(AudioTrack.MODE_STREAM) .build(); audioTrack.play(); audioTrack.write(pcmData, 0, pcmData.length);这里再说说选择AudioTrack的核心理由：如果你要实现低延迟播放、音频实时处理、变速变调、自定义混音等高级需求，MediaPlayer往往满足不了，必须用AudioTrack或者OpenSL ES。AudioTrack本质上是往系统AudioFlinger里“投喂”数据的通道，只要缓冲区和写入节奏控制好，延迟可以做到很低。
反过来，如果你只是放个音乐、响个提示音，用MediaPlayer就行，系统内部会帮你处理解码、缓冲、资源释放等一揽子事情，别自己折磨自己。
2.2 SoundPool与音频池的实战用法
SoundPool是处理短促、高频播放音效的利器，比如游戏里的点击音、射击音、消息提示音。它之所以适合这种场景，是因为它会一次性把音频文件解码并加载进内存，后续播放时几乎无延迟。相比之下，MediaPlayer每次播放都要重新走一遍准备和缓冲的流程，短音效频繁触发时就容易产生明显卡顿。
使用SoundPool加载音频设备的完整流程是：new SoundPool.Builder()设置最大流数，然后load加载资源文件，等setOnLoadCompleteListener回调后再播放。注意，load是异步的，必须在加载完成后再调play，否则会拿到非法的soundID。
SoundPool.Builder builder = new SoundPool.Builder(); builder.setMaxStreams(4); SoundPool soundPool = builder.build(); final int[] soundId = new int[1]; soundPool.setOnLoadCompleteListener(new SoundPool.OnLoadCompleteListener() { @Override public void onLoadComplete(SoundPool soundPool, int sampleId, int status) { if (status == 0) { soundPool.play(sampleId, 1.0f, 1.0f, 1, 0, 1.0f); } } }); soundId[0] = soundPool.load(this, R.raw.click_sound, 1);这里有一个实战小陷阱：SoundPool在Android 5.0之后推荐使用Builder构造，旧版的构造方法已经被废弃。另一个是小技巧——如果你在项目中频繁播放同一个短音效，可以考虑在Application初始化时就把SoundPool创建好并加载音频，避免每次进入页面都重新加载。实测下来，这种预加载策略能极大减少音效首次播放的延迟感。
2.3 AudioRecord采集端的设备加载
说完播放再来说采集。AudioRecord负责从麦克风采集音频数据，它需要访问的是输入设备。和AudioTrack对称，AudioRecord也需要配置采样率、声道格式、音频格式，然后调用startRecording开始采集，通过read方法循环读取数据。
采集端有一个常被忽视的细节：设备类型的选择。系统里输入设备也是分类型的，比如DEFAULT、MIC、VOICE_RECOGNITION、CAMCORDER等。如果你做的是语音识别，最好使用MediaRecorder.AudioSource.VOICE_RECOGNITION作为音频源，这样系统会针对识别场景做降噪处理，并且不会把提示音、铃声混进来。如果你做的是普通录音，用MIC就够了。
从“加载音频设备”的视角看，AudioRecord的核心在于把输入设备的数据流接进你的应用里。它内部的buffer轮转和底层AudioFlinger线程之间的配合非常紧密，所以缓冲区大小的设置会直接影响采集的稳定性。正常情况下，用AudioRecord.getMinBufferSize()返回的最小缓冲区大小就够了，但如果你发现采集时有明显的咔嚓声或溢出，可以把缓冲区设为最小值的两倍甚至四倍，牺牲一点延迟换取稳定性，这在低端机型上尤其管用。
3. 实战：在应用中正确加载和切换音频设备
3.1 操作前的权限与环境准备
音频设备加载虽然不像定位、相机那样权限敏感，但采集音频必须有录音权限，这个跑不掉。在Android 6.0以上（API 23+），需要在运行时动态申请RECORD_AUDIO权限，而且用户在Andorid 11及以上还能进一步细粒度授权（比如只允许使用麦克风而不允许访问通话录音）。如果拿不到录音权限，AudioRecord创建能成功，但startRecording时会抛出异常。
还需要重点检查的权限是MODIFY_AUDIO_SETTINGS。这个权限在Android源码里被标记为签名权限，普通应用无法获取。但它真正影响的是能否变更系统全局音频设置，一般应用基本用不上。开发阶段如果遇到setSpeakerphoneOn失效，反而更可能是API使用姿势不对，而不是缺权限。
到了Android 12（API 31），系统又引入了新的BLUETOOTH_CONNECT权限限制，蓝牙音频设备的连接和状态查询都需要这个权限。如果要监听蓝牙耳机的连接状态或控制蓝牙设备上的音频路由，必须记得在AndroidManifest里加上权限，并在运行时申请。实测下来，忘了这个权限最常见的表现是：能播放声音到手机外放，但无法切换到蓝牙耳机。
3.2 AudioTrack加载外部音频文件的完整流程
在真实项目里，AudioTrack最常见的任务就是播放从网络下载或本地读取的音频文件。不能直接把文件字节丢进AudioTrack，因为AudioTrack只吃PCM裸数据。所以完整流程是：读取文件——解码成PCM——喂给AudioTrack。在Android原生的MediaCodec和MediaExtractor配合下，这个过程并不复杂。
下面我给出一段较完整的代码框架，支持播放常见的WAV和MP3文件。WAV文件的PCM数据可以直接提取，MP3则需要经过MediaExtractor和MediaCodec解码。
private static final int SAMPLE_RATE = 44100; private static final int CHANNEL_MASK = AudioFormat.CHANNEL_OUT_STEREO; private static final int ENCODING = AudioFormat.ENCODING_PCM_16BIT; private AudioTrack audioTrack; private MediaExtractor extractor; private MediaCodec codec; private ByteBuffer[] inputBuffers; private ByteBuffer[] outputBuffers; private MediaCodec.BufferInfo bufferInfo = new MediaCodec.BufferInfo(); public void startPlayFile(String path) { extractor = new MediaExtractor(); extractor.setDataSource(path); int trackIndex = selectAudioTrack(extractor); extractor.selectTrack(trackIndex); MediaFormat format = extractor.getTrackFormat(trackIndex); try { codec = MediaCodec.createDecoderByType(format.getString(MediaFormat.KEY_MIME)); } catch (IOException e) { e.printStackTrace(); } codec.configure(format, null, null, 0); codec.start(); // 根据解码输出的格式初始化AudioTrack initAudioTrack(format); audioTrack.play(); // 进入解码-播放循环（此处只展示核心逻辑，省略线程管理） decodeAndPlay(); } private MediaCodec.BufferInfo decodeAndPlay() { boolean inputDone = false; boolean outputDone = false; while (!outputDone) { if (!inputDone) { int inputIndex = codec.dequeueInputBuffer(10000); if (inputIndex >= 0) { inputBuffers = codec.getInputBuffers(); int sampleSize = extractor.readSampleData(inputBuffers[inputIndex], 0); if (sampleSize < 0) { codec.queueInputBuffer(inputIndex, 0, 0, 0, MediaCodec.BUFFER_FLAG_END_OF_STREAM); inputDone = true; } else { codec.queueInputBuffer(inputIndex, 0, sampleSize, extractor.getSampleTime(), 0); extractor.advance(); } } } int outputIndex = codec.dequeueOutputBuffer(bufferInfo, 10000); if (outputIndex >= 0) { outputBuffers = codec.getOutputBuffers(); ByteBuffer outputData = outputBuffers[outputIndex]; byte[] pcmData = new byte[bufferInfo.size]; outputData.get(pcmData); audioTrack.write(pcmData, 0, pcmData.length); codec.releaseOutputBuffer(outputIndex, false); if ((bufferInfo.flags & MediaCodec.BUFFER_FLAG_END_OF_STREAM) != 0) { outputDone = true; } } } return bufferInfo; }这里要注意一点：解码后PCM的采样率、声道数、位深是由音频文件本身决定的，不一定是固定的44100Hz。我用codec.getOutputFormat()可以在解码完成后拿到真实的格式信息，然后据此初始化AudioTrack。如果硬用固定的参数去初始化AudioTrack，解码输出和播放参数不匹配，要么变调，要么噼里啪啦噪声。这是我在做播放器时候踩过的一个大坑。
3.3 监听音频设备插拔与自动切换
设备加载不是一锤子买卖，耳机拔了、蓝牙断了，系统都需要动态调整路由。应用如果播放音乐时不关心这些变化，可能就会出现：拔掉耳机声音瞬间从外放爆出来，蓝牙断开后播放立刻卡顿的情况。要做出体验良好的播放器，必须监听设备变化。
Android提供了AudioDeviceCallback来监听设备连接变化，但它有个局限：无法感知设备“断开”的精确时机，只能感知listener注册之后的状态变化。还有更常用的方案是监听ACTION_HEADSET_PLUG广播和BluetoothDevice的A2DP连接状态广播。
private BroadcastReceiver headsetReceiver = new BroadcastReceiver() { @Override public void onReceive(Context context, Intent intent) { if (intent.getAction().equals(Intent.ACTION_HEADSET_PLUG)) { int state = intent.getIntExtra("state", -1); if (state == 1) { // 耳机插入 onDevicePluggedIn(); } else if (state == 0) { // 耳机拔出 onDeviceUnplugged(); } } } };实际操作中，设备切换有一个通用策略：应用始终跟随系统当前默认路由。也就是说，如果你不强制指定路由，系统会自动在有线耳机插入时把声音切到耳机，拔出时切回外放。这不是需要应用处理的bug，而是正常的系统策略。但如果你的应用使用了AudioTrack且没有正确处理路由变化，可能会出现拔出耳机后播放线程还在往旧路由写数据的情况，这时候要主动做一下AudioTrack状态同步：拔插事件发生时暂停播放，等路由稳定后再恢复。
蓝牙设备场景更复杂一点。蓝牙耳机的连接和音频路由是两个步骤：连接成功 ≠ 音频已经路由到蓝牙。你需要先确认A2DP profile的连接状态，再检查AudioManager.isBluetoothA2dpOn()确认音频确实在走蓝牙通道。有些国产手机在这个状态同步上做得不够及时，连接成功后音频仍然外放，这时候轮询状态（比如1秒查一次，持续查5秒）会比单纯依赖回调更可靠。
4. 音频焦点与设备状态管理
4.1 音频焦点申请与释放
加载音频设备之后，应用能不能正常独占音频通道，是一个经常被忽略的问题。Android里有一套音频焦点机制：多个应用同时发声时，系统根据焦点优先级决定谁播放谁暂停。比如你在听音乐，突然来一条导航语音，音乐应该降音量，导航播完再恢复音量。
从“加载音频设备”的角度看，申请音频焦点其实是在往系统声明：我要占用这个音频输出了。如果不申请焦点，你播放时很容易被其他应用打断，或者你的播放会干扰其他应用。
焦点申请代码大致如下：
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(focusChangeListener) .build(); int result = audioManager.requestAudioFocus(focusRequest); if (result != AudioManager.AUDIOFOCUS_REQUEST_GRANTED) { // 焦点获取失败，说明有其他更高级别的音频流占用 }我做音乐播放器时在焦点处理上犯过一个错：只在开始播放时申请了焦点，没有监听焦点变化的回调。结果来电时铃声响起，我的应用没有任何反应，音乐还在大声播，用户体验极差。后来才补上onAudioFocusChange的完整逻辑：AUDIOFOCUS_LOSS时暂停播放，AUDIOFOCUS_LOSS_TRANSIENT时暂停播放但保留恢复位置，AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK时降低音量。
4.2 音频设备的音量与路由管理
加载设备之后的音量控制也是一门学问。系统按音频流类型（STREAM_MUSIC、STREAM_VOICE_CALL、STREAM_ALARM等）来管理音量。即便你的应用是用AudioTrack播放，只要AudioAttributes里的Usage设置成了USAGE_MEDIA，它就跟STREAM_MUSIC绑定在一起，受媒体音量控制。
实际操作中要注意：AudioTrack的setVolume是应用内音量，系统音量由AudioManager控制。不要在应用里依赖setVolume去做大声量的增益提升，因为超过1.0f的数值在有些设备上会被钳制。更合理的做法是先用AudioManager的setStreamVolume把系统媒体音量调整到目标值，再用setVolume做微调。
路由管理上有一个坑：用setSpeakerphoneOn(true)强制外放的方式在老版本API里有效，但在Android 5.0之后的设备上已经被弱化，尤其是通话场景。推荐改用setCommunicationDevice或者AudioRouting接口来精确控制路由。AudioRouting接口是在API 23中引入的，通过它可以查询和切换音频输出设备：
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) { AudioTrack audioTrack = ...; AudioDeviceInfo[] devices = audioTrack.getRoutedDevices(); // 遍历devices，找到你想切换的设备 boolean success = audioTrack.setPreferredDevice(targetDevice); }setPreferredDevice是应用层能做出的“请求”，系统并不保证一定会切到目标设备，但大多数情况下会尊重应用的偏好。这在需要固定输出到蓝牙外设或者USB声卡的场景下格外有用。
4.3 常见状态异常与恢复策略
音频设备状态异常往往表现为无声音、单声道、滋滋声、卡顿等，原因可能出在设备驱动、系统音频服务、应用代码任何一个环节。我总结了几条高频异常与恢复策略：
- 无声音但播放不报错：优先检查音频焦点是否被其他应用抢占、音量是否为0、设备的AudioTrack是否还在PLAYSTATE_PLAYING状态。焦点和音量是最容易被忽略的两项。
- 刚开始播放有短暂爆音：大概率是AudioTrack还没有完全进入PLAYSTATE_PLAYING就写入了大量数据。解决套路是先写入一段静音缓冲，等音频服务稳定后再写真实数据。
- 拔插耳机后音频无输出：这是典型的设备路由未刷新问题。可以在ACTION_HEADSET_PLUG回调里延迟100ms重新查询AudioManager.getDevices，并调用AudioTrack的flush和reconfigure，强制系统重新走一遍路由流程。
- 蓝牙设备播放卡顿：蓝牙A2DP传输存在带宽限制，高采样率高码率音频容易卡顿。可以先检查蓝牙设备的采样率能力，强制AudioTrack用低规格播放，比如44.1kHz/16bit/双声道，这是兼容性最好的配置。
正常项目里，建议实现一个兜底的“音频重置”逻辑：检测到AudioTrack异常时，依次执行stop、flush、release，然后重新创建AudioTrack实例。这比在现有实例上做各种reset操作要可靠得多，实测在绝大多数设备上都能恢复播放能力。
5. 常见问题排查与避坑指南
5.1 无声、卡顿、延迟问题的定位思路
遇到无声问题，第一反应不应该是怀疑代码，而是先通过系统自带的日志和状态工具定位问题范围。Android系统里，音频播放链路的问题大多会反映在logcat的AudioFlinger、AudioPolicyManager相关Tag下。你可以先用adb shell dumpsys media.audio_policy命令查看当前的音频策略与设备路由状态，看看系统认为当前输出设备是什么。
另一个实用工具是adb shell dumpsys audio。它能查看每个AudioTrack和AudioRecord实例的状态、采样率、声道、缓冲大小，对排查参数配置问题帮助极大。比如你能看到当前正在播放的AudioTrack的采样率已经变成了96000Hz，而你期望的是44100Hz，那就说明音频被某个环节重采样了，延迟变高也就不奇怪了。
延迟问题的排查思路：如果是从AudioTrack.write到声音发出的延迟过大，重点检查缓冲区大小和写入节奏。缓冲区越大延迟越高，但卡顿风险越低；缓冲区越小延迟越低，但低端机上容易卡顿。针对延迟敏感场景（比如音乐演奏类App），建议用AudioTrack.getUnderrunCount实时监测缓冲欠载次数，若欠载频繁，再适度加大缓冲区。
5.2 设备插拔闪退的坑
设备插拔导致闪退的原因，最常见的是AudioTrack还在播放中，但底层设备已经被移除，应用没有捕获到异常。在老版本SDK中，直接访问一个已经失效的AudioTrack实例很容易触发IllegalStateException。
我推荐的防护策略：所有AudioTrack相关的操作都放在一个HandlerThread里，并且在设备插拔回调里不再直接操作AudioTrack，而是向HandlerThread发送消息，由它统一处理pause、flush、release等动作。这样可以避免跨线程同时操作同一个AudioTrack实例的问题。
一个容易忽略的细节：AudioTrack实例释放后，不要再去调用任何方法，包括getPlayState()。有些开发者在release之后还想查一次状态，结果直接Crash。记得把audioTrack引用置null，并在所有访问点判空。
5.3 调试工具与日志分析技巧
最后分享几个效率翻倍的调试手段。
第一个是logcat过滤：调试音频相关问题时，重点过滤这几个Tag：AudioTrack、AudioFlinger、AudioPolicyManager、AudioService、MediaCodec。不要只看app的TAG，因为音频服务的错误信息往往不会出现在应用进程的日志里，需要同时打adb logcat的底层Tag。
第二个是结合dumpsys追踪路由：在播放过程中执行adb shell dumpsys audio | grep -A 5 "routed device"，能看到当前音频路由到了哪个设备。如果显示输出的设备和你预期不符，权限问题或者焦点问题基本跑不掉。
第三个是开启系统音频的debug模式：在开发者选项里，可以打开“显示surface更新”和“GPU呈现模式分析”，但音频没有专门的开发调试开关。所以本质上还是要靠logcat和dumpsys来拿到系统状态。熟能生巧，多排查几次不同机型的无声问题，你就能很快练就一套定位敏感度。
站在我个人的使用经验上来说，Android音频这块最忌讳的是“想当然”。凡是症状和预期不一致，先把系统的实际状态用dumpsys拉出来看看，再判断是应用层的问题还是系统层的问题，基本能避免无效调试。加载音频设备这个动作听起来抽象，但落到实际操作上，无非就是理清设备列表、选对API、处理好路由和焦点，最后再兜底一下代码的健壮性。把这几个环节打通了，音频相关的需求也就稳了。
最后再分享一个我在项目里一直在用的小经验：音频模块最好统一封装成一个单例管理器，不要在各个页面里散落创建AudioTrack和SoundPool。统一管理的好处是，遇到设备插拔、焦点变化、资源释放这些全局事件时，只需要在一个地方做处理，排查问题时思路也清晰得多。如果你正在被音频问题折磨，不妨先按这个思路重构一遍代码，很多莫名其妙的bug会自己消失。
