在系统编程领域,UI 框架一直是块难啃的骨头。Rust 有 Druid 和 Iced,Python 有 PySide,而 Zig 语言社区长期缺乏一个生产级的 GUI 方案。Gooey 是近期出现在 GitHub 上的一个实验性项目,试图改变这一现状——它是一个完全用 Zig 编写的 GPU 加速跨平台 UI 框架,支持 macOS(Metal)、Linux(Vulkan/Wayland)和浏览器(WASM/WebGPU)三大平台,被定位为"GPU渲染优先"的现代 UI 基础设施。
Gooey 采用了混合即时模式与保留模式的渲染架构。这一设计选择并非随意:即时模式适合快速 UI 状态刷新的场景,保留模式则能高效处理复杂静态界面。Gooey 将两者结合,用 GPU 完成实际渲染,同时维护一棵场景图供保留模式使用。这意味着开发者既能享受即时模式编程的灵活性,又能获得保留模式的高性能缓存优势——两者在传统 UI 框架中通常是鱼与熊掌不可兼得的选择。

项目采用 Zig 原生生态而非第三方包依赖。Zig 是一门系统级编程语言,主打透明式内存管理和编译期计算,其元编程能力正好适合这种需要精细控制底层资源的项目。区别于 C++ 的模板元编程和 Rust 的 trait 系统,Zig 的编译期计算更接近金属直出的理念——没有隐藏的控制流,没有隐式的内存分配,所有计算都在编译期完成,结果直接写入编译产物。这种特性让 Gooey 能够在编译阶段为不同平台生成定制化的渲染代码,而不是依赖运行时反射。
Gooey 声称仅链接系统框架和库——在 macOS 上链接 Metal 和 Foundation,在 Linux 上链接 Vulkan/Wayland,在浏览器上编译为 WASM + WebGPU。这种策略让二进制体积可控,也避免了跨平台依赖的复杂性。不同于 Electron 应用动辄数百 MB 的运行时开销,用 Zig 和原生 GPU API 构建的 UI 程序在理论上可以达到接近原生应用的体积和性能。
三大平台的三种渲染 API 是最大的技术障碍。Metal、Vulkan 和 WebGPU 虽然都源自 AMD 的 Mantle 家族,但 API 设计差异显著——Metal 偏向苹果的极简风格,Vulkan 需要显式地管理所有资源生命周期,WebGPU 则介于两者之间并额外处理 JavaScript 运行时的内存管理。Gooey 的策略是提供统一的渲染抽象层,将底层 API 差异封装在平台适配层中,开发者接触的是同一套渲染原语。
这类似于后台管理系统中常见的"一次编写,到处运行"逻辑,但实现难度要高出几个数量级——GPU 编程没有虚拟机这层缓冲,每一条渲染指令都需要精确对应到底层 API 调用。当一个 macOS 上的 Metal 命令缓冲区在 Vulkan 对应体中需要被翻译成一组"管线状态对象+描述符集"时,抽象层的复杂性急剧上升。这也是为什么 GUI 跨平台方案长期被 Electron 和 Qt 统治——它们各自找到了不同的折中点。
另一个挑战是输入事件处理。桌面端需要处理鼠标光标轨迹、键盘焦点顺序、触控板手势,浏览器端需要处理键盘、鼠标以及移动端才有的手势和屏幕旋转事件。Gooey 正在构建统一的输入事件模型,试图在不同平台提供一致的交互体验,但目前尚未完全实现。
选择 Zig 来实现 UI 框架有几个深层原因。首先,Zig 的编译期计算能力可以在编译阶段生成大量样板代码,减少运行时的反射开销——这在需要为不同平台生成不同渲染代码时尤为重要。其次,Zig 对 WASM 的良好支持让同一套代码天然具备浏览器运行能力,配合 WASI 标准甚至可以探索桌面端以外的更多场景。第三,Zig 与 C 的无缝互操作使得 Gooey 可以渐进式地集成现有 C 语言图形库,而不是从头实现所有渲染基元。
Zig 社区近年来在系统编程领域积累了不少关注度,但 GUI 方向一直是空白。主流 Zig 项目如 Ziglang 编译器本身和 zls 语言服务器都运行在命令行界面,Gooey 的出现填补了这一空白,也为 Zig 在嵌入式 GUI 领域的可能性做了初步验证。
当然,作为一个早期项目,Gooey 的局限性也很明显:缺乏成熟的组件库、文档有限、API 尚未稳定。目前它实现的仅有基础图元渲染、输入事件接收和跨平台窗口管理,离"可用的 UI 框架"还有相当距离。它目前的定位是给希望在 Zig 生态中探索 GUI 可能性开发者的技术演示,而非生产级解决方案。
跨平台 UI 框架的历史几乎和个人计算机的历史一样长。早期有 Qt、Tkinter 和 GTK,此后有 Swing、JavaFX,再之后是 Electron 和 Flutter。每一次技术跳跃都试图解决前一代的某个核心矛盾:Qt 解决了性能问题但引入 C++ 复杂性,Electron 解决了跨平台问题但带来体积问题,Flutter 解决了渲染一致性但引入了 Dart 语言的学习成本。
在 GPU 成为主流计算单元的今天,将渲染层卸载到 GPU 上已经是行业共识。问题是抽象层的边界在哪里——有些框架选择将 GPU 细节完全对开发者隐藏(如 Flutter 的 Skia),有些则选择让开发者直接操作 GPU 原语(如 wgpu)。Gooey 目前处于两者之间:保留模式的场景图提供了抽象,但渲染管线仍然需要为每个平台单独实现适配层。
GPL 许可意味着任何商业项目直接使用 Gooey 需要考虑许可证兼容性,但 MIT 许可的承诺(项目 README 中已注明)让这一顾虑即将消除。随着许可问题解决和社区贡献增加,Gooey 有望成为 Zig 生态在 GUI 领域的重要里程碑。
对系统编程爱好者而言,Gooey 展示了一种可能性:用一门强类型、高性能、编译期计算的语言,配合现代 GPU 渲染技术,能否构建出比 Electron 更轻量、比 Qt 更现代的跨平台 UI 方案?这个问题的答案,还要等社区给出。
Gooey 开源地址:https://github.com/duanebester/gooey