话说回来，

上一篇写 Renderer Pipeline 时我关注的是资源回来之后页面如何从 DOM/CSS 变成屏幕上的一帧。

写完那一篇之后很自然会换到另一个方向：

如果使用者已经看到页面了接下来点了一下、滚了一下Chromium 里会发生什么？

我以前很容易把这个过程想成：

使用者点击页面 → 触发 JS click handler → 页面更新

这种说法只描述了最表面的结果。使用者痛点：总觉得“点一下就能马上看到变化”，但实际情况远比这复杂。

输入不是一开始就属于网页

使用者在 Chrome 窗口里点了一下这个输入最开始并不知道自己属于谁。说到它可能是，

点了地址栏
点了返回按钮
点了权限弹窗
点了网页里的按钮
在页面里滚动
按了浏览器快捷键
按了页面监听的键盘事件

这些行为看起来都是“使用者输入”。但它们的目标完全不同，使用者痛点：在同一个窗口里操作，却不确定是浏览器层还是网页层。

输入进入 Chrome 后第一件关键的事不是马上进入网页，而是先在 Browser process 一侧判断目标。按理说，

• 如果目标是地址栏、工具栏、菜单、权限弹窗。事件会被浏览器 UI 自己处理。
• 如果目标是网页内容区域，它才会进入 WebContents / renderer 链路。

关键图示说明：

• Input Pipeline 并非 “点击 → JS” 的直线。而是先经过 Browser process 判断目标，再决定是否进入 renderer。

浏览器 UI 与网页内容是两条分支

这一点对理解 Chromium 很关键。按理说，Chrome 本身不是一个透明壳子。它有自己的地址栏、标签页、菜单、下载气泡、权限弹窗、快捷键程序。Browser process 必须先回答：

这个输入是给浏览器自己的？还是给网页内容区域的，

浏览器 UI 自己处理

• 典型场景：
• 点击地址栏 点击返回 / 刷新按钮 按 Ctrl+L / Ctrl+T 点击浏览器菜单操作权限弹窗

这些事件通常停留在 Browser process 的 UI 层，由 Views、Aura、Chrome UI 或命令程序处理。说起来，它们不会进入 Blink，也不会变成 DOM event。

页面内容继续路由

• 典型场景：
• 点击网页按钮 在输入框里输入文字 页面内滚动 触发 pointermove / click / keydown listener

这些事件会被送到对应的 WebContents，再通过 Browser 一侧的 renderer host 程序路由到目标 renderer。这条路才是我们通常说的“输入进入页面”。

页面输入也不是直接进入 JS

即使输入目标是网页内容，它也不会直接调用 JavaScript。Browser process 大致经过这样一段链路：

OS native input event
→ platform window receives event
→ ui::Event
→ target WebContents / RenderWidgetHostView
→ RenderWidgetHostImpl
→ InputRouter
→ WebInputEvent / WebCoalescedInputEvent
→ target renderer

User Pain Point:*高频事件可能被合并；renderer 忙时事件排队；某些事件需要等待默认行为取消——导致“无响应”或卡顿现象。*

• ui::Event : Chromium 对网站原生事件的统一抽象；避免各网站差异导致逻辑混乱。说起来，
• RenderWidgetHostView : 表示“页面可显示、可接收输入”的视图位置。不过，
• RenderWidgetHostImpl : 在跨进程通信中转发输入。并参与 ACK 管理，
• InputRouter : 排队、合并、发送和 ACK 管理。

User Pain Point:*当你感觉“单击无效”时往往不是因为 JS 没执行，而是因为之前就已经被消费或阻塞在前端链路上*。

完整数据形态可以记作：

OS event
→ ui::Event
→ WebInputEvent / WebCoalescedInputEvent
→ Blink DOM Event
→ JS callback / default action
→ DOM/CSS/layout invalidation
→ next frame.

说到注意，WebInputEvent 并非 DOM Event。底层 mouse down/up 在 Blink 后还要 hit test 和 DOM event dispatch 才能产生真正的 click 等可见行为。

Renderer侧为什么会分两条路？

• Differentiation 娱乐ween compositor fast path and Blink main thread.
• The goal is to avoid blocking on slow main thread for smooth interactions.

为什么滚动有时可以更快？

• Main thread often occupied by JS,layout,paint.

If all scroll had to wait for main thread,any minor JS lag would make scrolling feel janky.

The compositor fast path allows certain scrolls to be handled directly by compositor using existing layer/scroll tree,bypassing main thread.

。

---