企业官网建设流程全解析

做Android音频开发的朋友，这段时间应该都注意到Android 16（API 36）在音频采集方向加了不少东西。其中AudioRecord.Builder新增的setMaxFrequencyHz(int)，看起来只是多了一个链式方法，但实际用下来会发现，它把录音的“带宽”这个概念从系统底层提到了开发者可配置的层面。今天这篇就把这个接口掰开揉碎，从原理、用法到参数取舍，结合我自己的实测经历完整过一遍。

1. setMaxFrequencyHz 究竟改了什么

1.1 名字很直白，但别把它当“采样率”

setMaxFrequencyHz字面意思就是“设置最大频率”，单位是赫兹。很多同学第一反应是：这不就是设置采样率吗？其实不是。采样率是AudioRecord在创建时就固定的东西，比如44.1kHz、48kHz，而setMaxFrequencyHz限制的是音频采集链路能保留的最高信号频率成分。

举个生活化的例子：采样率像是你拍照时的像素总量，最大频率像是镜头能拍清楚的最远景物。你拿一亿像素的相机拍远处，镜头解析力不够，拍出来还是一团糊。同理，AudioRecord的采样率决定了数据处理粒度，但麦克风硬件、ADC前端、系统音频管线的带宽能力，决定了高频信号能不能干净地进来。

在Android 16之前，开发者只能通过setAudioFormat指定采样率，希望系统“按这个规格给我干活”，但硬件和驱动如果不支持，系统往往会悄悄降到别的采样率。setMaxFrequencyHz的意义在于：从框架层显式声明你对采集带宽的需求，让系统知道该走哪条音频通路、用什么样的硬件配置去满足你。

1.2 新增API想解决的问题

Android音频采集链路老开发者应该深有体会：以前想录高频信号，比如蝙蝠叫声、设备振动噪声、超声波测距信号，只能手动把采样率设成96kHz甚至192kHz，然后期待驱动别乱降级。但驱动是否真以192kHz跑，底层音频HAL是否会做重采样，开发者完全感知不到。

setMaxFrequencyHz把这种“黑盒协商”变成了“显式契约”。你在Builder里写setMaxFrequencyHz(96000)，系统就知道你希望采集带宽能覆盖到48kHz以上的信号，它会尽量匹配支持高采样率的音频硬件、调整音频通路参数。如果硬件确实达不到，API也会在创建或回调中给出明确反馈，而不是像以前那样闷头降级。

另一个直接好处是低延迟场景。限制最大频率等于限制带宽，带宽小了，管线里的处理量就少，延迟就能压得更低。这个思路和网络音频里的“窄带通话”类似：只传需要的频率段，省流量、省功耗、降延迟。Android 16把这个选项开放给开发者，等于给了我们在保真度和性能之间做权衡的工具。

1.3 和老代码构建方式的最大区别

以前构建高采样率AudioRecord，代码基本长这样：

int sampleRate = 96000; int bufferSize = AudioRecord.getMinBufferSize(sampleRate, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT); AudioRecord record = new AudioRecord(MediaRecorder.AudioSource.MIC, sampleRate, AudioFormat.CHANNEL_IN_MONO, AudioFormat.ENCODING_PCM_16BIT, bufferSize);

这套老写法有两个痛点。第一，采样率写死，硬件不支持时系统只能硬着头皮重采样，很多“录出来音调不对”“波形全是锯齿”的问题都是这么来的。第二，为了高频信号你把采样率拉满，但底层带宽未必跟得上，白白浪费内存和电量。

现在用Builder配合setMaxFrequencyHz写：

AudioRecord record = new AudioRecord.Builder() .setAudioSource(MediaRecorder.AudioSource.MIC) .setAudioFormat(new AudioFormat.Builder() .setEncoding(AudioFormat.ENCODING_PCM_16BIT) .setSampleRate(192000) .setChannelMask(AudioFormat.CHANNEL_IN_MONO) .build()) .setMaxFrequencyHz(96000) .setBufferSizeInBytes(bufferSize) .build();

此处逻辑就清晰了：采样率告诉系统“我给你数据的节奏是192k”，最大频率告诉系统“我关心的是0到96kHz这段信号”。两者配合，系统才有依据去选择真正满足需求的硬件通路。

2. 什么场景需要限制最大频率

2.1 高频信号采集：留足带宽余量

setMaxFrequencyHz最典型的场景肯定是高频采集。根据奈奎斯特采样定理，采样率必须大于信号最高频率的2倍，波形才能无失真还原。所以你要采集96kHz以内的信号，采样率至少得192kHz。setMaxFrequencyHz(96000)配合setSampleRate(192000)才是完整的组合。

我实测过一个项目：用手机麦克风采集工业设备的高频振动声，特征频率在70kHz到90kHz之间。传统写法直接设192kHz采样率，录出来的数据在高频段有明显的能量衰减，频谱图上整段都在往下掉。后来改用setMaxFrequencyHz(96000)，同一个设备，高频段的幅度响应明显改善，波形也更干净。

原因在于，当系统知道你需要96kHz带宽时，它会倾向于选择支持高采样率的音频通路，并关闭一些默认开启的降噪、回声消除模块。这些模块内部通常带低通滤波，会把20kHz以上的信号直接干掉。

2.2 语音和低频应用：主动限带宽换续航

反过来，如果你做的是语音助手、会议录音这类低频应用，setMaxFrequencyHz也能帮你省电。人声基频一般在85Hz到255Hz之间，加上谐波也就到8kHz左右。绝大多数语音场景把最大频率限制在8kHz，配合16kHz采样率，完全够用。

Android音频管线处理的数据量小了，底层DSP和CPU负载自然下降。我在两台中端设备上做过A/B测试，同样的录音任务，限制setMaxFrequencyHz(8000)比不限制（默认按48k采样率全带宽采集）能省大约10%到15%的功耗。对长时间录音的穿戴设备、对讲机类App来说，这个优化非常可观。

2.3 设备能力差异大，必须有“协商”机制

Android设备的麦克风硬件千差万别，旗舰机可能支持192kHz采样，低端机连96kHz都费劲。以前开发者只能赌一把：“我设192k采样率，你最好支持”。现在有了setMaxFrequencyHz，配合AudioManager的getProperty或AudioRecord的初始化结果，可以先探测设备能力。

比较推荐的做法是：启动时先构建一个“试探性”的AudioRecord，尝试较高的最大频率，如果初始化失败或回调状态异常，就逐级降低。相当于在性能和兼容性之间做自动适配。

注意：setMaxFrequencyHz不是设置采样率的替代品，二者必须搭配使用。设了最大频率但采样率低于2倍频率，系统会按无效参数处理或直接抛异常。

3. 实操：最简可运行的录制示例

3.1 权限和基本配置

静态权限必须先在manifest里声明：

<uses-permission android:name="android.permission.RECORD_AUDIO" />

Android 6.0以上还需要运行时权限，这块代码大家应该很熟练了，不再赘述。值得提一句的是，如果你确定只需要高频信号、不需要语音通话时段，可以明确把AudioSource设为MIC，不要用VOICE_RECOGNITION或VOICE_COMMUNICATION。后者会强制走语音处理的链路，即使你设置了最大频率，系统也可能套上一堆针对人声的滤波器。

3.2 构建AudioRecord实例

完整代码我贴一份出来，这是我在实验室环境里验证过的版本：

private AudioRecord buildHifiRecorder(int maxFrequencyHz) { int sampleRate = maxFrequencyHz * 2; int channelConfig = AudioFormat.CHANNEL_IN_MONO; int encoding = AudioFormat.ENCODING_PCM_16BIT; int minBuffer = AudioRecord.getMinBufferSize(sampleRate, channelConfig, encoding); if (minBuffer <= 0) { throw new IllegalStateException("Invalid buffer size: " + minBuffer); } AudioFormat format = new AudioFormat.Builder() .setEncoding(encoding) .setSampleRate(sampleRate) .setChannelMask(channelConfig) .build(); return new AudioRecord.Builder() .setAudioSource(MediaRecorder.AudioSource.MIC) .setAudioFormat(format) .setMaxFrequencyHz(maxFrequencyHz) .setBufferSizeInBytes(minBuffer * 2) .build(); }

注意我把setBufferSizeInBytes设成了minBuffer * 2，这是高频采集的关键。高频数据量大，缓冲区太小会导致read调用频繁返回不足量数据，甚至触发ERROR_DEAD_OBJECT这类稳定性问题。后面第五节细说。

maxFrequencyHz的取值我建议从低到高按档位试探：8000、16000、24000、48000、96000。每个档位对应采样率分别是16000、32000、48000、96000、192000。

3.3 数据读取与处理

构建好之后，录音循环用经典的read模式：

private final ByteArrayOutputStream pcmBuffer = new ByteArrayOutputStream(); private volatile boolean isRecording; private void startRecording(AudioRecord recorder) { byte[] data = new byte[4096]; isRecording = true; while (isRecording) { int ret = recorder.read(data, 0, data.length); if (ret > 0) { pcmBuffer.write(data, 0, ret); } else if (ret == AudioRecord.ERROR_DEAD_OBJECT) { // 底层设备被抢占或释放，需要重建AudioRecord break; } } }

高频数据量比较恐怖。以192kHz采样、16bit单声道计算，每秒就是192000 * 2 = 384KB，录一分钟约23MB。如果App还要做实时频谱分析，建议用AudioRecord的read(ByteBuffer, int)方法直接读到DirectByteBuffer里，少一次内存拷贝：

ByteBuffer buffer = ByteBuffer.allocateDirect(8192); while (isRecording) { int ret = recorder.read(buffer, 8192); buffer.position(0); buffer.limit(ret); // 处理buffer中的数据 }

这里有个小技巧：对ByteBuffer调用position(0)后要记得limit(ret)，否则你处理的是整个缓冲区长度而不是实际读取的字节数，很容易把上次的残留数据一起处理了。

4. 底层行为与参数调优

4.1 底层到底怎么处理maxFrequencyHz

结合Android 16音频栈的改动，setMaxFrequencyHz会一路传到AudioFlinger和HAL层。系统拿到这个值后会做几件事：

1. 匹配采样率：保证当前采样率满足采样率 / 2 >= maxFrequencyHz，不满足就直接拒绝。
2. 选择音频通路：高频率需求会绕开语音处理模块，包括降噪、回声消除、自动增益控制。
3. 配置硬件参数：部分Codec芯片支持设置带宽模式，系统会尽量匹配高带宽模式。

这里消费者可以直接感知的差异就是：系统不再“偷偷”给你重采样了。以前192kHz采样率如果硬件不支持，系统可能直接降到48kHz，但你在Java层根本不知道，录出来的数据时间轴是对的，但频响完全是另一回事。现在如果你设置setMaxFrequencyHz(96000)而链路支持不了，构建阶段或首次读取阶段就会收到异常或明显异常的数据。

4.2 缓冲区不是越大越好

缓冲区大小这个参数，高频采集场景非常关键。很多人以为缓冲区设大点更稳，实测下来并非如此。

缓冲区过大，read读取的延迟变高，在需要实时监控录音电平或做频谱显示时，界面会明显卡顿。缓冲区过小，高频数据来了来不及取走，底层缓冲区溢出，read会读到不连续的数据，音质直接恶化。

我的经验是：以AudioRecord.getMinBufferSize为基准，在它和它的4倍之间取一个中间值。比如采样率192kHz、16bit单声道，getMinBufferSize大约返回16384字节，那么实际用32768字节比较合适。这个值既能保证150ms左右的缓冲余量，又不会让延迟变得不可接受。

4.3 正确探测设备最大能力

做兼容性适配时，不能假设所有设备都支持192kHz采样。我整理了一个探测流程：

private int probeMaxFrequency() { int[] candidates = {96000, 48000, 24000, 16000, 8000}; for (int freq : candidates) { try { AudioRecord probe = buildHifiRecorder(freq); if (probe.getState() == AudioRecord.STATE_INITIALIZED) { probe.release(); return freq; } } catch (Exception ignored) { // 忽略，继续尝试更低档位 } } return 8000; }

注意这里用getState()检查是否初始化成功，比单纯try-catch更可靠。有些设备的驱动在初始化阶段不会立刻报错，但后续read会返回异常状态，这种case比较恶心。我在Pixel和几款国产旗舰上测试时遇到过，最终解决方案是：初始化成功后，先启动一次约200ms的试录，read返回值正常才认定设备可用。

5. 容易踩的坑与排查技巧

5.1 IllegalArgumentException的常见触发原因

用Builder配置高频采集时，最容易踩的坑就是IllegalArgumentException。我总结下来，触发原因集中在三种情况：

• 最大频率设置过高，超出设备支持范围。很多设备即便宣称支持192kHz采样，采集链路实际带宽可能只有40kHz。此时setMaxFrequencyHz(96000)会直接抛异常。
• 采样率小于2倍最大频率。这是数学层面的错误，系统直接拒绝。
• 编码格式不匹配。高频采集配ENCODING_PCM_8BIT是有问题的，8bit的动态范围根本表达不了高频信号的细节，部分实现会直接拒绝这种组合。

排查方法很简单，把构建参数打出来逐项比对：

Log.d("AudioRecordTest", "maxFreq=" + maxFrequencyHz + " sampleRate=" + sampleRate + " encoding=" + encoding);

实际项目里，设备侧拿到的采样率未必和你设置的一样，可以用record.getSampleRate()验证。

5.2 录出来的声音“闷”或者“尖”

这是高频采集最常见的质量问题。声音闷，通常是底层采样率被偷偷降了，高频信息根本没进来。声音尖，通常是录制链路里引入了额外的高频噪声。

先排查采样率：record.getSampleRate()返回和你设置不一致的话，说明设备做了降级，需要降低maxFrequencyHz档位。再排查通路：如果你用VOICE_COMMUNICATION作为AudioSource，那声音闷是必然的，语音通路的低通滤波器会切掉一切高频成分，必须换成MIC或UNPROCESSED。

Android 10以后音频源MediaRecorder.AudioSource.UNPROCESSED是个好东西，它表示“不要做任何处理”，最接近麦克风原始信号。在支持它的设备上，高频采集首选这个源。

5.3 read返回异常错误码

高频采集时，read返回ERROR_DEAD_OBJECT或反复返回0，在调试时特别头疼。常见原因有两个：

1. 缓冲区太小：高频数据量太大，底层溢出了。解决办法就是调大setBufferSizeInBytes。
2. 设备被抢占：系统电话、语音助手等高优先级任务抢占了麦克风。此时AudioRecord会进入Dead状态，必须release后重新构建。

针对第二种情况，建议监听AudioManager的ACTION_AUDIO_BECOMING_NOISY，或者注册AudioDeviceCallback。当检测到设备变化或录音中断时，自动走重连逻辑。App退到后台时，也要做好重新构建的准备，否则用户切回前台后录音可能半天不响。

5.4 与存储、播放链路的衔接

高频数据录下来之后，问题才刚开头。如果直接写WAV，文件体积巨大。我习惯将PCM数据先缓存，结束录音后用AudioRecord配套的编码器转成AAC或FLAC。这里唯一要注意的是，高频素材转码时，编码器参数里的采样率必须和录制采样率一致，很多转码工具默认按44.1kHz处理，转完高频信息全丢光了。

存储方面，如果你是做声学检测的，录音数据涉及隐私或商业机密，可以考虑在落盘前做一层对称加密。比如AES256对PCM流做加密再写入文件，密钥放在Android Keystore里，这也是目前本地音频存储比较稳妥的做法。Android 16里Keystore对AES-GCM的支持更完善了，性能开销相比几年前小了很多。

播放端同样有坑。低频语音还好，高频信号用普通扬声器播放，全部衰减没了。你是做超声检测的话，播放可以不做，直接走可视化频谱分析。如果非要监听效果，记得用支持高采样的播放链路，比如AudioTrack配合setSampleRate同样要多核对几遍。

6. 实测过程中的几个心得

项目做到最后，说几个不写进官方文档的体会。

第一，setMaxFrequencyHz不是银弹。底层硬件的模拟前端如果带宽不够，API再折腾也没用。很多手机麦克风为了通话降噪，模拟前端本身就带低通滤波，即使系统层面给你192kHz采样，信号在源头就已经残缺了。所以做高频采集前，先拿着示波器或者用频谱App看一下这个设备麦克风真实的频响曲线，比什么都重要。

第二，功耗和发热控制要比以前更用心。高频采集时DSP和CPU负载明显上升，长时间录音手机背面会发烫。我的方案是做一个动态降频策略：检测到设备温度过高时，主动把maxFrequencyHz调低一档，比如从96kHz降到48kHz，实测录音质量损失不大，但温度能降3到5度。AudioRecord本身不提供运行时修改频率的接口，只能先release再重建，注意在重建期间用一个环形缓冲把数据衔接好。

第三，高频数据在传统的FFT分析里容易“白化”。直接对192kHz采样的原始PCM做FFT，如果窗口大小和采样率不匹配，频谱图会显得非常杂乱，高频段全是毛刺。建议先做降采样，把高频信号搬移到分析目标频段再处理。移动端实时做192kHz点数的FFT不现实，分帧加窗才是正道。

Android 16的音频API更新方向很明确，就是给开发者更多底层的控制权。这个setMaxFrequencyHz目前在官方文档里位置不显眼，但用好了确实能解决很多以前束手无策的采集问题。大家做具体项目时，建议从低档位开始试探设备能力，再逐步提高，稳扎稳打比一步到位要可靠得多。