1. 音频基础与性能瓶颈
各位同学好，我是老张。做移动端音频处理有些年头了，踩过的坑比走过的路还多。今天咱们先聊聊最基础的东西——音频的三个核心参数：采样率、位深、声道数。别小看这三个参数，它们直接决定了你的 App 耗电快不快、会不会卡顿、甚至会不会闪退。
我记得刚入行那会儿，接手一个实时变声项目。产品经理说「给我上 192kHz 采样率，24bit 位深，立体声，要无损音质」。结果一跑，手机烫得能煎鸡蛋，延迟高到没法用。后来我才明白，音频处理不是堆参数就行的，你得懂背后的性能账。
1.1 采样率：每秒要处理多少次？
采样率，说白了就是每秒钟对声音信号采多少个点。44.1kHz 就是每秒 44100 个点，48kHz 就是 48000 个点。
为什么这个数字重要？因为你的 CPU 每秒钟要处理的数据量，跟采样率是成正比的。采样率翻倍，数据量就翻倍，计算量也跟着翻倍。
| 采样率 | 每秒采样点数 | 常见场景 | 性能开销（相对值） |
|---|---|---|---|
| 8kHz | 8000 | 电话语音 | 1x |
| 16kHz | 16000 | VoIP、语音识别 | 2x |
| 44.1kHz | 44100 | CD 音质音乐 | 5.5x |
| 48kHz | 48000 | 视频配音、游戏 | 6x |
| 96kHz | 96000 | 高解析音频 | 12x |
1.2 位深：每个点用多少比特？
位深决定了每个采样点的精度。16bit 就是每个点用 16 个比特表示，24bit 就是 24 个比特。
你想想看，位深增加 50%（从 16bit 到 24bit），数据量就增加 50%。而且位深还影响动态范围和信噪比，但移动端扬声器就那么小，24bit 和 16bit 你能听出区别？反正我盲听测试没赢过。
1.3 声道数：单声道还是立体声？
声道数更直接。单声道就是一路数据，立体声就是两路，5.1 环绕声就是六路。数据量直接乘以声道数。
移动端大部分场景，单声道就够了。为什么？因为手机扬声器就那么大，立体声分离度有限。除非你接耳机，否则立体声在手机外放上基本是浪费。
- 单声道：数据量 1x，适合语音、通话、语音助手
- 立体声：数据量 2x，适合音乐、视频、游戏（接耳机时有用）
- 多声道：数据量 3x 以上，移动端基本用不到
1.4 数据量计算公式
把上面三个参数合起来，就是音频数据量的计算公式：
数据量 (bytes/s) = 采样率 (Hz) × 位深 (bits) / 8 × 声道数举个例子：
CD 音质：44100 × 16 / 8 × 2 = 176,400 bytes/s ≈ 172 KB/s
高清语音：16000 × 16 / 8 × 1 = 32,000 bytes/s ≈ 31 KB/s
「发烧友」配置：96000 × 24 / 8 × 2 = 576,000 bytes/s ≈ 562 KB/s看到差距了吧？「发烧友」配置的数据量是 CD 音质的 3 倍多，是高清语音的 18 倍。这些数据都要经过 CPU 处理、内存搬运、DSP 计算，性能开销可想而知。
1.5 移动端 CPU/GPU/DSP 架构差异
嗯，这里要注意。移动端不是只有 CPU 干活，还有 GPU 和 DSP。它们各有各的擅长领域。
1.6 各处理单元的特点
CPU：最通用，但最耗电。适合做控制逻辑、协议解析、文件 I/O。不适合做大量重复的音频计算，比如 FFT、滤波、重采样。我见过有人用 CPU 做实时 FFT，结果手机 5 分钟就没电了。
GPU：并行计算能力强，但数据搬运开销大。适合做大批量、高并发的计算，比如频谱分析、卷积混响。但 GPU 的延迟较高，不适合低延迟场景（比如实时通话）。
DSP：这才是音频处理的亲儿子。专为信号处理设计，功耗低、延迟低、效率高。但编程难度大，而且不是所有设备都有独立的音频 DSP。
核心观点：移动端音频性能调优，本质就是「在合适的硬件上做合适的计算」。别拿 CPU 硬扛 DSP 的活，也别拿 GPU 做低延迟处理。选对硬件，性能优化就成功了一半。
1.7 实际项目中的选择策略
我个人习惯这样选：
- 先看目标设备：iOS 设备基本都有 Audio DSP，Android 设备参差不齐。如果目标用户是高端机，优先用 DSP；如果是低端机，老老实实用 CPU 优化。
- 再看场景：实时通话、K 歌、变声等低延迟场景，优先 DSP 或 CPU 优化；离线处理、音频编辑等场景，可以用 GPU 加速。
- 最后看参数：采样率、位深、声道数，够用就行。别为了「参数好看」牺牲用户体验。
好了，这一章的内容就这些。音频基础参数和硬件架构是后续所有优化的基石。你想想看，如果连数据量都算不清楚，怎么优化？如果连 CPU、GPU、DSP 的区别都不懂，怎么选方案？