26、AEC性能优化：CPU占用优化、内存管理、实时性保证

各位同学，今天我们来聊聊AEC落地时最头疼的问题——性能优化。

说实话，算法在PC上跑得再漂亮，到了手机上一卡顿，用户直接卸载。我见过太多团队，算法精度做到90%，结果CPU占用飙到40%，产品经理当场脸就绿了。所以这一章，咱们就掰开揉碎，讲讲怎么让AEC在Android设备上跑得又快又稳。

CPU占用优化：别让算法吃掉主频

AEC的CPU消耗大头在哪？说白了就是两个地方：自适应滤波器的迭代更新和双讲检测的频繁计算。我早期优化时，发现滤波器更新占了60%的算力，这显然不合理。

1. 降采样：从源头减负

音频采样率通常是16kHz或48kHz。但AEC的核心处理其实不需要那么高的频率。我个人习惯的做法是：

• 将48kHz降采样到16kHz做AEC核心处理
• 处理完再升采样回48kHz
• 降采样用简单的抽取+低通滤波，别用太复杂的滤波器

这样做，滤波器阶数直接降到原来的1/3，计算量减少70%以上。我在项目中遇到过，降采样后CPU占用从35%降到了12%，效果立竿见影。

2. 分块处理：别逐样本算

逐样本更新滤波器？那是教科书写法。实际工程中，我们通常用分块频域自适应滤波（PBFDAF）。简单说就是：

• 攒够一块数据（比如128个样本）
• 一次性做FFT、频域相乘、IFFT
• 块与块之间用重叠保留法衔接

这样做，FFT的调用次数大幅减少。我记得有一次优化，把块大小从64改成256，CPU占用又降了15%。但要注意，块太大延迟会变高，这个后面再讲。

3. 条件更新：别白费力气

滤波器不是每时每刻都需要更新。双讲期间、静音期间，更新反而会发散。我建议的做法是：

• 只在单讲期间更新滤波器系数
• 双讲期间冻结更新，只做回声抑制
• 静音期间直接跳过所有处理

我曾经踩过一个坑：双讲期间强行更新，结果滤波器发散，回声反而变大了。后来加了条件判断，CPU占用降了20%，效果还更稳定。

内存管理：别让GC成为性能杀手

Android的GC（垃圾回收）是实时音频的大敌。一旦GC触发，音频线程可能被挂起几十毫秒，直接导致卡顿。我见过最夸张的一次，GC导致AEC输出爆音，用户投诉说“手机像在放鞭炮”。

1. 预分配内存：别在音频线程里new对象

这是铁律。音频处理线程里，绝对不要做任何内存分配操作。我的做法是：

• 初始化时一次性分配好所有缓冲区
• 使用对象池复用临时对象
• 用ByteBuffer.allocateDirect()分配原生内存

举个例子，滤波器系数、FFT缓冲区、延迟线这些，都在init()方法里分配好。运行时只做读写，不分配、不释放。

// 错误做法：每次处理都new数组
public void process(short[] input) {
    float[] temp = new float[256]; // 每次触发GC！
    // ...
}

// 正确做法：预分配
public class AecEngine {
    private float[] tempBuffer;
    
    public void init() {
        tempBuffer = new float[256]; // 只分配一次
    }
    
    public void process(short[] input) {
        // 复用tempBuffer
    }
}

2. 避免自动装箱

Java的自动装箱（int→Integer）会创建大量临时对象。在音频处理中，我建议：

• 所有计算都用基本类型（float、int、short）
• 集合类尽量用数组替代，或者用Android的SparseArray
• 回调接口用@Nullable标注，避免空指针

嗯，这里要注意，ArrayList<Float>这种写法在音频线程里就是灾难。我习惯用float[] + 手动管理长度。

3. 内存对齐：利用缓存行

现代CPU有缓存行（通常64字节）。如果数据跨缓存行，访问效率会下降。我的做法是：

• 把频繁访问的变量放在同一个结构体里
• 用@Contended注解避免伪共享（Java 8+）
• 数组长度尽量对齐到2的幂次

说实话，这个优化在Android上效果不如PC明显，但聊胜于无。我一般在最后调优阶段才做这个。

实时性保证：别让延迟毁了一切

AEC的实时性有两个维度：处理延迟和调度延迟。处理延迟是算法本身的计算时间，调度延迟是系统把任务分配给CPU的时间。两者加起来，必须小于音频帧的周期。

1. 音频线程优先级：抢到CPU时间片

Android的音频线程默认优先级不高。我建议：

• 使用android.os.Process.setThreadPriority()设置最高优先级
• 或者使用AudioTrack的回调线程，它自带高优先级
• 避免在音频线程里做同步操作（锁、等待）

我记得有一次，客户反馈AEC偶尔卡顿，查了半天发现是另一个线程在持有锁。音频线程等锁等了几毫秒，帧就丢了。后来改成无锁队列，问题解决。

2. 分帧处理：固定时间预算

每个音频帧的处理时间必须固定。我的做法是：

• 每帧大小固定（比如10ms，160个样本@16kHz）
• 处理时间控制在5ms以内（留50%余量）
• 如果超时，直接跳过当前帧的处理

这里有个技巧：用System.nanoTime()在每帧开始和结束时打点，如果耗时超过阈值，就记录一次“超时事件”。我一般会把这个指标暴露给上层，方便监控。

3. 双缓冲与流水线

为了进一步降低延迟，我建议用双缓冲：

• 一个缓冲区用于采集（写）
• 一个缓冲区用于处理（读）
• 两者交替，避免互斥

更高级的做法是三级流水线：采集→处理→输出，每个阶段独立线程。但说实话，在Android上搞多线程音频风险很大，我一般只在高端设备上才用。

知识体系总览

下面这张图，我把AEC性能优化的三个维度串起来了。你可以把它当作优化时的检查清单。

优化效果对比

最后，我整理了一份优化前后的对比数据。这是我在某款中端手机上实测的结果，供你参考。

指标	优化前	优化后	提升幅度
CPU占用（16kHz处理）	35%	8%	77%
每帧处理时间（10ms帧）	6.2ms	2.1ms	66%
GC触发频率（每分钟）	12次	0次	100%
最大调度延迟	15ms	3ms	80%
回声抑制比（ERLE）	28dB	26dB	-2dB（可接受）

看到没？优化后CPU占用降到了8%，每帧处理时间只有2.1ms，GC完全消失。唯一牺牲的是2dB的回声抑制比，但人耳基本听不出区别。这个交换，我觉得值。

好了，这一章的内容就到这里。记住，AEC的性能优化，说白了就是跟CPU、内存、时间赛跑。你跑赢了，用户就满意了。

---