一、背景痛点分析

在Android音频开发中，原生AudioRecord常遇到三个典型问题：

• 采样率漂移：硬件时钟差异导致48kHz采样时出现47.8kHz等偏差
• 内存泄漏陷阱：连续采集时short[]数组未及时释放引发OOM
• 线程阻塞：read()同步调用导致UI卡顿

二、技术方案对比

| 方案 | 延迟(ms) | CPU占用 | 兼容性 | |---------------|---------|--------|----------| | AudioRecord | 20-100 | 中 | API>=16 | | OpenSL ES | 10-50 | 低 | API>=21 | | tinycap | 5-30 | 极低 | 需root |

关键结论：对延迟敏感型应用（如语音唤醒），tinycap+ALSA驱动是终极方案。

三、tinycap实战指南

3.1 编译与集成

1. 下载Android NDK交叉编译工具链
2. 修改tinycap.c源码：

   // 增加采样精度校验
   if (format != AUDIO_FORMAT_PCM_16_BIT) {
       ALOGE("Only 16-bit PCM supported");
       return -1;
   }

3. 编写Android.mk：

   LOCAL_MODULE    := tinycap
   LOCAL_SRC_FILES := tinycap.c
   LOCAL_LDLIBS    := -llog

3.2 环形缓冲区实现

class PCMRingBuffer {
public:
    PCMRingBuffer(int size) : 
        mBuffer(new short[size]), mSize(size) {}

    void write(const short* data, int len) {
        std::lock_guard<std::mutex> lock(mMutex);
        int remaining = std::min(len, mSize - mPos);
        memcpy(mBuffer.get() + mPos, data, remaining * sizeof(short));
        if (remaining < len) {
            memcpy(mBuffer.get(), data + remaining, (len - remaining) * sizeof(short));
            mPos = len - remaining;
        } else {
            mPos += remaining;
        }
    }

private:
    std::unique_ptr<short[]> mBuffer;
    std::mutex mMutex;
    int mPos = 0;
    int mSize;
};

3.3 JNI优化技巧

1. 避免频繁回调：积累100ms数据后通过CallVoidMethod批量回调
2. 直接缓冲区模式：

   // Java层声明
   public native void setDirectBuffer(ByteBuffer buffer);

四、性能实测数据

| 采样率(kHz) | AudioRecord CPU% | tinycap CPU% | |-------------|-----------------|-------------| | 16 | 12 | 3 | | 44.1 | 28 | 7 | | 48 | 35 | 9 |

延迟测试方法：

1. 连接示波器信号发生器
2. 记录输入脉冲到首帧数据的时间差
3. 重复100次取90分位值

五、避坑指南

权限管理： - /dev/snd/设备需要root读写权限 - 动态申请RECORD_AUDIO权限仍为必须

采样对齐：

// 确保每次读取的采样数是帧大小的整数倍
#define FRAME_SIZE 256
read_size = (read_size / FRAME_SIZE) * FRAME_SIZE;

异常恢复： 1. 检测ALSA驱动崩溃：ioctl返回-EPIPE 2. 重新初始化整个音频链路 3. 保留最后50ms数据做平滑过渡

延伸思考

1. 如何实现双通道数据分离存储为左右声道独立文件？
2. 在非root设备上如何实现类似tinycap的低延迟方案？
3. 当采样率不稳定时，怎样动态调整重采样参数？