3. 主线程架构
好，咱们今天聊聊渲染进程里最核心的“大脑”——主线程。
很多人觉得主线程就是个死循环，不断拿任务、执行任务。嗯，这么说也没错，但实际工程里远没那么简单。我做过几个渲染引擎后，最大的感受是：主线程架构设计得好不好，直接决定了你的渲染器是“丝滑”还是“卡成PPT”。
3.1 任务循环机制：别小看那个“while”
先看最基础的骨架。一个渲染主线程，本质上就是这样一个循环：
while (!shouldExit) {
Task task = taskQueue.pop(); // 从队列拿任务
if (task.isValid()) {
task.execute(); // 执行
}
// 可能还要处理空闲回调
}
是不是很简单？但坑全在细节里。
我个人习惯把任务循环分成三个阶段：
- 取任务阶段：从队列头部拿一个待办项
- 执行阶段：运行任务逻辑
- 收尾阶段：检查是否有紧急信号、处理空闲任务
我在项目中遇到过一个问题：某个任务执行时间过长，导致后续所有任务排队等待。用户操作没反应，界面卡死。后来我们加了个任务执行时间预算——每个任务最多跑几毫秒，超时就打断，放到下一帧继续。
3.2 消息队列与事件循环：谁给主线程“投喂”任务？
任务从哪来？说白了，就是各种“消息”和“事件”。
消息队列是个典型的生产者-消费者模型：
- 生产者：其他线程（比如网络线程、IO线程）、系统窗口消息、定时器、用户输入
- 消费者：主线程的任务循环
你想想看，如果多个生产者同时往队列里塞任务，不加锁会怎样？数据错乱、崩溃。加锁太粗又会怎样？性能下降。
我建议的做法是：使用无锁队列（lock-free queue），或者用细粒度的读写锁。具体选哪种，取决于你的任务量和并发度。
事件循环这块，有个经典模型叫“Reactor模式”。主线程注册自己感兴趣的事件（比如“窗口需要重绘”、“网络数据到达”），然后事件循环负责监听并分发。
// 伪代码：事件循环注册
eventLoop.register(WindowEvent::Paint, onPaint);
eventLoop.register(TimerEvent::FrameTick, onFrameTick);
eventLoop.run(); // 开始循环
这里有个小技巧：把高频事件和低频事件分开处理。比如帧更新是每16ms一次，但用户点击可能几秒才一次。混在一起容易让低频事件被饿死。
3.3 任务优先级调度：别让“急事”排队
所有任务都平等？不可能。
渲染引擎里，任务的紧急程度天差地别：
| 优先级 | 任务类型 | 举例 |
|---|---|---|
| 最高 | 用户交互响应 | 点击、触摸、键盘输入 |
| 高 | 帧同步任务 | VSync回调、提交渲染命令 |
| 中 | 常规渲染更新 | 场景图更新、动画计算 |
| 低 | 后台加载、GC | 纹理流送、内存回收 |
我常用的调度策略是多级反馈队列：
- 高优先级队列：每次循环优先检查，有任务就立刻执行
- 中优先级队列：高优队列空了才处理
- 低优先级队列：只有前两个都空了，才轮到它
但这里有个陷阱：低优先级任务可能永远得不到执行。如果高优任务源源不断，低优任务就会“饿死”。
解决办法？我一般加个老化机制——每个任务等待超过一定时间，自动提升优先级。这样既保证了紧急任务优先，又不会让后台任务永远排不上。
3.4 实战中的避坑指南
最后分享几个我踩过的坑：
- 任务拆分粒度要适中：太细了，调度开销大；太粗了，卡顿明显。我一般控制在1-3ms一个任务。
- 小心任务依赖：任务A需要任务B的结果？那就别让它们同时出现在队列里。用任务图（Task Graph）来管理依赖关系。
- 空闲时间别浪费：主线程没事干时，可以跑一些“空闲任务”，比如预编译Shader、清理缓存。但记得设置时间预算，别影响下一帧。
嗯，主线程架构这块，说白了就是怎么让CPU在正确的时间做正确的事。消息队列是“输入”，事件循环是“调度器”，优先级是“规则”。三者配合好了，你的渲染进程才能既高效又稳定。