22、音频性能优化：CPU占用优化、内存管理策略、中断与轮询模式选择、功耗优化技巧

各位同学，今天我们来聊聊音频性能优化。说实话，这部分内容在面试中经常被问到，但在实际项目中却很少有人能讲清楚。我做了这么多年音频系统，踩过的坑不少，今天就把这些经验分享给你们。

CPU占用优化：别让音频吃掉你的算力

CPU占用过高，说白了就是你的音频处理线程在跟其他任务抢时间片。我见过一个项目，播放音乐时CPU占用直接飙到30%，结果UI卡顿、动画掉帧，用户反馈说“手机像中了毒”。

怎么优化？核心思路就两条：减少不必要的计算，让计算发生在正确的时间。

1. 减少数据拷贝

音频数据在驱动、AudioFlinger、HAL之间来回拷贝，这是CPU占用的主要来源。我建议使用共享内存或ION buffer，避免memcpy。在Android中，AudioFlinger通过AudioBufferProvider接口传递数据，如果你能实现零拷贝，CPU占用能降一半。

// 不推荐：频繁拷贝
memcpy(output_buffer, input_buffer, size);

// 推荐：使用共享内存
sp<IMemory> sharedMem = heap->getMemory(bufferId);
audio_track_cblk_t* cblk = static_cast<audio_track_cblk_t*>(sharedMem->pointer());

2. 避免高频回调

AudioFlinger的MixerThread默认每10ms回调一次。如果你把回调间隔改成20ms，CPU占用能降一半，但延迟会翻倍。这是个取舍问题。我个人习惯是：对于音乐播放，用20ms；对于VoIP或游戏，用5-10ms。

3. 使用FastMixer

Android 5.0引入的FastMixer，专门处理低延迟音频。它运行在独立的实时线程上，优先级高，但CPU占用反而更低。为什么？因为它用批处理方式，一次处理多个buffer，减少了上下文切换。

内存管理策略：别让音频吃掉你的RAM

音频内存管理，我踩过最大的坑是内存泄漏。有一次，播放器切歌时内存一直涨，最后OOM了。查了两天才发现，是AudioTrack的buffer没有正确释放。

1. Buffer池化

频繁申请释放内存，不仅慢，还容易产生碎片。我建议用对象池或环形缓冲区。AudioFlinger内部就用了一个BufferQueue，但很多第三方HAL实现没有复用。

// 伪代码：Buffer池化
class AudioBufferPool {
    std::vector<AudioBuffer*> pool;
    AudioBuffer* acquire() {
        if (pool.empty()) return new AudioBuffer();
        AudioBuffer* buf = pool.back();
        pool.pop_back();
        return buf;
    }
    void release(AudioBuffer* buf) {
        pool.push_back(buf);
    }
};

2. 按需分配，不要预分配过多

很多开发者喜欢“多分配一点，反正用不完”。但音频buffer如果太大，不仅浪费内存，还会增加延迟。我建议根据采样率和通道数精确计算：

采样率	通道数	位深	10ms buffer大小
44100	2	16bit	1764 bytes
48000	2	16bit	1920 bytes
48000	6 (5.1声道)	24bit	8640 bytes

3. 及时释放不再使用的资源

我曾经遇到一个问题：播放完音频后，AudioFlinger的线程没有退出，一直占用内存。后来发现是AudioFlinger::closeOutput()没有正确调用。记住，每个AudioTrack或AudioRecord对象，用完一定要调用release()或close()。

中断与轮询模式选择：别让CPU空转

中断和轮询，是音频数据传输的两种方式。选错了，CPU要么被频繁打断，要么一直在空转。

1. 中断模式：适合低延迟场景

中断模式是硬件主动通知CPU“数据准备好了”。优点是延迟低，缺点是频繁中断会消耗CPU。我建议在VoIP、游戏等低延迟场景使用中断模式。

但要注意：中断频率不能太高。如果每次传输1个frame就中断一次，CPU会疯掉。一般建议每次中断传输16-32个frame。

2. 轮询模式：适合高吞吐场景

轮询模式是CPU主动去检查“数据准备好了没”。优点是实现简单，缺点是CPU一直在空转。我见过一个项目，轮询间隔设成了1ms，结果CPU占用直接到50%。

轮询间隔怎么设？我建议：

• 音乐播放：10-20ms轮询一次
• 录音：5-10ms轮询一次
• VoIP：3-5ms轮询一次

3. 混合模式：我推荐的做法

在实际项目中，我更喜欢用混合模式：正常情况下用中断，当系统负载高时切换到轮询。AudioFlinger的ThreadBase类就支持这种动态切换，通过mIsFastTrack标志来判断。

// AudioFlinger中的混合模式逻辑
if (mIsFastTrack) {
    // 中断模式：等待硬件信号
    mWaitWorkCV.waitRelative(mLock, timeout);
} else {
    // 轮询模式：主动检查
    while (!mActiveTracks.isEmpty()) {
        processTracks();
        usleep(10000); // 10ms轮询
    }
}

功耗优化技巧：让音频更省电

功耗优化，说白了就是让CPU少干活、让硬件多干活。我做过一个项目，优化后音频播放功耗从500mW降到了200mW，续航直接多了2小时。

1. 使用硬件加速

很多SoC都有音频DSP或硬件编解码器。如果你用软件做混音、重采样、编解码，CPU占用高，功耗自然高。我建议尽量把工作卸载到硬件上。

• 混音：用硬件混音器，而不是软件混音
• 重采样：用硬件SRC，而不是libresample
• 编解码：用硬件CODEC，而不是软件解码

2. 降低采样率

采样率越高，数据量越大，CPU和总线负载越高。对于音乐播放，48kHz足够了；对于语音，16kHz就够。我见过有人用192kHz播放语音，纯粹是浪费电。

3. 使用低功耗音频路径

Android从8.0开始支持低功耗音频路径（Low Latency Audio Path）。它绕过了AudioFlinger的混音器，直接走硬件路径。功耗能降低30%-50%。

// 启用低功耗音频路径
audio_attributes_t attributes;
attributes.usage = AUDIO_USAGE_MEDIA;
attributes.flags = AUDIO_FLAG_LOW_LATENCY;

AudioTrack track(attributes);
track.start(); // 自动选择低功耗路径

4. 合理使用电源锁

音频播放时，系统会持有PARTIAL_WAKE_LOCK，防止CPU休眠。但如果你播放的是静音或暂停状态，就不需要持有电源锁。我建议在AudioTrack::pause()时释放电源锁，在start()时重新获取。

知识体系总览

下面这张图，是我总结的音频性能优化知识体系。你可以把它当作一个检查清单，做优化时对照着看。

好了，这一章的内容就到这里。音频性能优化没有银弹，每个场景都需要具体分析。但记住一个原则：让硬件多干活，让CPU少干活。你按照这个思路去优化，基本不会跑偏。