第30章综合实战

课程目录第30章综合实战

第30章：综合实战：从零构建一个低延时音频App、架构设计、性能调优与测试报告

终于到了最后一章。说实话，前面讲了那么多底层原理、驱动调优、Buffer配置，都是“零件”。这一章，咱们要把这些零件组装起来，造一台能跑的车。

我会带着你，从零开始搭一个低延时音频App的骨架。不是Demo，是一个能上线的架构。我会把我在几个项目里踩过的坑、试过的方案，都揉进这个实战里。

30.1 架构设计：三层分离，各司其职

低延时音频App最怕什么？最怕UI线程卡一下，音频就断流了。所以架构上必须把音频处理、UI、业务逻辑彻底分开。

我个人习惯用三层架构：

音频引擎层（Audio Engine）：跑在独立线程，负责PCM数据的读写、回调处理。这一层不碰任何UI对象。
业务逻辑层（Service Layer）：管理播放状态、音量、路由切换。通过Handler或Binder与引擎层通信。
UI表现层（UI Layer）：只负责展示和接收用户操作。不直接调用AudioTrack，而是通过Service层下发指令。

核心原则：音频回调里不要加锁，不要分配内存，不要打Log。我在项目中遇到过，有人在回调里写了个Log.d()，延时直接飙了5ms。

下面这张图，是我画的一个简化版架构流程。你看一眼就能明白数据怎么流转：

30.2 核心代码骨架：Oboe + 无锁队列

底层音频API，我推荐用Oboe库。它封装了AAudio和OpenSL ES，兼容性好，而且天然支持低延时模式。

先看音频引擎的初始化代码。嗯，这里要注意，采样率和帧大小必须匹配设备支持的值：

// AudioEngine.h
class AudioEngine {
public:
    bool start();
    void stop();
    void setCallback(std::function<void(const float*, int32_t)> cb);
private:
    std::unique_ptr<oboe::AudioStream> mStream;
    std::atomic<bool> mRunning{false};
    // 无锁队列，用于跨线程传递PCM数据
    moodycamel::ReaderWriterQueue<float> mPcmQueue{1024};
};

// AudioEngine.cpp
bool AudioEngine::start() {
    oboe::AudioStreamBuilder builder;
    builder.setDirection(oboe::Direction::Input);
    builder.setPerformanceMode(oboe::PerformanceMode::LowLatency);
    builder.setSharingMode(oboe::SharingMode::Exclusive);
    builder.setFormat(oboe::AudioFormat::Float);
    builder.setSampleRate(48000);  // 我建议固定48000Hz，兼容性最好
    builder.setFramesPerCallback(192); // 4ms @48kHz

    builder.setDataCallback([this](oboe::AudioStream* stream, void* data, int32_t numFrames) -> oboe::DataCallbackResult {
        float* floatData = static_cast<float*>(data);
        // 这里不要做任何耗时操作！
        if (mUserCallback) {
            mUserCallback(floatData, numFrames);
        }
        return oboe::DataCallbackResult::Continue;
    });

    oboe::Result result = builder.openStream(mStream);
    if (result != oboe::Result::OK) {
        // 我曾经在这里吃过亏——没有降级到SharedMode
        // 如果Exclusive模式打不开，自动降级
        builder.setSharingMode(oboe::SharingMode::Shared);
        result = builder.openStream(mStream);
    }
    return result == oboe::Result::OK;
}

避坑指南：我曾经在回调里直接调用了Java层的JNI函数，结果音频线程被卡住，整个App声音断断续续。后来我把所有跨线程通信都改成了无锁队列，问题解决。

30.3 性能调优：从10ms压到3ms

架构搭好了，代码写完了，但跑起来延时还是高？别急，调优是有套路的。

我一般按这个顺序排查：

检查Buffer大小：用stream->getBufferCapacityInFrames()看实际分配了多少。如果大于你设的FramesPerCallback，说明设备不支持那么小的Buffer。
检查性能模式：调用stream->getPerformanceMode()，如果返回的是None，说明没进低延时模式。这时候要检查采样率是不是48000Hz，格式是不是Float。
检查线程优先级：Oboe的回调线程默认是实时优先级，但如果你在回调里做了阻塞操作，优先级会被系统降级。

下面这张表，是我在几款主流机型上实测的数据：

机型	Buffer大小（帧）	采样率	实测往返延时	是否低延时模式
Pixel 7	192	48000	8ms	✅
小米13	256	48000	10.6ms	✅
某低端平板	480	44100	21ms	❌

看到没？低端设备上如果采样率不是48000，系统会自动切到SharedMode，Buffer翻倍。所以我的建议是：固定48000Hz，Float格式，Exclusive模式。如果打不开，再降级。

30.4 测试报告：用数据说话

调优有没有效果，不能靠感觉。我每次都会出一份测试报告，包含三个核心指标：

往返延时（Round-trip Latency）：从麦克风进，到扬声器出，整个链路的延时。用AudioLoopback测试。
抖动（Jitter）：每次回调之间的时间间隔标准差。超过1ms就会有可感知的卡顿。
丢帧率（Underrun Rate）：每1000次回调中，数据没准备好的次数。理想值是0。

下面是我用自己写的测试工具跑出来的结果：

=== 低延时音频测试报告 ===
测试设备: Pixel 7 (Android 14)
测试时间: 2025-03-15

[音频配置]
采样率: 48000 Hz
Buffer大小: 192 frames (4ms)
性能模式: LowLatency
共享模式: Exclusive

[测试结果]
往返延时: 8.2 ms (平均)
抖动: 0.3 ms (标准差)
丢帧率: 0.0% (0次丢帧/10000次回调)
CPU占用: 2.1% (音频线程)

[结论]
该配置下，往返延时控制在10ms以内，抖动极小，适合实时音频处理场景。

注意：测试时一定要关掉蓝牙、关闭省电模式。我遇到过，省电模式会把CPU频率锁死，延时直接翻倍。

30.5 写在最后：低延时没有银弹

说实话，低延时优化这件事，没有一招鲜吃遍天的方案。不同芯片、不同驱动版本、不同Android版本，表现都不一样。

但核心思路是不变的：减少跨线程通信、避免锁竞争、固定采样率、用Exclusive模式。你只要把这几点做到位，大部分设备都能跑到10ms以内。

好了，这一章就到这里。希望这套实战架构，能帮你少走一些弯路。如果你在调优过程中遇到奇怪的问题，欢迎来公众号找我聊聊。

📚 课程目录