NuPlayer的线程模型：一场精心编排的多线程协奏曲

做Android多媒体开发这些年，我见过太多因为线程问题导致的诡异bug。画面卡住、声音断续、甚至直接闪退——十有八九都是线程模型没搞对。Stagefright的NuPlayer，它的线程模型设计得相当精巧。说白了，它用一套消息队列机制，把多线程的复杂度封装得干干净净。

NuPlayer内部主要跑着三个线程：一个解码器线程、一个渲染线程、还有一个负责控制逻辑的线程。你想想看，这三个线程如果直接裸奔操作共享数据，那锁竞争得把人逼疯。所以NuPlayer引入了一个核心设计——消息驱动模型。

消息队列：线程间的“快递员”

每个线程都有自己的消息队列。线程A想通知线程B做某件事，不是直接调用B的方法，而是往B的消息队列里塞一条消息。B在自己的主循环里不断取消息、处理消息。这个模式的好处很明显：解耦。

我在项目中遇到过一个问题：解码器线程正在处理一个关键帧，渲染线程突然要跳转播放位置。如果直接调用解码器的方法，很可能导致解码器内部状态错乱。但用消息队列就不会——渲染线程只是发一条“请跳转到第X帧”的消息，解码器线程处理完当前任务后，再从容地处理这条消息。

// NuPlayer消息队列的核心结构
struct NuPlayer {
    sp<ALooper> mLooper;      // 主消息循环
    sp<AHandler> mDecoder;    // 解码器消息处理器
    sp<AHandler> mRenderer;   // 渲染器消息处理器
    
    // 发送消息的典型方式
    void postFlush() {
        // 注意：这里只是发消息，不会阻塞调用线程
        (new AMessage(kWhatFlush, mDecoder))->post();
    }
};

这段代码看起来简单，但背后藏着NuPlayer的精华。每个AHandler都绑定一个ALooper，ALooper内部维护一个消息队列。消息的发送和接收完全异步，调用方发完消息就返回，不会等对方处理完。

锁与同步机制：该锁的时候别手软

消息队列解决了大部分线程通信问题，但有些场景还是得用锁。比如多个线程同时访问同一个播放状态变量——播放、暂停、停止这些状态切换，必须保证原子性。

NuPlayer的锁设计有个特点：尽量缩小锁的粒度。我见过一些项目，一把大锁锁住整个播放器，结果性能惨不忍睹。NuPlayer的做法是：把共享数据拆成小块，每块用独立的锁保护。

// NuPlayer中的锁使用示例
class NuPlayer {
    Mutex mLock;  // 保护状态变量
    PlayerState mState;
    
    status_t setPlaybackState(PlayerState newState) {
        Mutex::Autolock autoLock(mLock);
        // 检查状态转换是否合法
        if (!isValidTransition(mState, newState)) {
            return INVALID_OPERATION;
        }
        mState = newState;
        return OK;
    }
};

这里用了Mutex::Autolock，这是Android的RAII风格锁。进入作用域自动加锁，离开作用域自动解锁。我建议你也养成这个习惯——手动加锁解锁太容易出错了，我曾经就因为忘记解锁导致死锁，查了两天才找到问题。

条件变量：让线程学会“等待”

有些场景需要线程等待某个条件成立。比如渲染线程要等解码器产出足够的数据才能开始渲染。轮询？太浪费CPU。休眠固定时间？响应不及时。NuPlayer的做法是用Condition条件变量。

// 条件变量使用模式
status_t NuPlayer::waitForDecodedFrame() {
    Mutex::Autolock autoLock(mLock);
    while (mDecodedFrames.empty()) {
        // 没有解码好的帧，线程进入休眠
        mFrameAvailableCondition.wait(mLock);
    }
    // 醒来后，取出帧数据
    return mDecodedFrames.pop();
}

void NuPlayer::onFrameDecoded(const sp<ABuffer> &frame) {
    Mutex::Autolock autoLock(mLock);
    mDecodedFrames.push(frame);
    // 唤醒等待的线程
    mFrameAvailableCondition.signal();
}

这个模式很经典：先检查条件，不满足就等待，条件满足时被唤醒。注意while循环而不是if——这是为了防止“虚假唤醒”。嗯，这里要注意，条件变量的wait()可能被意外唤醒，所以必须用while重新检查条件。

避坑指南：我曾经踩过的坑

我曾经在项目中犯过一个低级错误：在消息处理函数里直接调用了wait()阻塞等待。结果呢？消息队列被卡住了，其他消息都处理不了，整个播放器直接僵死。后来我意识到：消息处理函数里绝对不能做阻塞操作。如果必须等待，应该把等待逻辑拆成状态机，用消息驱动状态流转。

另一个常见坑是：发送消息时传递了野指针。NuPlayer的消息系统是异步的，消息可能在发送者销毁后才被处理。如果你传递了一个指向局部变量的指针，那消息处理时这个指针已经失效了。解决方案是：要么传递值类型，要么用sp<>智能指针管理生命周期。

NuPlayer线程模型全景图

下面这张图展示了NuPlayer的线程模型和消息流转路径。我画这张图时特意把消息队列放在中间，因为它是整个架构的“中枢神经”。

从这张图你能看到：三个线程各自独立运行，通过消息队列进行通信。共享数据被锁保护，只有持有锁的线程才能访问。这种设计让每个线程的职责非常清晰，也方便我们做问题定位——哪个线程出了问题，直接看它的消息处理逻辑就行。

总结一下关键点

• 消息队列是核心：NuPlayer用消息队列解耦线程间通信，避免直接调用带来的锁竞争和状态混乱。
• 锁要小、要短：必须用锁的地方，尽量缩小保护范围，减少锁持有时间。
• 条件变量配合锁使用：等待/通知模式用条件变量实现，记得用while循环防止虚假唤醒。
• 消息处理函数不要阻塞：这是新手最容易犯的错误，阻塞消息队列等于杀死播放器。

嗯，NuPlayer的线程模型就聊到这里。这套设计经受住了Android数亿设备的考验，值得我们好好消化。下一节我们会深入消息队列的具体实现，看看ALooper和AHandler到底是怎么工作的。