Wayland 的架构之困：当合成器与窗口管理器解耦之后

Linux 桌面生态正在经历一场静默的架构革命。

过去十年，Wayland 作为 X11 的继任者被寄予厚望，却迟迟未能完全接管桌面市场。其中一个被忽视的原因，或许藏在它的架构设计里——传统 Wayland 合成器（Compositor）采用了与 X11 时代截然不同的单体架构，将显示服务器、合成器和窗口管理器三个角色强行捆绑在一起。

这种设计解决了 X11 的延迟问题，却制造了新的麻烦：如果你想换一个窗口管理器，就必须重写整个 Wayland 合成器。

被忽视的架构债务

让我们先看看 X11 时代的分工：

• X Server 负责与内核交互，处理输入事件和缓冲区
• Compositor 负责将多个窗口的缓冲区合成为一帧画面
• Window Manager 负责窗口布局、快捷键、用户交互策略

这种分离架构的问题很明显：当用户点击一个按钮时，输入事件要在 X Server、Compositor、Window Manager 之间来回传递，每一次跨进程通信都在增加延迟。

Wayland 的解决方案是"一刀切"——把三个角色合并到一个进程里。这确实消除了延迟，但也带来了意想不到的副作用。

单体架构的隐性成本

想象一下这个场景：你喜欢 i3wm 的平铺布局，却看中了 Hyprland 的动画效果。在 X11 时代，你可以自由组合：用 i3wm 管理窗口，用 picom 做合成。但在 Wayland 世界里，这是不可能的。

每一个 Wayland 合成器都在重复造轮子：

• Sway 实现了 i3 的平铺逻辑，但必须从头写一套 Wayland 合成代码
• Hyprland 做出了漂亮的动画，却无法被其他窗口管理器复用
• 开发者想要自定义窗口管理策略，必须 fork 整个合成器

这种架构的隐性成本是：创新被锁定在单体边界内，无法像 X11 时代那样自由组合最佳组件。

River 的解耦实验

River 项目正在尝试一条不同的路。

它的核心洞察是：Wayland 解决的是 X11 的延迟问题，但并不意味着窗口管理器必须与合成器绑定。真正需要合并的只有显示服务器和合成器——这两个角色决定了帧延迟。窗口管理器完全可以作为独立进程存在。

River 0.4.0 版本引入的 river-window-management-v1 协议，正是这种思路的体现：

• River 专注于帧完美渲染、性能优化、底层基础设施
• Window Manager 作为独立程序，通过协议控制窗口位置、快捷键、布局策略

这种分离不是简单的进程拆分，而是重新定义了协议边界。窗口管理器拥有完整的控制权，却不必关心缓冲区合成、DRM/KMS 交互这些底层细节。

对搜索技术的启示

这个架构实验对搜索领域有有趣的映射。

现代搜索引擎的架构演进，其实也经历了类似的"合久必分，分久必合"：

早期分离架构：爬虫、索引、查询处理、排序各自独立，通过消息队列通信。灵活但延迟高。

单体优化阶段：为了降低延迟，很多系统开始将组件合并到同一进程，甚至同一台机器。性能提升，但灵活性下降。

现在的微服务趋势：随着硬件性能提升和网络优化，又开始在灵活性和性能之间寻找新平衡。

River 的探索提醒我们：架构选择的权衡不是一成不变的。当底层基础设施（Wayland 协议、硬件性能）发生变化时，上层的组件边界也值得重新审视。

未来展望

River 的窗口管理协议已经吸引了多个独立窗口管理器的实现。这种生态的多样性，正是 X11 时代的魅力所在。

如果这种模式被更广泛地接受，我们可能会看到：

• 专注于特定交互范式（平铺、浮动、标签页）的窗口管理器百花齐放
• 合成器专注于渲染性能和视觉效果，不必重复实现窗口管理逻辑
• 用户可以自由组合最佳组件，而不是被迫接受单体合成器的全部设计

当然，这种架构也有代价：进程间通信的延迟、协议标准化的复杂性、生态碎片化的风险。River 能否证明这些代价是值得的，还有待时间检验。

但无论如何，这种敢于质疑"既定架构"的探索精神，本身就值得尊重。

技术架构的演进，从来不是寻找唯一正确的答案，而是在不同约束条件下寻找最优的权衡。

或许 Wayland 的下一个十年，会从 River 这样的实验中找到新的方向。

来源: HackerNews (232 points, 107 comments)
原文: Separating the Wayland Compositor and Window Manager
相关: FOSDEM 2026 Talk