Zebkit：把Chromium引擎变成你的库
Zebkit – Chromium as an embeddable library
厌倦了Electron庞大的体积和缓慢的启动？Zebkit提供了一种全新的思路：将Chromium引擎直接作为链接库集成到你的应用中，而非依赖独立的运行时。它保留了Blink、V8、PDFium和FFmpeg等核心组件，却剥离了Chrome浏览器的外壳。无论是C、C++、Rust还是Python应用，只需几行代码即可嵌入Web视图，同时享受原生窗口和工具链的控制权。相比Electron，Zebkit体积减小34%，冷启动时间缩短至2.3秒，内存占用更低，且无需Node.js。它不仅支持完整的PDF编辑和媒体处理API，还能让Playwright的自动化功能在引擎内部原生运行，速度提升数倍。这是一个让开发者真正掌控Chromium能力的轻量化解决方案。
Zebkit是Chromium引擎作为你链接到应用中的一个库：包含Blink、V8的所有JIT层级、PDFium、FFmpeg以及构成Chrome的所有组件，但没有Chrome浏览器的任何部分，也没有Electron的运行时。
HN 评论区
40- torginus
这和 CEF（Chromium Embedded Framework）有什么区别？
CEF 也是一个相当精简版的 Chrome 引擎，专为嵌入使用而设计，被无数项目采用，比如游戏用于其游戏内大厅，或者 OBS 用于其 Web 叠加层。
就我个人而言，我对 CEF 的顾虑是它让 Chrome 保持得相当“原汁原味”——里面有很多东西是你不想包含在你的用户应用里的。
但他们这么做是有原因的——如果他们真的大刀阔斧地砍掉 Chrome 的代码库，基本上就会失去将新版本上游化的能力。
另一方面，Zebkit 听起来会更加细粒度——我们拭目以待看他们能否更好地处理这个问题，但我认为确实存在一个市场对更轻量级且广泛兼容的浏览器引擎有需求——例如，仅仅去掉沙箱和进程隔离就是一个巨大但会导致不兼容的改动。
同样，如果去掉 WebRTC、视频播放、webusb 或诸如此类的大型模块，我相信 99% 的应用最终都不会用到它们。
- joahnn_s
我不太明白。CEF 已经存在了，为什么还要把它作为共享库/cffi 加载？这会让你的应用进程暴露在所有浏览器可能遇到的问题中，包括安全问题。
在大多数语言中，CFFI 崩溃会导致整个应用进程崩溃，因为它们是同一个进程。也许用于个人项目还行，但没什么严肃的应用场景适合这么干。
- netshade
不错。我是 ZShot（https://zshot-app.com, https://zshot-cli.com）的重度 CEF 用户，但我非常赞同你的观点，这类东西应该更容易集成。
此外，我也非常赞同将那些库（比如 PDFium 和 FFmpeg）暴露给消费者，这能大幅降低打包负担，并且能解锁很多功能。
给任何走这条路的人提个醒，顺便说一句：实际上打包 Chromium（尤其是 FFmpeg）可能会变得很复杂。如果你在 Mac OS 上分发，你需要担心对你的主进程以及所有辅助进程进行公证（我假设 Zebkit 仍然运行着辅助进程）。链接到 FFmpeg 库时情况也类似。另外，对于 FFmpeg，只需验证你的许可证合规性是否确实是你想要分发的版本——FFmpeg 有 GPL 和 LGPL 模式，确保你选择了正确的那个很重要。如果我没记错的话，Blink 也是 LGPL，所以确保你满足那里的要求对分发有一些重要的影响。
- tarpump
新手提问——这和 Electron 有什么区别？
- prologic
这很有趣！我为 GoNix（https://gonix.dev）用 CEF（Chromium Embedded Framework）创建了一个网络浏览器，效果相当不错，但需要共享内存和管道，不过将 Chromium 作为库嵌入听起来甚至更吸引人。我可能会试试这个！感谢分享！