在移动端音视频开发中，实现低延迟、高保真的音频处理一直是开发者面临的挑战。Android平台提供了MediaCodec和AudioTrack这两个强大的工具，但要想充分发挥它们的性能，需要深入理解其工作原理并掌握优化技巧。本文将带你从零开始构建一个高效的音频处理流水线。

一、移动端音频处理的挑战

1. 延迟问题：从音频采集到播放的端到端延迟需要控制在100ms以内才能实现实时交互
2. 功耗控制：持续的解码运算会快速消耗电量，特别是在使用软件解码时
3. 内存管理：音频数据缓冲区的合理分配直接影响OOM风险和GC频率
4. 设备兼容性：不同厂商对MediaCodec的实现存在差异

二、解码方案对比：MediaCodec vs FFmpeg

我们在一加8T设备上测试了两种解码方案的性能差异：

| 指标 | MediaCodec(硬解) | FFmpeg(软解) | |------|----------------|-------------| | CPU占用 | 8-12% | 35-45% | | 解码延迟 | 15-25ms | 40-60ms | | 功耗 | 中等 | 高 | | 兼容性 | 需要版本适配 | 通用性强 |

对于实时性要求高的场景，MediaCodec显然是更好的选择。

三、核心实现详解

1. MediaCodec配置关键代码

// 创建解码器实例
val codec = MediaCodec.createDecoderByType("audio/mp4a-latm")

// 配置MediaFormat (关键参数)
val format = MediaFormat().apply {
    setString(MediaFormat.KEY_MIME, "audio/mp4a-latm")
    setInteger(MediaFormat.KEY_SAMPLE_RATE, 44100)
    setInteger(MediaFormat.KEY_CHANNEL_COUNT, 2)
    setInteger(MediaFormat.KEY_AAC_PROFILE, MediaCodecInfo.CodecProfileLevel.AACObjectLC)
    // 必须设置CSD-0参数
    setByteBuffer("csd-0", ByteBuffer.wrap(extradata)) 
}

// 配置解码器
codec.configure(format, null, null, 0)

2. AudioTrack环形缓冲区实现

class AudioBufferThread : Thread() {
    private val bufferSize = AudioTrack.getMinBufferSize(
        44100,
        AudioFormat.CHANNEL_OUT_STEREO,
        AudioFormat.ENCODING_PCM_16BIT
    ) * 4 // 4倍缓冲

    private val audioTrack = AudioTrack(
        AudioAttributes.Builder()
            .setUsage(AudioAttributes.USAGE_MEDIA)
            .build(),
        AudioFormat.Builder()
            .setSampleRate(44100)
            .setEncoding(AudioFormat.ENCODING_PCM_16BIT)
            .build(),
        bufferSize,
        AudioTrack.MODE_STREAM,
        AudioManager.AUDIO_SESSION_ID_GENERATE
    )

    private val bufferQueue = LinkedBlockingQueue<PcmData>(10)

    override fun run() {
        audioTrack.play()
        while (!interrupted()) {
            val data = bufferQueue.take()
            audioTrack.write(data.buffer, 0, data.size)
        }
    }
}

四、性能优化实战

1. 实测数据对比

优化前后关键指标变化：

| 指标 | 优化前 | 优化后 | |------|--------|--------| | 内存占用 | 25MB | 12MB | | 延迟 | 120ms | 45ms | | CPU峰值 | 28% | 15% |

2. 异常处理策略

• 解码失败：捕获MediaCodec.CodecException后重启解码器
• 采样率不匹配：动态调整AudioTrack配置或使用重采样
• 缓冲区不足：监控INFO_OUTPUT_BUFFERS_CHANGED事件

五、避坑指南

解决AudioTrack underrun的5个方法

1. 增大缓冲区大小为最小值的2-4倍
2. 使用MODE_STREAM而非MODE_STATIC
3. 确保写入线程优先级高于UI线程
4. 预热AudioTrack提前分配资源
5. 监控AudioTrack.getUnderrunCount()进行预警

MediaCodec资源释放时序

正确的释放顺序非常重要：

1. 停止解码器：codec.stop()
2. 释放资源：codec.release()
3. 清空缓冲区队列
4. 最后释放AudioTrack

六、进阶方向

对于追求极致性能的开发者，可以尝试：

1. 使用Opus编码替代AAC，降低比特率
2. 集成NDK实现DSP加速
3. 实验低延迟音频路径(AAudio)
4. 探索Oboe库的统一音频接口

通过本文介绍的技术方案，我们成功将端到端音频延迟控制在50ms以内。希望这些实战经验能帮助你在音视频开发中少走弯路。记住，性能优化是个持续的过程，建议定期使用Android Profiler监控关键指标。