30、项目实战：从零搭建一个完整的Android AEC SDK

终于到了最后一章。说实话，写到这里我还有点不舍。

前面29章，我们把AEC的原理、算法、调优、测试讲了个遍。但我知道，很多人心里一直有个疑问：这些东西到底怎么拼成一个真正的SDK？

嗯，今天我们就来解决这个问题。

从零搭建一个完整的Android AEC SDK，说白了就是把你学到的所有知识，封装成一个别人能直接调用的库。我当年第一次做这件事时，踩了不少坑——有的坑现在想起来还觉得好笑。今天我把这些经验都摊开来讲。

30.1 SDK的整体架构设计

一个合格的AEC SDK，至少需要包含三层：

• 算法核心层：负责真正的回声消除处理
• 音频管理层：负责录音、播放、数据路由
• 应用接口层：负责暴露给上层调用的API

我个人习惯把这三层拆成独立的模块。为什么？因为这样好测试。你想想看，如果算法和音频管理混在一起，出了问题你根本分不清是算法bug还是音频采集的锅。

下面这张图是我当时设计的架构，你可以参考一下：

30.2 算法核心层的实现

这一层是整个SDK的心脏。我把它设计成一个纯C++的库，通过JNI暴露给Java层。

为什么用C++？因为音频处理对实时性要求极高。Java的GC暂停会要了你的命——我在项目里就吃过这个亏，后来全部重写成了native代码。

核心接口就三个：

// aec_engine.h
class AecEngine {
public:
    // 初始化，传入采样率、帧长、滤波器阶数
    int init(int sampleRate, int frameSize, int filterLength);
    
    // 处理一帧数据
    // nearBuf: 近端信号（麦克风输入）
    // farBuf:  远端信号（扬声器参考）
    // outBuf:  输出信号（回声消除后）
    int process(short* nearBuf, short* farBuf, short* outBuf, int len);
    
    // 释放资源
    int release();
};

这里有个细节我想强调一下：farBuf必须是扬声器实际播放的数据，而不是播放文件的原始数据。我见过有人直接把音频文件的数据当参考信号传进来，结果回声根本消不掉——因为经过系统混音、音量调节后，实际播放的信号已经变了。

30.3 音频管理层的实现

这一层负责两件事：采集近端信号和获取远端参考信号。

Android的音频架构有点特殊。录音和播放跑在不同的线程上，而且延迟不稳定。我当时的做法是：

• 用两个独立的线程分别管理录音和播放
• 中间用环形缓冲区做数据中转
• 每处理完一帧，就计算一次延迟偏移

代码结构大概是这样的：

// AudioManager.java
public class AudioManager {
    private AudioRecord recorder;
    private AudioTrack track;
    private CircularBuffer nearBuffer;
    private CircularBuffer farBuffer;
    
    public void startCapture() {
        // 启动录音线程
        new Thread(() -> {
            while (isRunning) {
                recorder.read(nearBuf, 0, FRAME_SIZE);
                nearBuffer.write(nearBuf);
                // 触发AEC处理
                processAec();
            }
        }).start();
    }
    
    public void startPlayback() {
        // 启动播放线程
        new Thread(() -> {
            while (isRunning) {
                track.write(farBuf, 0, FRAME_SIZE);
                farBuffer.write(farBuf);  // 截取参考信号
            }
        }).start();
    }
}

30.4 应用接口层的设计

这一层是给App开发者用的。我的设计原则是：接口越简单越好。

最终暴露的API只有四个：

方法	说明
init(config)	初始化SDK，传入配置参数
start()	启动回声消除
stop()	停止回声消除
release()	释放所有资源

配置参数我封装成了一个Config类：

public class AecConfig {
    public int sampleRate = 16000;      // 采样率
    public int frameSize = 160;         // 帧长（10ms）
    public int filterLength = 512;      // 滤波器阶数
    public boolean enableNlp = true;    // 是否启用非线性处理
    public boolean enableComfortNoise = true; // 是否启用舒适噪声
}

你可能会问：为什么不做成自动检测？嗯，我试过。但不同手机的硬件差异太大，自动检测的准确率只有70%左右。与其让用户面对不可控的结果，不如把选择权交给他们。

30.5 延迟测量与动态补偿

这是整个SDK里最容易被忽视、但影响最大的部分。

Android系统的音频延迟不是固定的。不同的手机、不同的系统版本、甚至不同的负载下，延迟都会变。如果不做动态补偿，你的AEC算法永远对不齐参考信号。

我的做法是：

1. 在初始化时，播放一段已知的测试信号，同时录音
2. 通过互相关计算找到延迟峰值
3. 运行时每隔一段时间重新校准一次

代码实现：

// DelayEstimator.java
public class DelayEstimator {
    private int estimatedDelay = 0;
    
    public int estimate(short[] near, short[] far, int sampleRate) {
        // 互相关计算
        int maxCorr = 0;
        int bestDelay = 0;
        for (int d = 0; d < MAX_DELAY; d++) {
            int corr = 0;
            for (int i = 0; i < near.length - d; i++) {
                corr += near[i + d] * far[i];
            }
            if (corr > maxCorr) {
                maxCorr = corr;
                bestDelay = d;
            }
        }
        return bestDelay;
    }
}

30.6 性能优化与内存管理

移动端的内存和CPU都是稀缺资源。AEC算法本身计算量就不小，如果再不加优化，很容易导致卡顿。

我总结了几条优化经验：

• 避免频繁的内存分配：在初始化时一次性分配好所有缓冲区，运行时复用
• 使用定点数运算：浮点运算在ARM上比定点慢3-5倍
• 减少JNI调用次数：每次JNI调用都有开销，尽量把多帧数据打包一起处理
• 线程优先级：把音频处理线程设为THREAD_PRIORITY_URGENT_AUDIO

举个例子，内存分配这块：

// 错误做法：每次处理都new数组
public void process(short[] near, short[] far) {
    short[] out = new short[FRAME_SIZE];  // 每次分配，GC压力大
    nativeProcess(near, far, out);
}

// 正确做法：复用缓冲区
private short[] outBuffer = new short[FRAME_SIZE];
public void process(short[] near, short[] far) {
    nativeProcess(near, far, outBuffer);  // 复用
}

30.7 测试与验证

SDK写完了，怎么验证它好不好用？

我一般分三步走：

1. 单元测试：用已知的测试向量验证算法正确性
2. 模拟测试：在PC上模拟Android音频链路，测试延迟补偿
3. 真机测试：至少覆盖10款主流机型，包括不同芯片平台的

真机测试时，我习惯录一段双讲对话，然后对比处理前后的频谱图。如果残留回声在-40dB以下，基本就合格了。

30.8 总结

从零搭建一个完整的AEC SDK，说难不难，说简单也不简单。核心就是三件事：架构清晰、延迟对齐、性能优化。

我当年做第一个版本时，花了大概三周。但后来迭代优化，又花了两个月。所以如果你一次没做好，别灰心——这很正常。

好了，30章的内容到这里就全部结束了。感谢你一路看到这里。如果你在搭建SDK的过程中遇到什么问题，欢迎随时交流。

---

公众号:蓝海资料掘金营，微信deep3321