Xfce 团队在 2026 年初正式宣布启动 xfwl4 项目，这是一个从零编写的 Xfce Wayland compositor，核心技术栈选择了 Rust 语言配合 Smithay 框架。与传统基于 wlroots（C 语言库）的 Wayland compositor 不同，xfwl4 采用了一种更符合 Rust 语言特质的架构设计。本文将深入分析 Smithay 框架的事件循环机制与模块化设计思路，探讨为何 xfwl4 选择 Smithay 而非 wlroots，以及这种选择对 compositor 性能和可维护性的影响。
为何 xfwl4 放弃 wlroots 转投 Smithay
在 Wayland compositor 开发领域，wlroots 长期以来是事实上的标准库。从 sway 到 Wayfire，绝大多数 Wayland compositor 都基于 wlroots 构建。然而，xfwl4 项目负责人 Brian Tarricone 在评估两条技术路线后，做出了使用 Smithay 的决策。这个决策背后有多重技术考量。
首先是语言层面的原生性。wlroots 使用 C 语言编写，虽然提供了 Rust 绑定，但绑定层与底层 C 代码之间的交互带来了额外的复杂性。Smithay 则是纯 Rust 实现，与 Rust 生态系统深度集成，开发者可以充分利用 Rust 的所有权系统、生命周期检查和类型安全特性。对于一个需要长期维护的桌面环境组件项目而言，这种语言层面的安全性保障至关重要。Way Cooler 团队在博客中详细记录了他们从 wlroots Rust 绑定迁移到 Smithay 的过程，指出 wlroots 的 C 风格设计使得 Rust 绑定很难做到零成本抽象。
其次是定制化能力的差异。wlroots 提供了一套相对高层次的抽象，这使得快速构建 compositor 变得容易，但也限制了深度定制的能力。Smithay 的设计理念则完全不同，它不提供开箱即用的 compositor 框架，而是提供构建 compositor 所需的各种组件和接口。开发者可以根据需要选择使用哪些组件，甚至可以完全重写某些行为。这种「乐高式」的模块化设计让 Smithay 能够支持从简单的 kiosk 模式 compositor 到完整的桌面环境。Smithay 官方文档明确指出，它不是一个框架，而是一套构建块。
第三是协议支持的广度。Smithay 支持所有官方的 Wayland 协议扩展，同时还兼容 wlroots 协议和一些 KDE 专用协议。这意味着使用 Smithay 的 compositor 可以运行更广泛的 Wayland 客户端，包括那些依赖特定扩展的应用。对于需要保持向后兼容性的桌面环境来说，这种广泛的协议支持是一个重要的考量因素。
calloop 事件循环的核心机制
Smithay 体系中的事件循环由 calloop 库提供支持，这是一个纯 Rust 实现的事件循环库，采用基于回调的设计模式。与 Rust 异步运行时（如 Tokio、async-std）不同，calloop 的设计更接近传统的事件驱动模型，这种设计选择与 compositor 的工作特性高度契合。
calloop 的核心抽象是 EventSource trait。任何可以产生事件的 I/O 源都可以实现这个 trait，包括文件描述符、计时器、信号等。EventSource trait 定义了三个关键方法：as_poll_source 返回一个可以实现 mio::Evented 的对象；process_events 处理从底层 I/O 机制收到的事件；register 和 deregister 用于向事件循环注册和注销源。
事件循环的运行通过 EventLoop::run 方法启动。这个方法接受三个参数：轮询超时时间、可变的共享状态闭包，以及一个在每次事件批处理之间执行的回调。典型的配置使用 20 毫秒的超时时间，这意味着事件循环最多等待 20 毫秒来处理新事件，然后执行批量处理逻辑。这种设计确保了 compositor 能够及时响应用户输入，同时不会空转浪费 CPU 资源。
calloop 的回调机制允许事件源在产生事件时执行用户定义的闭包。这个闭包接收三个参数：事件本身、特定于事件源的元数据，以及对共享状态的可变引用。通过这种设计，不同的事件源可以协同工作并共享 compositor 的内部状态。例如，当检测到新的键盘输入时，输入事件源触发回调，该回调可以修改 compositor 的焦点状态，然后通过共享状态传递给渲染逻辑。
calloop 的另一个重要特性是动态事件源管理。EventLoopHandle 可以克隆并在任何地方使用，这使得在事件回调中动态注册新的事件源成为可能。对于 compositor 来说，这很有用，例如当新的客户端连接时，可以在处理连接事件的过程中注册该客户端的输入事件源，而不必预先知道所有可能的客户端。
状态机驱动的 compositor 架构
Smithay 推荐使用状态机模式来组织 compositor 的内部逻辑。这种设计将 compositor 的状态明确建模为一组离散的状态，每个状态定义了在当前状态下可以处理哪些事件以及状态转换的规则。这种模式在 Rust 中可以通过枚举和 match 表达式优雅地实现，同时受益于编译器的穷尽性检查。
以窗口管理为例，compositor 的窗口状态可能包含以下状态：初始状态（窗口尚未映射）、就绪状态（窗口已映射并可见）、最小化状态、最大化状态、全屏状态等。每个状态定义了在接收到特定事件时的行为和可能的状态转换。例如，在就绪状态下接收到最小化请求时，窗口状态应转换到最小化状态，同时触发相应的渲染更新。
状态机模式的优势在于其可预测性和可调试性。由于所有可能的状态和转换都是显式定义的，代码的逻辑流变得清晰可见。当 compositor 行为异常时，开发者可以更容易地追踪状态变化路径。此外，状态机模式天然支持复合状态 —— 例如，一个窗口可以同时处于「最大化」和「聚焦」状态，这在传统的事件处理器中往往需要复杂的标志位组合来处理。
Smithay 的模块化设计允许不同的 compositor 组件独立实现自己的状态机。输入处理、窗口管理、输出配置、快捷键绑定等都可以有自己的状态机，这些状态机通过共享的全局状态进行协调。这种关注点分离使得各个组件可以独立演进，降低了系统的耦合度。
与 wlroots 事件循环的对比
理解 Smithay 的设计需要将其与 wlroots 的事件模型进行对比。wlroots 使用 C 语言的事件循环机制，通常与 libwayland 的事件循环集成。wlroots 提供了 wlr_backend、wlr_input_device 等结构体，通过回调函数处理事件。这种设计是有效的，但在 Rust 中使用 FFI 调用这些 C 回调会失去 Rust 类型系统的保护。
从性能角度看，两种设计处于同一水平。两者都是基于 epoll（Linux）或 kqueue（BSD/macOS）的低层次事件通知机制。Smithay 使用 Rust 的 mio 库作为其 I/O 多路复用的底层实现，这与 wlroots 内部使用的机制在原理上是相同的。性能差异主要来自语言运行时的开销 ——Rust 的零成本抽象意味着 Smithay 的事件分发逻辑在编译后与手写的 C 代码几乎等价。
在可组合性方面，Smithay 展现出明显的优势。由于所有组件都通过 Rust 接口交互，开发者可以轻松替换或扩展任何子系统。例如，如果需要实现一个自定义的窗口装饰渲染器，只需实现 Smithay 的相应 trait 并将其插入 compositor 流程即可。在 wlroots 中实现类似的定制通常需要修改 wlroots 本身或通过复杂的钩子机制绕过其默认行为。
Smithay 生态中的实际 compositor 实现
Smithay 已经被多个生产级 compositor 项目采用，这些项目验证了框架的实用性和稳定性。System76 的 Cosmic 桌面环境是 Smithay 的最大用户之一，他们基于 Smithay 构建了下一代 Wayland 桌面体验。Niri 则是一个专注于滚动平铺的 compositor，它展示了 Smithay 在实现复杂窗口布局算法方面的能力。Catacomb 是一个面向移动设备的 Wayland compositor，表明 Smithay 可以适应从桌面到嵌入式等多种场景。
这些项目共同证明了 Smithay 的设计是成熟和可扩展的。每个项目都根据自身需求选择了 Smithay 的不同组件组合，同时共享底层的事件循环和协议处理基础设施。这种灵活性正是 Smithay 设计目标的体现：提供一个共同的基石，让不同的 compositor 可以在其上构建各自独特的功能。
对于 xfwl4 来说，采用 Smithay 意味着它可以站在这些先行项目的经验之上。xfwl4 的目标是实现与现有 xfwm4 完全一致的窗口管理行为，这意味着它需要精确实现 Xfce 多年积累的窗口管理策略。Smithay 的模块化设计使得移植这些策略成为可能，而不必被束缚在某个预设的 compositor 框架中。
工程实践中的关键参数
在基于 Smithay 构建 compositor 时，有几个工程参数值得特别关注。首先是事件轮询的超时时间设置。默认的 20 毫秒超时是一个平衡响应性和 CPU 功耗的折中值。对于需要更低延迟的场景（如实时图形应用），可以将超时降低到 5 毫秒甚至 1 毫秒，但这会提高 CPU 占用率。对于嵌入式或电池供电设备，适当增加超时（如 50-100 毫秒）可以显著降低功耗。
其次是事件批处理策略。calloop 会在每次轮询后调用用户提供的回调，这允许在处理完一批事件后执行自定义逻辑。一个常见的模式是在这里执行渲染更新，将所有待处理的窗口修改合并为一次渲染操作。这种批量处理可以减少画面撕裂并提高渲染效率。然而，需要注意不要在批处理回调中执行耗时操作，否则会阻塞事件循环导致输入延迟。
第三是状态序列化的考虑。虽然 compositor 通常是短期运行的服务进程，但实现状态快照和恢复功能对于调试和会话管理很有价值。Smithay 的状态机模式使得序列化 compositor 状态相对简单 —— 只需为每个状态枚举实现序列化逻辑即可。xfwl4 的路线图中提到支持 xdg-session-management 协议，这将需要某种形式的状态持久化。
面向未来的架构演进
Wayland 协议本身仍在不断演进，Smithay 的设计使其能够相对容易地支持新的协议扩展。每个 Wayland 协议在 Smithay 中对应一个独立的模块，添加新协议只需要实现相应的 trait 并在 compositor 中注册。对于 xfwl4 这样的长期项目，这种演进能力至关重要 —— 它确保了 compositor 不会因为协议变化而需要大规模重构。
Rust 异步生态系统的成熟也影响着 Smithay 的发展路线。虽然 calloop 目前基于回调模型，但 Smithay 社区正在探索如何更好地与 async/await 语法集成。一种可能的方案是提供 calloop 事件源与 async 任务之间的桥接，让开发者可以根据场景选择同步或异步编程模型。这种灵活性将进一步扩大 Smithay 的适用场景。
Xfwl4 项目计划在 2026 年中发布首个开发版本，届时我们将能够看到 Smithay 在一个完整的桌面环境中的实际应用。无论最终的实现细节如何，xfwl4 基于 Smithay 的架构选择已经表明，Rust 生态系统中的 Wayland compositor 开发已经达到了生产就绪的成熟度。对于其他考虑从 X11 迁移到 Wayland 的桌面环境项目来说，Smithay 提供了一个值得认真考虑的技术选项。
参考资料
- Xfwl4 项目路线图：https://alexxcons.github.io/blogpost_15.html
- Smithay 官方仓库：https://github.com/Smithay/smithay
- calloop 事件循环库：https://github.com/Smithay/calloop