第18章音频线程模型

课程目录第18章音频线程模型

18、音频线程模型：Android音频线程架构、Callback线程与UI线程隔离、避免线程阻塞与优先级设置

聊到音频低延时，线程模型是个绕不开的话题。我见过不少开发者，算法写得挺漂亮，但一跑起来就卡顿、爆音，最后查下来，问题往往出在线程调度上。说白了，音频线程就像一条高速公路，你让它在高峰期去等红绿灯，那肯定堵车。

这一章，我们就来拆解Android音频线程的底层逻辑，看看Callback线程和UI线程到底该怎么相处，以及怎么避免线程阻塞、怎么设置优先级。嗯，这些经验，很多是我在项目里踩坑踩出来的。

Android音频线程架构：谁在干活？

先搞清楚一件事：音频数据从App到硬件，中间经过了好几个线程。它们各司其职，但一旦配合不好，延时就上去了。

我习惯把Android音频线程分成三层：

应用层线程：你写的播放器、录音器，跑在App的主线程或你创建的工作线程里。
AudioFlinger线程：系统服务层的核心线程，负责混音、路由、数据搬运。
ALSA / HAL层线程：直接跟硬件打交道，驱动级的线程，延时最低。

这三层之间通过共享内存或Binder通信。数据从应用层到HAL层，每经过一层，都会引入一次线程切换和缓冲区拷贝。你想想看，如果每一层都多等一个buffer的时间，累积下来延时就很可观了。

核心观点：低延时的本质，就是减少线程切换次数，缩短数据在每一层的停留时间。

下面这张图，是我自己整理的Android音频线程数据流，你可以直观地看到数据是怎么“跑”的。

Callback线程与UI线程隔离：别让主线程拖后腿

很多新手会犯一个错误：直接在UI线程里处理音频数据。比如在onClick里调用AudioTrack.write()。这其实很危险。UI线程要处理布局、触摸事件、动画，一旦卡顿，音频就会断流。

我个人习惯是：音频回调线程和UI线程必须物理隔离。什么意思？就是音频的读写、处理，全部放在独立的、专有的线程里，绝不跟UI线程混用。

我的经验：在项目里，我见过一个案例，开发者在onProgressChanged里更新音频播放位置，结果SeekBar拖动时音频一卡一卡的。后来把音频控制逻辑移到独立线程，用Handler发消息，问题就解决了。

具体怎么做？我推荐两种方式：

使用HandlerThread：创建一个专用于音频的HandlerThread，所有音频操作通过Handler发到该线程执行。
使用AAudio的callback模式：AAudio的callback直接跑在音频服务端的高优先级线程上，天然与UI线程隔离。

下面是一个简单的HandlerThread隔离示例：

// 创建音频专用线程
HandlerThread audioThread = new HandlerThread("AudioWorker");
audioThread.start();
Handler audioHandler = new Handler(audioThread.getLooper());

// 在UI线程中触发播放
public void onPlayButtonClicked() {
    audioHandler.post(() -> {
        // 这里跑在音频线程，不会阻塞UI
        audioTrack.write(buffer, 0, buffer.length);
    });
}

你看，这样UI线程只负责发消息，实际的音频操作在另一个线程里完成。哪怕音频线程卡了，UI还能响应触摸事件，不至于ANR。

避免线程阻塞：音频线程的“红灯”不能等

音频线程最怕什么？阻塞。一旦线程被挂起，buffer就会欠载，爆音就来了。

我遇到过最典型的场景：有人在音频回调里做了网络请求，或者写了日志文件。结果网络延迟一高，音频直接断断续续。嗯，这其实是个很常见的坑。

警告：在音频回调线程中，绝对不要做以下操作：

网络I/O（HTTP请求、Socket读写）
文件I/O（写日志、读配置文件）
锁竞争（synchronized、Lock）
内存分配（new对象、字符串拼接）
长时间计算（超过一个buffer周期）

为什么会这样？因为音频回调的周期很短。比如采样率48000Hz、buffer大小192帧，那么每个回调只有4ms的时间。你想想看，4ms里你要完成数据拷贝、格式转换，还要去等网络？根本来不及。

那如果确实需要做耗时操作怎么办？我的做法是：在回调里只做最轻量的数据搬运，把复杂处理放到另一个工作线程。比如用环形缓冲区（Ring Buffer）做生产者-消费者模式。

// 伪代码：回调中只做入队
void onAudioCallback(AudioBuffer* buffer) {
    ringBuffer.push(buffer);  // 轻量操作，无锁或自旋锁
}

// 工作线程：从ringBuffer取出数据做处理
void workerThreadLoop() {
    while (running) {
        AudioBuffer* buf = ringBuffer.pop();
        processAudio(buf);  // 可以放心做耗时操作
    }
}

这样既保证了回调的实时性，又不会丢失数据。我在一个实时变声项目里就是这么做的，效果很好。

优先级设置：给音频线程“插队”的权利

Android系统里线程有优先级之分。普通线程的优先级是0，音频回调线程的优先级通常是-16或-19（实时优先级）。这意味着当CPU资源紧张时，系统会优先调度音频线程。

但有个问题：如果你自己创建的工作线程优先级太低，可能会被其他后台任务抢占，导致音频处理延迟。所以我建议：音频相关的工作线程，也要适当提高优先级。

在AAudio中，callback线程的优先级由系统自动设置，你不需要手动干预。但如果你用AudioTrack配合HandlerThread，可以这样设置：

HandlerThread audioThread = new HandlerThread("AudioWorker", 
    Process.THREAD_PRIORITY_URGENT_AUDIO);
audioThread.start();

THREAD_PRIORITY_URGENT_AUDIO的值是-19，属于实时优先级。这样你的音频工作线程就能跟系统音频服务平起平坐，不会被普通任务打断。

注意：实时优先级是一把双刃剑。设置太高可能导致其他线程饿死，甚至影响系统稳定性。我建议只在音频处理的核心线程上使用，其他辅助线程保持默认优先级即可。

另外，我记得在Android 8.0之后，系统对实时线程的权限做了限制。普通App不能随意设置-19优先级，需要申请android.permission.RECEIVE_BOOT_COMPLETED或者通过MediaCodec/AAudio的callback间接获得。这点要注意，否则你设置了也没效果。

总结一下

音频线程模型的核心，说白了就是三件事：

隔离：音频线程和UI线程必须分开，别让UI卡顿影响音频。
不阻塞：音频回调里只做轻量操作，耗时任务交给工作线程。
提优先级：给音频线程实时优先级，确保它被优先调度。

这些原则看起来简单，但真正落地时，每个细节都可能踩坑。我建议你在写代码时，多想想“这个操作会不会让音频线程等太久？”——如果答案是“会”，那就换个方式做。

好了，这一章就到这里。下一章我们会聊更具体的buffer管理与延时控制，到时候见。

📚 课程目录

18、音频线程模型：Android音频线程架构、Callback线程与UI线程隔离、避免线程阻塞与优先级设置

Android音频线程架构：谁在干活？

Callback线程与UI线程隔离：别让主线程拖后腿

避免线程阻塞：音频线程的“红灯”不能等

优先级设置：给音频线程“插队”的权利

总结一下