19、内存与缓存优化：避免内存抖动、使用DirectBuffer与共享内存、音频数据的零拷贝技术

音频低延时优化，说白了就是跟数据搬运赛跑。你想想看，音频数据从录音到播放，中间要经过多少层？应用层、框架层、HAL层、内核驱动……每一层都在拷贝数据。我刚开始做低延时项目时，总觉得算法优化到位就行了，结果发现延时死活降不下来。后来一查，好家伙，光是内存拷贝就占了将近一半的耗时。

这一章，我们就来聊聊怎么把内存这块的坑填平。

19.1 内存抖动：音频线程的隐形杀手

内存抖动，就是频繁地分配和释放内存。在音频线程里，这简直是灾难。为什么？因为GC（垃圾回收）一旦触发，整个线程都得停下来等。你想想，一个8ms的音频buffer，GC一停就是几十毫秒，那声音不卡顿才怪。

我个人习惯，在音频处理线程里绝对禁止动态分配内存。所有buffer都在初始化时一次性申请好，后面只复用，不释放。

核心原则：音频回调线程中，不要new任何对象，不要触发任何GC。

我曾经在一个项目里遇到过，播放器偶尔出现“啪”的一声爆音。查了三天，最后发现是某个日志打印里偷偷new了一个String对象，触发了GC。从那以后，我定了个规矩：音频线程里连Log.d都要慎用。

19.1.1 对象池模式

如果实在需要临时对象，用对象池。比如ByteBuffer池、Float数组池。提前分配好一批，用的时候取，用完归还。

public class AudioBufferPool {
    private final ConcurrentLinkedQueue<ByteBuffer> pool = new ConcurrentLinkedQueue<>();
    private final int bufferSize;

    public AudioBufferPool(int count, int bufferSize) {
        this.bufferSize = bufferSize;
        for (int i = 0; i < count; i++) {
            pool.offer(ByteBuffer.allocateDirect(bufferSize));
        }
    }

    public ByteBuffer acquire() {
        ByteBuffer buf = pool.poll();
        if (buf == null) {
            // 极端情况，但尽量避免
            buf = ByteBuffer.allocateDirect(bufferSize);
        }
        buf.clear();
        return buf;
    }

    public void release(ByteBuffer buf) {
        pool.offer(buf);
    }
}

嗯，这里要注意：池子的大小要合理。太小了不够用，太大了浪费内存。我一般按音频通道数×2来算，比如双通道就准备4个buffer。

19.2 DirectBuffer：绕过JVM堆的直通车

Java层的ByteBuffer有两种：HeapByteBuffer和DirectByteBuffer。HeapByteBuffer的数据在JVM堆里，跟底层交互时，JVM得先把数据拷贝到native堆，再传给驱动。这一来一回，多了一次拷贝。

DirectByteBuffer呢？数据直接分配在native堆上，JVM堆只是个“壳”。底层驱动可以直接读写这块内存，省掉了中间拷贝。

我的建议：音频数据缓冲区，一律用ByteBuffer.allocateDirect()。虽然分配成本高一点，但运行时效率高得多。

我记得有一次优化一个USB音频设备，用HeapByteBuffer时，每次读写都有明显的延迟抖动。换成DirectBuffer后，延迟直接降了30%。

19.2.1 使用示例

// 错误示范：HeapByteBuffer
ByteBuffer heapBuf = ByteBuffer.allocate(4096);
// 底层读写时，JVM会做一次堆内到堆外的拷贝

// 正确做法：DirectByteBuffer
ByteBuffer directBuf = ByteBuffer.allocateDirect(4096);
// 底层直接操作native内存，零拷贝

19.3 共享内存：跨进程的零拷贝通道

Android音频架构里，应用进程和AudioFlinger服务进程是分开的。传统方式传数据，得用Binder，Binder内部会做一次内存拷贝。对于大块音频数据，这个开销不小。

共享内存（ashmem / MemFd）可以解决这个问题。两个进程映射同一块物理内存，数据写进去，对方直接读，不需要拷贝。

关键点：共享内存 + 文件描述符传递，是实现跨进程零拷贝的标准做法。

AudioFlinger内部其实就在用共享内存。应用层通过AudioTrack写数据时，数据直接写到共享内存里，AudioFlinger从同一块内存读出来混音。整个过程没有一次数据拷贝。

19.3.1 实现思路

// 服务端：创建共享内存
MemoryHeapBase heap(4096);
sp<IMemory> memory = new MemoryBase(heap, 0, 4096);
// 通过Binder把文件描述符传给客户端

// 客户端：映射共享内存
sp<IMemory> memory = ...; // 从Binder获取
void* data = memory->pointer();
// 直接读写data指针，无需拷贝

当然，应用层直接操作共享内存的场景不多。但如果你在开发自己的音频引擎，或者做低延时VoIP，这个技术非常有用。

19.4 零拷贝技术：从源头消灭数据搬运

零拷贝，不是说真的不拷贝，而是尽量减少CPU参与的数据搬运。在音频领域，主要有几个层面：

  • 应用层到框架层：用DirectBuffer + 共享内存
  • 框架层到HAL层：用DMA（直接内存访问）
  • HAL层到驱动层：用mmap映射

Android从8.0开始引入了AAudio，它的核心就是mmap。AAudio把音频数据缓冲区直接映射到应用进程，应用写数据就是写硬件缓冲区，延时可以做到5ms以内。

注意：零拷贝不是银弹。它需要硬件支持，而且内存管理更复杂。如果使用不当，反而可能引入数据竞争或内存泄漏。

我曾经在一个项目里，为了追求极致延时，强行用mmap绕过AudioFlinger。结果发现，某些设备上mmap的缓冲区刷新不及时，导致声音断断续续。后来还是老老实实用了AAudio的共享内存模式。

19.5 知识体系总览

下面这张图，把内存与缓存优化的核心脉络梳理了一下。你可以看到，从内存抖动到零拷贝，其实是一条“减少不必要操作”的优化链。

内存与缓存优化知识体系 内存与缓存优化 内存抖动 DirectBuffer 共享内存 零拷贝技术 避免GC触发 对象池模式 绕过JVM堆 allocateDirect 跨进程通信 MemFd传递 DMA传输 mmap映射 AAudio框架 目标：减少CPU参与的数据搬运，降低延时

19.6 实战避坑指南

说了这么多理论，最后分享几个我踩过的坑：

  1. DirectBuffer别频繁分配：allocateDirect本身开销不小，最好在初始化时一次性分配好，后面复用。
  2. 共享内存注意同步：两个进程读写同一块内存，一定要用原子操作或信号量做同步。我见过有人直接用volatile，结果数据错乱。
  3. mmap的page对齐：映射大小必须是内存页的整数倍（通常是4KB）。不对齐的话，映射会失败或者多映射一些无用区域。
  4. 对象池要预热：刚启动时，先往池子里塞满对象，避免运行时临时分配。
一个小技巧：用Perfetto抓trace，看音频线程里有没有GC的标记。如果有，说明内存分配没控制好。这是排查内存抖动最直接的方法。

好了，这一章的内容就到这里。内存优化是个细活，每个微秒的节省，最终都会体现在用户的听觉体验上。下一章，我们会聊聊更底层的调度优化，敬请期待。

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

← 上一章 📖 返回目录 下一章 →