Electron 和 Chromium 嵌入式框架（Chromium Embedded Framework，CEF）是两种成熟的技术，用于将 Chromium 引入桌面应用程序。两者都允许开发者构建可在 macOS、Windows 和 Linux 上显示现代网站和 Web 界面的软件。不过，它们的用途存在根本区别。
Electron 是一个完整的桌面应用框架，结合了 Chromium、Node.js 和原生操作系统 API。开发者无需具备丰富的原生编程经验，就能使用 JavaScript、TypeScript、HTML 和 CSS 构建完整的应用程序。相比之下，CEF 是一个将 Chromium 嵌入现有或新应用程序的框架，这些应用程序通常使用 C++ 或其他原生语言编写。
这两种技术都广泛用于生产环境中的软件。Visual Studio Code、Slack、Discord 和 Notion 等应用使用 Electron，而 Spotify、Steam 和 OBS Studio 等产品则使用 CEF。在 WebCatalog，我们选择使用 Electron 构建跨平台桌面应用程序。
那么，两者有什么区别？在什么情况下应该选择其中一种？
Electron 与 CEF 概览
虽然 Electron 和 CEF 都使用 Chromium，但它们在架构、开发体验和目标应用场景方面存在显著差异。
| 特性 | Electron | Chromium 嵌入式框架（CEF） |
|---|---|---|
| 首次推出 | 2013 年 | 2008 年 |
| 主要用途 | 构建完整的桌面应用 | 将 Chromium 嵌入其他应用程序 |
| 浏览器引擎 | Chromium | Chromium |
| 主要语言 | JavaScript、TypeScript | C、C++，以及第三方语言绑定 |
| 是否包含 Node.js | 是 | 否 |
| 原生集成 | Electron API 和 Node.js 原生模块 | 与原生代码直接集成 |
| 应用结构 | 主进程和渲染进程 | 宿主应用程序与 Chromium 子进程 |
| 离屏渲染 | 可通过定制方案实现 | 内置 API 支持 |
| 应用体积 | 通常较大 | 取决于集成方式，但 Chromium 本身体积较大 |
| 性能 | 取决于应用程序 | 取决于应用程序和集成方式 |
| 跨平台支持 | macOS、Windows、Linux | macOS、Windows、Linux |
| 打包生态 | Electron Forge、electron-builder | 通常由宿主应用程序管理 |
| 最适合 | 基于 JavaScript 的桌面应用 | 需要嵌入 Web 内容的原生应用 |
最重要的区别在于，Electron 提供的是应用框架，而 CEF 提供的是浏览器嵌入框架。由于两者处于不同的抽象层级，因此不一定能直接相互替代。
架构：完整框架与嵌入式浏览器
Electron 将 Chromium 和 Node.js 结合为统一的应用运行时。开发者创建主进程来管理应用窗口、生命周期事件和原生功能，而渲染进程则负责基于 Web 的界面。
这种架构使开发者能够使用熟悉的 JavaScript 和 TypeScript 工具编写应用程序的大部分代码。Electron 提供了用于创建窗口、管理浏览器会话、处理菜单、显示通知、访问系统对话框以及与操作系统集成的 API。
CEF 采用了不同的方法。它并不提供完整的桌面应用框架，而是允许开发者将 Chromium 集成到由他们自行构建和控制的应用程序中。
例如，开发原生 C++ 应用程序的开发者可以使用 CEF，在现有应用窗口中显示 Web 内容。外围界面、应用生命周期、后台服务和其他原生功能仍由开发者掌控。
CEF 提供了用于管理浏览器实例、导航、资源加载、JavaScript 执行，以及浏览器与原生应用之间通信的 API。它也采用 Chromium 的多进程架构，使用独立进程处理渲染和其他浏览器功能。
这种区别会影响开发者组织应用程序的方式。使用 Electron 时，应用程序通常围绕 Chromium 和 Node.js 构建。使用 CEF 时，Chromium 通常只是更大型应用程序中的一个组件。
CEF 也可以用于构建以 Web 界面为主的应用程序，但开发者需要自行实现更多配套的应用基础设施。
一个有趣的历史细节是，早期版本的 Electron 和 NW.js 都使用过 CEF。Electron 最终转向与 Chromium 更直接地集成，因为 CEF 的抽象层使某些功能难以实现，尤其是与 Node.js 的深度集成。
对于希望使用 Web 技术构建桌面应用、并需要完整框架的开发者来说，Electron 通常是更直接的起点。对于已经拥有原生应用、希望添加 Web 功能的开发者来说，CEF 可能是更自然的选择。
开发体验：JavaScript 与原生开发
Electron 最大的优势之一是易于上手。熟悉现代 Web 开发的开发者可以利用现有技能构建桌面应用，无需学习 C++ 或特定平台的 UI 框架。
Electron 与 Node.js 的集成让开发者可以利用庞大的软件包生态，实现文件系统操作、网络通信、数据库、后台进程和其他功能。React、Vue、Svelte 和 Angular 等流行前端技术都可以使用，无需对架构进行重大调整。
CEF 主要围绕 C 和 C++ API 设计。虽然 C#、Java、Python 和 Delphi 等语言有第三方绑定，但开发者仍需了解原生应用的架构，以及 CEF 对进程、线程和生命周期的要求。
对于已经在维护原生应用的团队来说，这可能是优势而非劣势。CEF 允许开发者引入现代 Web 界面，而不必重写现有原生代码或采用全新的应用框架。
不过，对于以 JavaScript 为主、准备开发新桌面应用的团队来说，CEF 通常需要更多的配置和原生集成工作。
这种差异也体现在工具方面。Electron 拥有 Electron Forge 和 electron-builder 等成熟工具，可以简化打包、代码签名、应用分发和更新。CEF 提供二进制发行包和示例，但开发者通常需要自行将框架集成到自己的构建和部署系统中。
这并不意味着 CEF 的能力更弱，而是反映了它作为可嵌入组件、而非完整应用开发平台的定位。
性能、内存占用与应用体积
由于 Electron 和 CEF 都使用 Chromium，因此两者都不会自动消除运行现代浏览器引擎所带来的资源开销。
这两种技术都可能使用多个进程来处理渲染、GPU 加速、网络通信和其他浏览器功能。内存消耗和 CPU 使用率在很大程度上取决于显示的内容、活跃浏览器实例的数量，以及应用程序管理资源的方式。
将 CEF 集成到现有原生应用中时，可以获得更高的灵活性。开发者可以仅在需要 Web 技术的界面部分使用 Chromium，而直接用原生代码实现其他功能。
例如，图形应用程序可以使用 CEF 实现设置面板或嵌入式 Web 界面，同时继续以原生方式实现渲染引擎、文档处理和其他对性能敏感的功能。
Electron 应用也可以通过 Node.js 插件、外部进程或原生模块执行原生代码。不过，Electron 的架构总体上更倾向于使用 Web 技术构建应用程序本身。
CEF 一项特别实用的能力是离屏渲染。CEF 可以将内容渲染到缓冲区中，由宿主应用自行处理和显示，而不是在传统浏览器窗口中显示 Web 内容。这对游戏引擎、流媒体软件以及采用自定义渲染系统的工具等应用很有价值。
Electron 可以通过额外集成来支持特殊的渲染工作流，但 CEF 已将离屏渲染作为其嵌入 API 的成熟组成部分提供。
对于评估性能的开发者来说，最有参考价值的指标包括：
- 启动时间： 应用程序多快能够进入可用状态。
- 内存占用： 在运行具有代表性的浏览器内容和原生功能时的资源消耗。
- CPU 使用率： 渲染、导航和后台操作期间的性能表现。
- 应用体积： 下载大小和安装后的磁盘占用。
- 渲染需求： 应用程序需要普通窗口，还是自定义离屏渲染。
区分 CEF 与基于系统 WebView 的框架也很重要。CEF 自带 Chromium，而不是依赖操作系统安装的浏览器引擎。因此，从 Electron 切换到 CEF，并不会自动让应用体积大幅缩小。
如果开发者最关心的是缩小应用安装包，可以考虑 Tauri 等使用系统提供的 WebView 的替代方案。
如果没有对实际实现进行基准测试，就不应断言 Electron 或 CEF 一定更快。
安全性与浏览器更新
Electron 和 CEF 都依赖 Chromium 的浏览器架构与安全机制，但开发者有责任正确配置自己的应用程序。
Electron 提供了渲染进程沙箱、上下文隔离，以及在具有特权的应用功能与 Web 内容之间基于 IPC 的通信等特性。其安全文档建议限制 Node.js 访问、仔细验证 IPC 消息，并将远程加载的内容视为不可信内容。
CEF 也支持 Chromium 的多进程架构和安全隔离。不过，由于 CEF 被集成到开发者自行控制的应用程序中，因此宿主应用需要负责决定对外开放哪些浏览器功能、权限和原生能力。
CEF 支持 JavaScript 绑定和原生通信，允许开发者将 Web 内容与应用功能连接起来。这些接口必须谨慎设计，尤其是在显示第三方网站时。
| 安全考量 | Electron | CEF |
|---|---|---|
| Chromium 沙箱 | 支持 | 支持 |
| 特权原生访问 | Node.js 和 Electron API | 宿主应用的原生 API |
| JavaScript 与原生代码通信 | 预加载脚本和 IPC | V8 绑定和进程消息传递 |
| 远程内容隔离 | 渲染进程沙箱和上下文隔离 | Chromium 进程隔离和宿主控制机制 |
| 浏览器安全更新 | 升级 Electron 版本 | 升级 CEF 版本 |
| 应用安全责任方 | 应用开发者 | 应用开发者 |
另一个重要考量是浏览器维护。Electron 和 CEF 通常都会分发自己的 Chromium 运行时，因此，当安全修复发布时，开发者必须发布应用更新。
CEF 提供跟踪 Chromium 的发布分支和二进制发行包，以简化这一过程。Electron 同样维护着包含 Chromium 和 Node.js 更新的版本。
这两种方式都无法完全免除持续维护的需要。使用旧版 Chromium 的应用，可能仍然受到上游已经修复的漏洞的影响。
对于开发可显示任意网站的软件的团队来说，安全维护应当被视为应用生命周期中不可或缺的一部分，而不是偶尔才做的任务。
采用情况：使用 Electron 和 CEF 的主要应用
Electron 和 CEF 都已广泛应用于生产环境，但它们的使用模式有所不同。
Electron 在主流桌面效率工具、通信软件和开发者应用中尤其常见。微软使用 Electron 开发 Visual Studio Code，其他知名 Electron 产品包括 Slack、Discord、Notion、Figma、Signal Desktop 和 GitHub Desktop。
CEF 也被大型软件公司采用，尤其是在将 Web 界面集成到具有现有原生架构的应用程序时。
例如：
| 应用程序 | 技术 | 典型用途 |
|---|---|---|
| Visual Studio Code | Electron | 跨平台代码编辑器 |
| Slack | Electron | 团队沟通 |
| Discord | Electron | 沟通与社区平台 |
| Notion | Electron | 笔记与效率工具 |
| Figma Desktop | Electron | 设计应用 |
| Spotify Desktop | CEF | 桌面客户端中基于 Web 的界面 |
| Steam | CEF | 桌面客户端中的嵌入式 Web 界面 |
| OBS Studio | CEF | 浏览器源、叠加层和浏览器停靠面板 |
Spotify 是一个有充分文档佐证的 CEF 使用者。其官方开源页面公布了与 Spotify Desktop 各版本对应的 CEF 和 Chromium 版本。
OBS Studio 是另一个清晰展示开发者为何选择 CEF 的例子。它的 obs-browser 集成使用 CEF 提供浏览器源，让用户能够在直播场景中显示基于 Web 的叠加层和其他内容。CEF 是 OBS Studio 的一个组件，而不是用于构建整个应用程序的框架。
Steam 也在其桌面客户端中使用基于 Chromium 的嵌入式 Web 组件，将 Web 界面与更广泛的原生应用基础设施集成起来。
这些例子说明了两种技术的区别。Electron 通常用于构建完整的桌面应用，而 CEF 则经常用于为已经包含大量原生组件的应用引入 Web 功能。
不应将 CEF 视为冷门或过时的替代方案。它创立于 2008 年，早于 Electron，多年来一直广泛用于商业软件。它悠久的历史，以及在主要产品中的持续使用，证明嵌入 Chromium 仍然是桌面开发中的一种重要方式。
与此同时，Electron 围绕基于 JavaScript 的桌面应用构建了特别强大的生态系统。广泛的采用、成熟的工具，以及大型科技公司的参与，使它对使用 Web 技术开发新产品的团队很有吸引力。
这两个框架各有优势，因为它们面向不同的架构需求。
为什么 WebCatalog 选择 Electron
在 WebCatalog，我们选择使用 Electron 支撑跨平台桌面应用，因为它与我们产品的需求高度契合。
WebCatalog 允许用户将网站转化为桌面应用、独立管理多个账号，并在 macOS、Windows 和 Linux 上组织应用。我们的软件需要支持数千名不同开发者创建的网站，这些网站采用不同的身份验证系统、存储机制、浏览器 API 和 JavaScript 框架。
Electron 和 CEF 都提供一致的 Chromium 运行时，这对兼容性非常重要。与基于系统 WebView 的框架不同，它们允许我们在所支持的桌面平台上使用确定的 Chromium 版本。
不过，WebCatalog 并不是一个主要依靠原生功能、只需要嵌入浏览器组件的应用。浏览器功能是我们产品的核心。我们需要广泛控制窗口、会话、存储、权限、导航和应用生命周期行为。
Electron 为这些需求提供了成熟的 API。它的 BrowserWindow、webContents 和 session 接口让我们能够使用 JavaScript 和 TypeScript 构建类似浏览器的功能。持久化会话分区尤其重要，因为它们允许用户为同一网站上的多个账号维持相互独立的登录会话。
CEF 也提供了用于管理浏览器实例、请求、存储和原生集成的 API。原则上，许多相同的能力也可以通过 CEF 实现。不过，这样做需要我们自行构建和维护更多原生基础设施。
Electron 与 Node.js 的集成也契合我们的工程技术栈。我们可以使用 TypeScript 实现大部分桌面应用逻辑，在不同产品间共享代码，并利用 JavaScript 生态系统。
跨平台开发是另一个考量因素。WebCatalog 支持 macOS、Windows 和 Linux，涉及各平台特有的应用打包、集成和系统行为。Electron 成熟的 API 和分发工具减少了我们需要维护的原生代码量。
我们承认 Electron 会带来额外开销。捆绑 Chromium 会增加应用体积，基于浏览器的应用也需要谨慎管理资源。我们没有选择替换 Electron，而是专注于改进使用它的方式。
例如，我们引入了 APFS 克隆，以减少生成的 Mac 应用的磁盘占用，在不牺牲 Chromium 兼容性的前提下减少冗余存储。
我们的决定并不意味着 Electron 在所有情况下都优于 CEF。如果 WebCatalog 主要是一个只包含少量嵌入式 Web 界面的原生应用，那么 CEF 可能是极佳的选择。但由于我们的产品从根本上围绕 Web 应用和浏览器功能构建，Electron 提供了更高效、更易维护的基础。
CEF 的优势所在
虽然 Electron 是 WebCatalog 的首选，但对于需要与原生软件深度集成的应用来说，CEF 具有重要优势。
当开发者已经拥有成熟的 C++ 应用，并希望在不替换现有架构的情况下引入现代 Web 界面时，CEF 尤其具有吸引力。
对离屏渲染的支持是另一个显著优势。流媒体软件和游戏引擎等应用可能需要将 Web 内容直接渲染到自定义图形管线中，而不是传统的桌面窗口中。CEF 为这些用例提供了成熟的 API。
CEF 还让开发者能够充分控制浏览器集成。他们可以自定义请求处理、导航、JavaScript 绑定、资源加载，以及浏览器实例与原生应用组件之间的交互方式。
对于具备深厚原生开发经验的团队来说，这种灵活性可能比 Electron 的便利性更有价值。
以下情况值得考虑 CEF：
- 为现有原生应用添加 Web 界面。 开发者可以保留当前应用架构，在需要的地方嵌入 Chromium。
- 构建具有自定义渲染需求的软件。 离屏渲染允许将 Web 内容集成到图形管线和专用界面中。
- 与原生 C++ 功能深度集成。 CEF 提供原生 API，并允许精细控制浏览器行为。
- 维护成熟的 CEF 应用。 迁移到 Electron 可能需要大幅调整架构，却无法带来实质性收益。
- 结合原生界面与 Web 界面。 开发者可以在应用的特定部分使用 Chromium，同时在其他部分保留原生 UI 组件。
CEF 确实要求开发者对应用基础设施承担更多责任。开发者可能需要自行实现打包、更新、窗口管理和平台专属集成。
对于已经具备原生应用维护能力的团队来说，这可能完全合理。对于以 Web 开发为主、正在构建新桌面产品的团队来说，这可能会引入不必要的复杂性。
Electron 与 CEF：应该如何选择？
这两种技术都已成熟，仍在积极开发，并且能够支撑复杂的桌面软件。哪种选择更好，主要取决于你是在围绕 Web 技术构建新的桌面应用，还是在现有原生应用中嵌入 Web 功能。
| 你的优先需求 | 更合适的起点 | 原因 |
|---|---|---|
| 使用 JavaScript 或 TypeScript 开发新桌面应用 | Electron | 完整的应用框架 |
| 现有原生 C++ 应用 | CEF | 可集成到原生架构中 |
| 尽量减少原生开发 | Electron | Node.js 和 JavaScript API |
| 在原生窗口中嵌入 Web 内容 | CEF | 专为嵌入而设计 |
| 离屏渲染和自定义图形管线 | CEF | 专门的渲染 API |
| 丰富的桌面应用打包与更新工具 | Electron | 成熟的分发生态 |
| 与原生 C++ 代码直接集成 | CEF | 原生 C 和 C++ 接口 |
| 跨桌面平台保持 Chromium 一致性 | 两者皆可 | 两者都捆绑 Chromium |
| 复杂的浏览器会话管理 | 两者皆可 | 两者都提供浏览器管理能力 |
| 小体积应用安装包 | 两者均无固有优势 | 两者都分发 Chromium |
| 现有 JavaScript 工程团队 | Electron | 熟悉的开发技术栈 |
| 现有基于 CEF 的产品 | CEF | 避免不必要的迁移 |
对于大多数准备开发新跨平台桌面应用的 Web 开发者来说，Electron 通常是更实用的选择。它提供了构建完整产品所需的应用架构、原生集成、开发工具和分发生态，无需从零开始开发一切。
对于已经拥有原生应用，或需要专门的浏览器嵌入能力的开发者来说，CEF 往往是更好的选择。它的灵活性和直接的原生集成能力，使其特别适合游戏引擎、直播工具、工业应用，以及带有嵌入式 Web 界面的复杂原生产品等软件。
这两种技术都不存在天然更快或更安全的优势。这些特性在很大程度上取决于应用本身、其架构和实现质量。
总结
Electron 和 Chromium 嵌入式框架使用相同的底层浏览器技术，但它们解决的是不同的问题。
Electron 旨在让 Web 开发者更容易进行桌面应用开发。它将 Chromium、Node.js 和原生桌面 API 整合到一个框架中，使团队能够使用 JavaScript 和 TypeScript 构建复杂的应用程序。
CEF 旨在将 Chromium 嵌入其他应用程序。它提供对浏览器集成的更底层控制，对于需要基于 Web 的界面或特殊渲染能力的原生应用尤其有价值。
两者都已在主要生产软件中证明了自身价值。Visual Studio Code、Slack、Discord 和 Notion 等应用使用 Electron，而 Spotify、Steam 和 OBS Studio 等产品则使用 CEF。
在 WebCatalog，我们选择 Electron，是因为我们的产品从根本上围绕浏览器功能构建。它一致的 Chromium 运行时、成熟的浏览器管理 API 和 JavaScript 生态系统，让我们能够高效地开发和维护跨平台桌面应用。
对于开发原生应用的开发者来说，CEF 仍然是出色的选择，尤其是当需求是将 Chromium 嵌入现有架构，而不是将其作为整个产品的基础时。
最终的决定取决于你要构建什么。如果你想使用 Web 技术创建完整的桌面应用，Electron 通常是更好的起点。如果你想为原生应用添加 Chromium，CEF 很可能是更合适的工具。
