⚙️ Chromium 消息循环

目录

Chromium 为什么需要消息循环

• 跨平台：Windows / Linux / macOS / Android 统一抽象
• 低延迟：有任务就尽快唤醒，没有任务就安全休眠
• 可嵌套：弹窗、同步等待、原生消息泵都可能进入 nested loop
• 可控公平性：不同 TaskQueue 需要优先级和 fence

源码地图

理解顺序：Pump → ThreadController → SequenceManager → TaskQueue → RunLoop

总体分层

核心循环契约

• DoWork()：尝试执行应用任务，返回下一次唤醒信息
• DoIdleWork()：进入休眠前的收尾操作
• ScheduleWork()：跨线程 or 同线程立即唤醒
• ScheduleDelayedWork()：为最早 deadline 编排等待

MessagePump 接口

class MessagePump {
 public:
  class Delegate {
   public:
    struct NextWorkInfo {
      TimeTicks delayed_run_time;
      bool is_immediate() const;
    };
    virtual NextWorkInfo DoWork() = 0;
    virtual void DoIdleWork() = 0;
    virtual void BeforeWait() = 0;
    virtual void BeginNativeWorkBeforeDoWork() = 0;
  };
  virtual void Run(Delegate* delegate) = 0;
  virtual void Quit() = 0;
  virtual void ScheduleWork() = 0;
  virtual void ScheduleDelayedWork(...)=0;
};

NextWorkInfo 的意义

• immediate：马上再进 DoWork，常见于队列中还有 ready task
• delayed_run_time：有未来任务，睡到 deadline 或被外部唤醒
• max / null：当前没有明确 deadline，可以更保守休眠

MessagePump::Create

std::unique_ptr<MessagePump> MessagePump::Create(MessagePumpType type) {
  switch (type) {
    case MessagePumpType::UI: return std::make_unique<MessagePumpForUI>();
    case MessagePumpType::IO: return std::make_unique<MessagePumpForIO>();
    case MessagePumpType::DEFAULT: return std::make_unique<MessagePumpDefault>();
    ...
  }
}

同一套上层调度逻辑，通过工厂切到不同平台实现。

对齐唤醒策略

• 减少频繁 timer interrupt
• 移动端/电池场景更重要
• 对实时性要求高的任务则保留精确唤醒

MessagePumpDefault 主循环

for (;;) {
  Delegate::NextWorkInfo next = delegate->DoWork();
  bool immediate = next.is_immediate();
  if (state_->should_quit) break;
  if (immediate) continue;
  delegate->DoIdleWork();
  delegate->BeforeWait();
  event_.TimedWait(next.remaining_delay());
}

这是最纯粹的“任务驱动 + 条件变量/事件等待”模型。

Busy Loop 优化

• 适合极短 deadline
• 换来更稳定的任务响应时间
• 但 Chromium 明确限制 busy loop 时长，避免电量浪费

MessagePumpEpoll 的角色

• 统一处理 task + fd event
• 支持 one-shot / persistent watch
• 将“原生事件”纳入同一个执行节拍

WatchFileDescriptor

bool MessagePumpEpoll::WatchFileDescriptor(int fd,
                                           bool persistent,
                                           Mode mode,
                                           FdWatchController* controller,
                                           FdWatcher* delegate)

这层把 epoll interest、controller 生命周期、回调 delegate 绑定到一起，避免上层直接碰 epoll_ctl 细节。

Epoll Run 循环

for (;;) {
  NextWorkInfo next = delegate->DoWork();
  if (state->should_quit) break;
  bool did_native_work = WaitForEpollEvents(timeout);
  if (immediate || did_native_work) continue;
  delegate->DoIdleWork();
}

和 Default pump 很像，但中间多了一步 WaitForEpollEvents。

HandleWakeUp

• 跨线程 PostTask 能及时唤醒主循环
• 避免 signal/pipe 方案的复杂性
• 与 epoll 统一进一个等待集合

原生事件批处理

这是一个典型吞吐与公平性平衡点。

RunLoop 的定位

• Run()
• RunUntilIdle()
• Quit() / QuitWhenIdle()

RunLoop 类型

enum class Type {
  kDefault,
  kNestableTasksAllowed,
};

• kDefault：嵌套时尽量只跑系统任务，避免重入风险
• kNestableTasksAllowed：允许应用任务在 nested loop 中继续执行

RunLoop::Run

void RunLoop::Run(...) {
  if (!BeforeRun()) return;
  const bool application_tasks_allowed =
      run_depth == 1 || type_ == Type::kNestableTasksAllowed;
  delegate_->Run(application_tasks_allowed, TimeDelta::Max());
  AfterRun();
}

关键点：真正跑循环的是当前线程的 Delegate，而不是 RunLoop 自己。

QuitClosure 设计

这是一种很稳的线程亲和性封装。

ThreadControllerWithMessagePumpImpl 的职责

ThreadController 关键接口

void ScheduleWork() override;
void SetNextDelayedDoWork(LazyNow*, std::optional<WakeUp>);
MessagePump::Delegate::NextWorkInfo DoWork() override;
void DoIdleWork() override;
void BeginNativeWorkBeforeDoWork() override;

它是 Chromium 消息循环真正的“翻译层”。

ScheduleWork 去重

• 降低跨线程唤醒风暴
• 减少锁竞争
• 在高吞吐场景很关键

SetNextDelayedDoWork

if (wake_up) {
  run_time = pump_->AdjustDelayedRunTime(...);
  pump_->ScheduleDelayedWork({run_time, leeway, lazy_now->Now()});
}

SequenceManager 计算“下一个任务何时该跑”，ThreadController 再把它翻译成 Pump 能理解的定时唤醒。

DoWork 主体

• 如果又有 immediate work：返回 immediate
• 如果只有未来 deadline：返回 delayed_run_time
• 如果 idle：交给 DoIdleWork / BeforeWait 流程

Batch 执行模型

• 吞吐更高
• 过大则影响公平性与输入响应
• Chromium 允许动态开关/调整

嵌套 RunLoop 处理

void OnBeginNestedRunLoop() override;
void OnExitNestedRunLoop() override;
int RunDepth() override;

BeforeWait 钩子

SequenceManagerImpl 的定位

SequenceManager 关键方法

void BindToMessagePump(std::unique_ptr<MessagePump> pump) override;
void ScheduleWork();
std::optional<WakeUp> GetPendingWakeUp(...);
void DidRunTask(LazyNow& lazy_now) override;
bool OnIdle() override;

BindToMessagePump

manager->BindToMessagePump(std::move(message_pump));
controller_->BindToCurrentThread(std::move(pump));
controller_->SetSequencedTaskSource(this);

绑定后，SequenceManager 不再直接碰底层等待原语，而是只和 ThreadController 说话。

为什么要多 TaskQueue

TaskQueueImpl 四层队列

这种拆分能把并发入队、ready 判定、执行消费解耦。

PostImmediateTaskImpl

void PostImmediateTaskImpl(PostedTask task, ...) {
  push into immediate_incoming_queue;
  if (should_schedule_work)
    sequence_manager_->ScheduleWork();
}

重点不在“塞进队列”，而在：只有从空到非空等关键状态变化时才触发 ScheduleWork。

PostDelayedTaskImpl

MoveReadyDelayedTasksToWorkQueue

Fence 机制

void InsertFence(...);
void InsertFenceAt(TimeTicks time);
void RemoveFence();
bool BlockedByFence() const;

Fence 相当于“停止线”，能让某个 queue 暂时不可执行，常用于生命周期切换、页面冻结、导航隔离。

Queue Priority

Observer 与埋点

void AddTaskObserver(TaskObserver* observer);
void SetOnTaskStartedHandler(...);
void SetOnTaskCompletedHandler(...);
void AddTaskTimeObserver(TaskTimeObserver* observer);

Chromium 把可观测性内建在调度器里，方便跟踪 jank、长任务、队列饥饿。

Task 执行回调

RunOrPostTask

if (RunsTasksInCurrentSequence()) {
  RunTaskSynchronously(...);
} else {
  PostTask(...);
}

这是 Chromium 里很实用的一个模式：如果已经在正确线程，直接同步跑，省掉一次循环往返。

默认 TaskRunner 句柄

一次任务完整路径

延迟任务路径

Native Event 与 Task 交织

UML：类关系

时序图：立即任务

时序图：延迟任务

时序图：嵌套循环

为什么这套设计可靠

• 分层清晰：Pump 不懂任务语义，Queue 不懂 OS 等待原语
• 契约稳定：一切围绕 DoWork / ScheduleWork / delayed wake-up
• 嵌套可控：RunDepth、quit_pending、nestable policy 明确化
• 观测完善：task observer / trace / metrics 一开始就内建

性能优化点 1：减少唤醒

减少“空唤醒”是浏览器主线程省电与稳定性的基本功。

性能优化点 2：批处理

批处理提升吞吐，但要防止长批次拖慢输入响应。

性能优化点 3：时间抽象

常见反模式

• 在主线程里滥开 nested RunLoop
• 把低优先级大任务塞进高优先级队列
• 频繁 PostTask 但不做 dedup / coalescing
• 忽略 fence 与生命周期，导致页面冻结后仍跑活
• 用同步等待掩盖异步设计问题

工程启示 1

工程启示 2

工程启示 3

源码阅读建议

1. 先看 message_pump.h 契约
2. 再看 message_pump_default.cc 理解最小实现
3. 然后看 thread_controller_with_message_pump_impl.cc
4. 最后啃 sequence_manager_impl.cc 和 task_queue_impl.cc

关键源码片段 1：ScheduleWork

void ThreadControllerWithMessagePumpImpl::ScheduleWork() {
  if (work_deduplicator_.OnWorkRequested() ==
      ShouldScheduleWork::kScheduleImmediate) {
    pump_->ScheduleWork();
  }
}

一句话看懂：请求 work ≠ 总要唤醒 pump。

关键源码片段 2：RunLoop Quit 代理

if (!origin_task_runner_->RunsTasksInCurrentSequence()) {
  origin_task_runner_->PostTask(FROM_HERE,
      BindOnce(&RunLoop::Quit, Unretained(this)));
  return;
}

线程亲和性不是文档约定，而是代码层面强制执行。

关键源码片段 3：TaskQueue 入队后调度

bool should_schedule_work = false;
... push task into incoming queue ...
if (should_schedule_work)
  sequence_manager_->ScheduleWork();

入队和唤醒拆开，是为了把锁范围、状态变更和昂贵动作分离。

总结

扩展阅读

• base/message_loop/message_pump.h
• base/message_loop/message_pump_default.cc
• base/message_loop/message_pump_epoll.cc
• base/task/sequence_manager/thread_controller_with_message_pump_impl.cc
• base/task/sequence_manager/sequence_manager_impl.cc
• base/task/sequence_manager/task_queue_impl.cc
• base/run_loop.cc

读完这些，再去看 Blink scheduler / renderer main thread，会顺很多。