Electron

多年来，软件开发社区中一直进行着一场激烈的辩论：Electron 还是原生 (Native)。现代桌面巨头如 Visual Studio Code、Slack、Discord 和 Teams 都基于 Electron 构建，这个框架允许开发人员使用 Web 技术构建跨平台的桌面应用程序。 与此同时，用户和开发人员都经常抱怨 Electron 应用程序“臃肿”、“迟钝”且“消耗内存 (RAM)”。而另一边则是原生应用程序，它们专门针对目标操作系统编写（在 macOS 上使用 Swift/Objective-C，在 Windows/Android 上使用 Kotlin/C#，在 Linux 上使用 C++/Qt）。 那么，性能差异真的存在吗？还是夸大其词？在本文中，我们将深入探讨这两种方法的架构、内存使用、启动时间以及资源占用，以找出答案。 1. 架构蓝图：核心差异 要理解性能差距，我们首先必须了解这些应用程序在底层的运行方式。 Electron：盒子里的浏览器 Electron 应用程序本质上是 Chromium（Google Chrome 背后的开源浏览器）与 Node.js 运行时的打包实例。 主进程 (Main Process) 运行 Node.js 环境，管理应用程序生命周期和系统交互。 渲染进程 (Renderer Process) 运行 Chromium 实例，像网页一样渲染用户界面。 这意味着当您运行单个 Electron 应用程序时，您实际上是同时运行了一个 Web 浏览器和一个后端服务器。 原生：直接与硬件对话 原生应用程序直接编译为机器代码，或针对开销极小的优化虚拟机（如 JVM 或 .NET CLR）。它们使用操作系统的原生 UI 渲染引擎（如 macOS 上的 Cocoa 或 Windows 上的 WinUI），而不是在浏览器容器中渲染 HTML。

Electron 是使用 HTML、CSS 和 JavaScript 等 Web 技术构建跨平台桌面应用程序最流行的框架之一。在底层，Electron 采用多进程架构，由一个主进程（运行 Node.js）和一个或多个渲染进程（运行 Chromium 来渲染用户界面）组成。 由于安全风险，现代 Electron 应用程序会将渲染进程与操作系统隔离。这意味着您无法直接从渲染器 UI 访问 Node.js 模块或系统资源（例如读取文件或查询数据库）。 为了安全地桥接这一差距，Electron 使用了进程间通信 (IPC)。 在本指南中，我们将解释 Electron IPC 的工作原理，并通过真实的、可用于生产的代码示例来探索三种基本的通信模式。 1. 渲染器到主进程（单向 / One-Way） 当渲染器想要向主进程发送命令或操作而不等待任何响应时，使用此模式。一个常见的示例是单击 UI 中的按钮以最小化或关闭应用程序窗口。 让我们看看这如何在三个关键文件中实现：main.js、preload.js 和 renderer.js。 主进程 (main.js) 我们使用 ipcMain.on 来监听来自渲染进程的事件。 const { app, BrowserWindow, ipcMain } = require('electron'); const path = require('path'); function createWindow() { const win = new BrowserWindow({ width: 800, height: 600, webPreferences: { preload: path.join(__dirname, 'preload.js'), contextIsolation: true, nodeIntegration: false } }); win.loadFile('index.html'); } // 监听来自渲染器的 'close-app' 事件 ipcMain.on('close-app', () => { app.quit(); }); 预加载脚本 (preload.js) 我们使用 contextBridge.exposeInMainWorld 向渲染器暴露一个安全的包装器，而不暴露整个 ipcRenderer 模块。