LPC83x微控制器功耗优化实战：从数据手册解读到低功耗设计
2026/6/10 5:33:23
Capy UI vs Zapy UI — 深度对比
先澄清最关键的一点：Zapy 不是 Capy 的竞品，而是 Capy 的 Fork
从 Zapy UI 自己的 README 就能直接确认：
Zapy UI is an actively maintained fork of the original Capy UI project.As the original developer has reduced activity, I’ve taken over development to push the project forward…
所以它们的"对比"，本质上是原版 Capy（上游）vs社区接手的活跃复刻（Zapy）的选择问题。
1. 项目身世与现状
| 维度 | Capy UI（原版） | Zapy UI |
|---|---|---|
| 作者/维护者 | zen1th（Zen1th Rempler） | zapy-ui 维护者接手（Codeberg 托管） |
| 仓库 | GitHubzen1th/Capy→ 官网capy-ui.org | Codebergzapy-ui/zapy-ui |
| 定位 | 原始项目，仍在推进但节奏慢 | 活跃维护的 fork，明确标注"breaking changes as we improve" |
| 目标 Zig 版本 | 随 Zig master 波动（常跟 nightly） | 明确标靶Zig 0.15.1 |
| 生产就绪？ | 作者自己说NOT ready for production，仍有 breaking changes | 同样标注evolving with breaking changes，但更主动修 bug |
| 社区渠道 | #capy-uiMatrix / Zig Discord#gui-dev | 沿用同一套社区渠道（本身就是同一条线） |
2. 架构与核心技术（两者共享的 DNA）
两者底层完全一致，因为 Zapy 就是 Capy 的代码 fork：
- 声明式 UI 范式— 用
capy.column(.{ .spacing = 10 }, .{ ... })这样的 comptime 风格构建 widget tree - 原生控件后端（非自绘）：
- Windows→ Win32 API（原生 HWND 按钮/文本框等）
- Linux→GTK 3（选择原因：兼容性最广，KDE 的 Qt 主题集成不够统一）
- macOS→ AppKit（WIP）
- Web→ WASM + JS bridge（canvas 渲染层）
- 可执行体积极小— 示例程序 < 2MB，远小于 Electron（150MB+）/ Flutter（10MB+）/ Qt（8MB+）
- 导出 C ABI—
capy-ui.org强调可导出 C API，供 C/C++/Node/Bun 等调用 - DataWrapper驱动数据绑定 & 动画（comptime-heavy 设计）
一句话：Zapy 和 Capy 用的是同一套引擎。差异不在"谁的架构更好"，而在"谁在修 bug、谁在跟进 Zig 版本、谁在合并 PR"。
3. 关键差异点（这才是你选哪个的依据）
🔹 维护活跃度
| Capy（原版） | Zapy | |
|---|---|---|
| 提交频率 | 间歇式，作者承认“slow pace” | 更持续，明确在做 bug fix + WASM 完善 |
| Issue/PR 处理 | 堆积风险 | Fork 动机之一就是"原仓库响应慢" |
| Zig 版本适配 | 跟 zig master，但容易 broken | 锁定瞄准0.15.1，更稳定可复现 |
🔹 WASM / Web 支持
- Capy 原版的 WASM 后端是experimental级别
- Zapy 明确把improved WASM support列为 fork 的核心卖点之一
🔹 API 稳定性
- Capy 0.3 的 changelog 里作者直言仍在做 breaking changes（
setProperty风格 API 在犹豫中） - Zapy 坦诚地说“API may change in the future”，但它是在主动整形而非被动停滞
🔹 生态与 Docs
- Capy 有
capy-ui.org正式文档站 + 模板（capy-template） - Zapy 目前主要指向 Capy 的同一套文档/模板/社区，自身还没建独立品牌体系
4. 代码层面——几乎一模一样
Zapy 的示例用的 import 名还是capy（不是zapy）：
const capy = @import("capy"); const std = @import("std"); pub usingnamespace capy.cross_platform; pub fn main() !void { try capy.init(); defer capy.deinit(); var window = try capy.Window.init(); try window.set(capy.column(.{ .spacing = 10 }, .{ capy.button(.{ .label = "Save", .onclick = @ptrCast(&buttonClicked) }), capy.expanded(capy.textArea(.{ .text = "Hello World!" })), })); window.setPreferredSize(800, 600); window.show(); capy.runEventLoop(); }你在 Zapy 里写的代码，和 Capy 里的写法是同一个 namespace。迁移成本 ≈ 改build.zig.zon里的 URL。
5. 实用选型建议
| 场景 | 推荐 |
|---|---|
| 你想今天就开始做一个 Zig GUI 原型，并且 zig 0.15.x 环境 | ✅Zapy— 更可能编译过、WASM 更可用、bug 修复更快 |
| 你想要跟着上游官方走，愿意等/自己 patch | 盯Capy原版（capy-ui.org），关注 zen1th 是否回归活跃 |
| 生产用途 | ⚠️ 两者都明确说not production ready，都要做好 breaking change 的心理准备 |
| 你需要 macOS 原生 | 两者都标 macOS 为 WIP；实际可用性以你亲手编译测试为准 |
一句话总结
Capy 是"亲爹"，Zapy 是"养父接过来继续养"。如果你只是想写 Zig 原生 GUI 且希望它能编译、有人修东西——Zapy 在目前这个时间窗口更务实。但长远看，如果原版 Capy 重新活跃、或 Zapy 反并回去，这条线大概率会 reconverge（重新汇合）。两者不是 Flutter vs Electron 那种架构对立，而是同一个项目在不同维护者手里的两种命运。
需要我帮你搭一个最小可运行的build.zig.zon+build.zig模板（针对 Capy 或 Zapy，指定 Zig 0.15.x）吗？