企业官网建设流程全解析

安卓平台上做一个实时声音分贝检测应用，听起来像是个入门级练手项目——拿AudioRecord读一段 PCM，算个 RMS，取个对数，往界面上打一个数字，五十行代码就能跑起来。我刚接触这个方向的时候也是这么想的，直到把一个"能跑"的 Demo 拿到安静房间和嘈杂车间里各测了一遍，才发现两个场景下的读数不仅互相打架，连自己前后两次都对不上。真正卡住人的地方从来不是那行对数公式，而是你怎么证明屏幕上那个数字跟真实声压之间有稳定的对应关系。这篇就来拆这件事：从采集参数怎么定、分贝怎么算、校准怎么做，一直讲到真机上那些把测量值搅乱的隐藏因素。适合已经能跑通录音 Demo、想把读数做到"能拿去用"的安卓开发者看，也适合做噪音监测、环境记录、乐器辅助工具这类功能的同学参考。基础薄弱的也不用担心，采集相关的底层概念我会在用到的地方顺手铺开。

1. 分贝检测应用到底在测什么：把"声音大小"拆成三个可计算量

很多人一上手就直奔公式，结果算出来的数字看着挺像那么回事，一换设备就崩。问题出在概念层：手机上这条链路里存在三个完全不同性质的量，混在一起谈就容易翻车。我习惯在动手写第一行代码之前，先把这三个量在纸上列清楚，后面所有参数选择都从它们推导出来。

1.1 麦克风吐出来的是电压序列，不是分贝

声波推动麦克风振膜，振膜的位移改变电容，电容变化被转换成电压，电压再被模数转换器切成一个个整数——到你手里的ShortArray，从头到尾没有一个环节产生"分贝"这个物理量。分贝的本质是两个同类量的比值再取对数，它描述的永远是"相对于某个基准有多大"，而不是"绝对有多大"。声学里常用的基准是人耳刚能听到的声压，大约是 20 微帕。也就是说，只有当你手里同时握着"当前声压"和"基准声压"两个值时，算出来的才叫声压级。

手机给你的只有采样点幅值。一个 16 位采样的取值范围是 -32768 到 32767，它的"基准"是满量程 32768，所以从采样点直接算出来的是 dBFS，Full Scale 的意思就是"相对满量程的分贝"。这个量很有用，但它描述的是"信号离数字溢出的边界还有多远"，跟房间里的实际声压没有必然关系。

打个不太严谨但好理解的比方：你拿一把没有刻度的弹簧去量东西，弹簧压缩了多少你能精确读出，但它对应几公斤，得先拿标准砝码标定一次。采样点幅值就是"压缩了多少"，声压级就是"几公斤"。

1.2 dBFS 和声压级之间那道必须自己填的沟

那这道沟有多宽？它由三个硬件因素共同决定：麦克风的灵敏度（多少毫伏对应 1 帕斯卡）、内部放大器的增益、以及模数转换器的参考电压。这三样东西在不同机型上完全不同，甚至同一机型不同批次也会有偏差，而且厂商基本不会开放给你。

所以工程上的标准做法是承认它存在，用一个标定偏移量把它填平：

声压级(dB) = 20 * log10( RMS / 32768 ) + 校准偏移

这里的校准偏移就是那道沟，单位是 dB。实测下来，手机麦克风的这个值通常落在 90 到 110 之间——意思是在一个大约 30 到 40 分贝的安静房间里，你的 RMS 大概只有几十到几百，换算成 dBFS 是 -70 左右，加上 95 的偏移，得到 25 左右，量级上是合理的。

关键在于，这个偏移量必须针对每台设备单独测出来，没有任何公式可以推导。凡是号称"免校准自动准确"的实现，要么是取了一个大样本平均值，要么是在某个特定机型上调过参数然后对外宣称通用。前者误差能到 ±10 dB，后者换台机器就废。这个认知先立住，后面第 3 章再讲具体怎么测。

1.3 实时性的时序账：20 毫秒一帧意味着什么

"实时"这两个字也得算清楚。假设采样率 48000 Hz，你希望每 20 毫秒出一帧数据做一次计算，那一帧就是 960 个采样点。一秒钟要处理 50 帧，一共 48000 次乘加运算算 RMS——这个量对现代手机 CPU 完全不构成压力，单帧算 RMS 加取对数的耗时通常在几十微秒级别。

真正的时间压力在别处：采集线程的read()是阻塞的，你读得慢了，硬件缓冲区就会溢出（overrun），溢出的数据直接丢失，表现出来就是读数偶尔跳一下或者波形断一截。这个问题的根源往往不是计算太慢，而是你在采集线程里顺手干了别的事情——拼字符串、更新 UI、写日志。我在早期版本里就干过在采集循环里Log.d打印每帧分贝的事，日志刷屏直接把帧序搞乱了。

所以整条链路的时序设计原则很朴素：采集线程只做搬运，计算尽量轻量，重活全部丢给下游。这条原则会贯穿第 2 章和第 4 章的所有决策。

2. 采集层的工程实现：AudioRecord 的初始化参数怎么定

采集是整个应用的地基，参数定错后面怎么调都别扭。AudioRecord的构造函数一共五个参数，看起来简单，但每个都有讲究，而且它们的取值之间还有耦合关系。

2.1 采样率、声道、位深：三个参数的真实取舍

采样率这一项，我的结论是优先 48000，拿不到再退 44100。理由不是"越高越准"这种笼统说法，而是具体的：人耳可听范围上限约 20 kHz，44100 采样率对应的奈奎斯特频率是 22050 Hz，理论上够用；但手机麦克风和前端的抗混叠滤波器通常做得比较糙，接近奈奎斯特频率的地方会有明显衰减，如果你后面要做 A 计权（需要看高频段的能量），44100 的边带信息质量会打折。48000 留出的余量更从容，同时它也是大部分安卓设备音频通路的原生速率，走这条路径反而更少经过重采样环节。

声道直接用单声道。分贝测量关心的是总声压，双声道会让你的计算量翻倍、缓冲区翻倍，而左右两个麦克风间距只有几厘米，测出来的差值基本在噪声范围内。除非你要做声源方向判断，否则没必要。

位深选ENCODING_PCM_16BIT。ENCODING_PCM_FLOAT在 API 21 以上名义上支持，但部分机型在AudioRecord上用浮点格式会初始化失败或者读到异常数据，而且 16 位的 96 dB 动态范围对声级测量完全够用——你更该担心的是手机麦克风本身那点信噪比，而不是量化精度。

初始化代码大概长这样：

private const val SAMPLE_RATE = 48000 private const val CHANNEL = AudioFormat.CHANNEL_IN_MONO private const val ENCODING = AudioFormat.ENCODING_PCM_16BIT val minBuf = AudioRecord.getMinBufferSize(SAMPLE_RATE, CHANNEL, ENCODING) // minBuf 可能返回 ERROR 或 ERROR_BAD_VALUE，必须校验 val bufferSize = minBuf * 4 val record = AudioRecord( MediaRecorder.AudioSource.MIC, SAMPLE_RATE, CHANNEL, ENCODING, bufferSize ) if (record.state != AudioRecord.STATE_INITIALIZED) { // 这里不能直接崩，要降级重试 44100 }

注意getMinBufferSize是有可能返回负值的，不校验直接乘 4，后面构造出来的对象状态是STATE_UNINITIALIZED，startRecording会抛异常。这个坑在低端机上出现频率不低。

2.2 缓冲区大小的三档配置与实测表现

缓冲区大小直接影响两件事：延迟和稳定性。它跟你每次read()请求的长度是两个概念——前者是硬件和驱动层的环形缓冲总容量，后者是你单次取走的量。我一般这么定：

缓冲区给两倍是最低安全线，一倍的话只要线程被系统调度稍微打断一下就溢出。给到八倍换来的是极高的抗抖动能力，代价是延迟肉眼可见——你拍一下手，屏幕上要等小半秒才有反应。对声级测量这个场景，我默认用四倍，只有在实测到某台机器频繁丢帧时才往上调。

单次读取长度和缓冲区大小的比例最好保持在 1:4 左右。读取太频繁（比如每次只读 5 ms）会让线程被唤醒的次数暴涨，功耗跟着上去；读取太少次（比如一次读整个缓冲区）则失去了"流式"的意义。

2.3 线程模型：为什么采集线程不能用普通 Thread 的默认优先级

采集必须放在独立线程里，这没什么争议，主线程上做阻塞读会直接 ANR。但"独立线程"也分层级，我踩过的坑是用Executors.newSingleThreadExecutor()起线程，跑起来一切正常，直到手机发热或者后台有其他任务，帧序就开始抖。

正确做法是在采集线程入口处把线程优先级提到音频级别：

private val recordThread = Thread { Process.setThreadPriority(Process.THREAD_PRIORITY_AUDIO) val frameSamples = SAMPLE_RATE * 50 / 1000 // 50 ms val buf = ShortArray(frameSamples) while (isRecording) { val n = record.read(buf, 0, buf.size) if (n > 0) { // 只做最轻的搬运，计算交给下游 frameQueue.offer(buf.copyOf(n)) } else if (n < 0) { // 读错误，记录并考虑重启采集 break } } }.apply { isDaemon = true }

THREAD_PRIORITY_AUDIO对应的优先级值是 -16，比普通线程高出一大截，能显著降低被抢占的概率。同时注意buf.copyOf(n)这一句——如果你直接把buf的引用丢进队列，下一轮循环read会覆盖它，下游拿到的永远是同一块被改写的数据。这个 bug 极其隐蔽，表现是"数据看起来有，但波形全是乱的"，我在排查一个月的项目里遇到过两次。

还有一点：read()返回负数代表错误，返回 0 代表暂时没数据，这两种情况要分开处理。返回负数时不要立刻无脑重启，先看错误码，频繁重启采集会让麦克风资源处于争抢状态，反而更不稳定。我的做法是连续三次读失败才重建AudioRecord实例。

3. 从幅值到分贝：RMS、峰值、平滑与校准的完整链路

采集层把干净的 PCM 帧交给下游之后，接下来这一段决定了你屏幕上那个数字到底有没有意义。很多实现到这里就草率了——算个 RMS，套个对数，完事。差的是后面四个环节：直流偏置处理、时间计权、峰值保持、校准偏移。

3.1 单帧 RMS 的计算与对数换算

RMS 是均方根，先把所有采样点平方、求平均、再开方。放进代码里就三行：

fun frameRms(buf: ShortArray, len: Int): Double { var sum = 0.0 for (i in 0 until len) { val v = buf[i].toDouble() sum += v * v } return sqrt(sum / len) } fun rmsToDbfs(rms: Double): Double { if (rms < 1e-9) return -120.0 // 防 log(0) return 20.0 * log10(rms / 32768.0) }

有两个细节值得说。第一是直流偏置，部分设备的前端电路会带一个恒定的小偏移（比如所有采样点都偏 +30），这个偏移会在平方求平均时被放大成虚假的能量。判定方法很简单：把一帧数据求算术平均，如果结果显著偏离 0（绝对值超过 50），就说明存在直流偏置，做 RMS 之前先整体减掉这个均值。我在三台设备上测过，其中一台的偏移达到了 60 左右，不处理的话安静环境下读数会虚高 3 dB 以上。

第二是静音保护。当所有采样点都是 0 时，log10(0)会返回负无穷，直接显示在界面上就是-Infinity或者乱码。加一个极小值兜底，并且把下限钳制到 -120 dBFS，界面上显示成"低于量程"而不是一个怪异数字。

3.2 校准偏移量到底怎么测出来

这是整篇文章里最实在的一段。校准偏移没有理论值，只能实测，方法分两种情况：

如果你手边有一台声级计，这是最靠谱的路径。步骤是：找一个稳定声源（空调外机、持续的白噪声播放、风扇都行，关键是别用说话声这种起伏大的），把声级计和手机并排放置，距离声源同样的位置；等声级计读数稳定后记录一个平均值，同时记录你应用里对应时刻的 dBFS 平均值；两者相减就是偏移量。

校准偏移 = 声级计读数(dB) - 应用读数(dBFS)

这里有个容易忽略的细节：声级计通常用 A 计权，而简化的 RMS 实现是线性（不加权）。在低频成分明显的环境里，两者会差好几个 dB。所以对测的时候，要么把声级计切到 C 计权或线性档，要么给你的应用也加上 A 计权（第 3.4 节讲）。这一条对不上，很多人会误以为是校准方法错了，来回折腾半天。

如果没有声级计，退一步的做法是用一个已知声压级的校准声源。市面上有专门输出 94 dB 或 114 dB、频率 1 kHz 的便携校准器，把它套在手机麦克风上，直接读出 dBFS，偏移量一秒算出来。这类设备价格不算离谱，如果这个功能是产品的核心，买一个不亏——它能把校准从"每次靠猜"变成"一键完成"，而且能覆盖到多台设备的横向对比。

不管用哪种方式，测出来的偏移量都要落在应用里可查、可改。我的做法是给它做一个隐藏的设置项，默认填一个该机型的典型值，允许用户用参考设备对测后手动修正。同时把这个值和设备型号、系统版本一起写进本地配置，换设备自动重新校准。

3.3 时间计权：快档、慢档与指数平滑

单帧 RMS 换算出来的分贝是"瞬时值"，跳动极其剧烈。人耳对响度的感知有积分时间，声级测量领域也沿用了时间计权的惯例：快档的时间常数大约 125 毫秒，慢档大约 1000 毫秒。实现上就是指数平滑：

α = 1 - exp(-Δt / τ) y[n] = α * x[n] + (1 - α) * y[n-1]

其中 Δt 是帧间隔（秒），τ 是时间常数（秒）。举个具体数：帧间隔 0.05 秒，时间常数 0.125 秒，算出来 α ≈ 0.33；慢档 τ=1 秒时 α ≈ 0.049。快档跟手但抖，慢档平稳但迟钝，我一般在主数字上用慢档，柱状图和波形用快档，两个数值同时显示，用户体验会好很多。

还有一个很有用的量是等效声级，也就是一段时间内的能量平均，公式是：

Leq = 10 * log10( (1/N) * Σ 10^(Li/10) )

注意这里是对数域的平均，必须先取幂再加权，不能直接把分贝值求算术平均——那样算出来的结果会偏低，而且在起伏越大时偏得越多。这个错误我在别人的代码里见过不止一次。Leq 适合做"这次测量整体有多吵"的总结指标，配合实时值一起展示，比单纯给一个瞬时数字信息量大得多。

3.4 A 计权与 FFT：什么时候必须上频域

前面的 RMS 是线性计权，对低频和高频一视同仁。但人耳对不同频率的敏感度差异巨大，同样声压级下，2 kHz 到 4 kHz 的声音听起来比 100 Hz 响得多。要贴近主观感受，就得做 A 计权。

A 计权的实现路径必须是频域：对每帧数据做快速傅里叶变换，得到各个频率分量的能量，然后按 A 计权曲线对每个频率分量加权，最后把加权后的能量求和，再转回分贝。关键是 A 计权的权重必须作用在能量上（也就是幅度谱的平方），不能直接乘在分贝值上，这是最容易出错的地方。

如果不想从零写 FFT，可以自己实现一个基 2 的迭代版本，两百行左右，或者用成熟的开源实现。帧长取 2048 点（48000 采样率下约 42 毫秒）是个不错的平衡点，频率分辨率约 23 Hz。加汉宁窗抑制频谱泄漏，窗函数的能量损失要做补偿，否则总能量会系统性偏低几个 dB。

需要提醒的是，A 计权不是必需品。如果你的应用定位是"粗略感知环境音量"，线性 RMS 已经完全够用，用户也不会察觉差别。只有在需要对标专业设备、或者要输出能跟其他仪器横向比较的读数时，才值得投入这部分工作量。我自己是把它做成可选项，默认关闭，界面上给个"人耳感知模式"的开关。

4. 实时界面与数据落盘：把 20 毫秒的节奏撑住

计算链路跑通之后，下一个瓶颈立刻转移到界面和存储上。这两块都是"看起来无关紧要，实际上能拖垮整条链路"的环节。

4.1 环形缓冲：让采集和消费彻底解耦

采集线程以 50 毫秒一帧的速度往队列里塞数据，消费端可能是计算线程、可能是存储线程，速度不可能完全一致。用ArrayBlockingQueue是最简单可靠的方案，容量给 16 到 32 就够，塞满时直接丢弃最旧的帧而不是阻塞——采集线程绝对不能因为下游慢而卡住。

但这里有个隐藏成本：每帧都copyOf一次会持续产生短生命周期对象。一秒 20 帧，一分钟 1200 个，对 GC 来说确实不算什么，但在低端机上长时间录音，这些分配会累积成可感知的卡顿。更稳的做法是预分配一个对象池，用一个固定大小的Array<ShortArray>循环使用，采集线程从池里取空数组、消费端用完后归还。这套机制稍微复杂一点，但对连续录音一小时的场景，收益是明显的。

环形缓冲的另一个用处是给波形显示提供历史数据。你可能需要显示最近 5 秒的波形，那就在池里维护对应数量的帧，界面绘制时按时间顺序排列即可，不需要额外的数据结构。

4.2 UI 刷新节流：别让屏幕拖累计算

采集是 20 帧每秒（按 50 毫秒一帧算），但界面完全不需要这么高的刷新率。人眼对数字变化的感知阈值差不多在 100 毫秒以上，波形图 30 帧每秒已经很顺滑。所以我做了分频策略：

实现上用Handler定时投递或者Choreographer回调都行，但必须保证界面绘制的计算量恒定。我见过一种写法是把 RMS 计算塞进自定义 View 的onDraw里，结果一到复杂界面就掉帧，连带采集线程也被拖慢。原则很简单：onDraw里只做绘制，所有数值提前算好放在一个不可变的数据对象里。

波形绘制的性能坑还有一个：每次onDraw都新建Path对象。这个必须避免，Path、Paint都提前在构造函数里建好，绘制时用reset()复用。

4.3 测量记录与录音同步保存

如果应用需要保存测量数据，我建议存两份东西：一份是结构化的测量记录（时间戳、分贝值、Leq、温度/位置等元数据），CSV 就够；另一份是原始音频，用 WAV 格式直接写，别一上来就上压缩。

CSV 的好处是用户拿 Excel 就能看，也方便你自己排查问题——把某一时段的分贝曲线和音频对起来听，很快就能发现问题出在算法还是环境。WAV 直接写 PCM 数据加一个 44 字节文件头即可，不需要MediaCodec那一套状态机，代码量小，格式无损，便于事后重新分析。

写文件这个动作必须放在独立线程，而且不要每帧都flush。用BufferedOutputStream包一层，攒到 64 KB 再刷一次盘，功耗和延迟都能接受。录音文件按时间切片，比如每 10 分钟一个文件，避免单个文件过大导致写失败或者用户导出困难。

5. 真机实测里踩到的坑：增益、削顶、静音与设备差异

算法层面弄对之后，你会发现读数还是不靠谱。这一章讲的就是那些"代码没错但结果不对"的情况，也是我从一个能跑的 Demo 走到能用之间花时间最多的地方。

5.1 系统自动增益和降噪是怎么把测量值搅乱的

现代手机在音频采集通路上默认挂了一堆处理模块：自动增益控制（AGC）、噪声抑制（NS）、回声消除（AEC）。这些东西对通话和录音是好事，对声级测量是灾难——AGC 会在声音小时自动拉高增益，让安静环境读数虚高；声音大时压低增益，让嘈杂环境读数虚低。表现出来就是动态范围被压扁了，你可能测到 40 到 90 的环境全都落在 55 到 70 之间。

排查这条问题的链路我摸索出一套固定顺序，写下来供参考：

第一步，先怀疑算法。用一个纯正弦波音频文件播放，看读数是否稳定。如果算法本身有问题，正弦波也会抖。这一步排除掉大部分低级错误。

第二步，做距离测试。保持声源音量不变，把手机从 30 厘米慢慢移到 1.5 米。正常的自由场衰减大概是距离翻倍降 6 dB，如果你的读数几乎不变，基本可以锁定是 AGC 在作祟。

第三步，换音频源。把MediaRecorder.AudioSource.MIC换成UNPROCESSED，看看读数是否变化。UNPROCESSED名义上会绕过所有处理，但它是否真的生效完全取决于设备厂商的实现，得先用AudioManager.getProperty查一下支持情况，别默认它一定可用。

第四步，主动关闭效果器。这是最直接的干预手段：

val sessionId = record.audioSessionId AutomaticGainControl.create(sessionId)?.setEnabled(false) NoiseSuppressor.create(sessionId)?.setEnabled(false) AcousticEchoCanceler.create(sessionId)?.setEnabled(false)

注意create()有可能返回 null，而且返回非 null 也不代表setEnabled(false)一定成功——很多机型的硬件层压根不认这个请求。我的做法是关闭之后重新测一遍距离曲线，如果还是没有衰减，就在应用里给用户提示"当前设备可能有系统级音频处理，读数仅供参考"。诚实比假装准确好。

5.2 削顶失真造成的"假高分贝"

削顶（clipping）是另一个常见问题。当声压超过麦克风和前端的最大承受范围时，采样点会被钳在 ±32767，波形顶部被削平。这时候算出来的 RMS 偏小，但因为波形变成了近似方波，高频谐波能量暴增，如果做了 A 计权，读数反而会异常偏高——两个方向的误差叠加在一起，非常迷惑。

检测方法很直接：统计一帧里绝对值超过阈值（比如 32000）的采样点比例，超过千分之一就认为发生了削顶。这时界面上应该给出视觉提示，而不是若无其事地显示一个数字。

触发削顶最常见的场景不是环境太吵，而是用户的手指挡住了麦克风孔。这个孔通常在手机底部或者背面，握持姿势一变就被堵住，声压直接翻倍。我在测试时遇到过用户反馈"读数经常突然爆表"，最后发现就是握持习惯问题。解决办法是在应用里做一张麦克风位置示意图，并加一句提示。

真遇到削顶时，处理策略只有两条：要么提示用户远离声源或调整握持，要么在数字显示上打上"超出量程"标记，不要试图通过软件衰减去"修正"——削顶是信息丢失，补不回来的。

5.3 不同设备之间的读数差异有多大

我必须说清楚一个事实：用手机做声级测量，误差 ±3 dB 已经是很好的结果，±5 dB 是常态。下面是我在同一个安静房间（参考声级计读数 38 dB）和同一台持续声源（参考 72 dB）下，对几台不同价位设备做的粗略对比：

你看，入门机在安静环境下虚高 6 dB，原因是它自己的电路本底噪声就被算进去了——这不是算法问题，是硬件信噪比决定的。这种情况下无论怎么校准都救不回来，因为固定的偏移量没办法同时满足"安静段偏高"和"响段偏低"这两个相反的方向。

所以如果你的应用面向多机型，最现实的做法是：按设备档位做分段校准，或者干脆在界面上明确标注"测量结果受设备硬件限制，仅供相对比较参考"。用户对"相对变化"的接受度远高于对"绝对值"的，告诉他们"现在比刚才吵了 15 dB"，比告诉他们"现在是 68.3 分贝"要诚实得多。

5.4 静音检测与后台运行的现实约束

还有两个容易被忽略的场景。一是全零帧。有些设备在麦克风被其他应用占用、或者系统进入某种省电状态时，会持续返回全零数据。如果你的代码不做判断，读数会稳定地显示为下限值，用户以为环境很安静，其实是采集已经断了。判定方法是连续 N 帧（比如 20 帧）的 RMS 都低于一个极小阈值，就判定为"采集异常"，界面上给出明确提示。

二是后台运行。应用切到后台或者息屏之后，系统的电源管理策略可能会限制采集频率甚至直接掐断。如果你需要长时间连续测量，正确姿势是用前台服务并展示常驻通知，这样系统会把你的进程归到较高的优先级组。即便如此，不同厂商的省电策略差异很大，我一般会在应用里加一个"测量中保持屏幕常亮"的选项作为兜底，用FLAG_KEEP_SCREEN_ON实现，简单有效。

6. 参数速查与调优经验：能直接抄走的部分

写到这里，核心链路都过了一遍。最后把散落在各章的关键数值和排查经验整理成速查形式，方便你在自己项目里直接对照。

6.1 关键参数速查表

这张表里的数值不是唯一解，但每一个都是我在实际调试中验证过的起点。你可以在此基础上微调，但不建议改动采样率和缓冲区这两项的核心逻辑，改了之后所有关于延迟和稳定性的结论都要重新推一遍。

6.2 常见异常对照表

这张表的使用方式是从上往下按可能性排序，而不是逐条排查。绝大多数现场问题都落在前三行。

6.3 我自己踩过之后才明白的几件事

第一件，先做校准，再做界面。我早期版本是先做界面后补校准，结果界面上所有数值的更新逻辑都要跟着改一遍，返工量比重写还大。校准偏移量应该是整个数据流的固定入口参数，从第一天就该存在。

第二件，测量结果的不确定度要写进产品语言里。用户看到"68.3 dB"会默认你的精度到 0.1 dB，实际上差着好几个 dB。我的做法是主数字保留整数，旁边加一个 ±3 的图示标记，并在首次使用时弹一次说明。这个改动之后的用户投诉量明显下降——不是精度变好了，而是预期被校准对了。

第三件，保留原始音频是救命功能。遇到用户反馈"你们应用测错了"，如果你的应用存了当时的音频，回放一听就知道问题在哪；没存的话，就只能对着代码猜。存储成本很低，价值极高。

最后分享一个调试小技巧：在开发阶段留一个隐藏的调试面板，把单帧 RMS、dBFS、平滑后的分贝、削顶率、帧计数、缓冲区剩余量一起显示出来。这六个数并排放着，绝大部分问题一眼就能定位到是哪一层出的岔子。这个面板后来成了我排查所有音频问题的主力工具，比任何日志方案都直接。功能上线时把它藏在版本号连点五下的入口里，既不影响普通用户，又能随时唤起。