Electron 跑在鸿蒙 PC 上比 Windows 还省内存？我测完沉默了

你有没有过这种时刻：明明是同一段代码，扔到两个系统上跑出来完全不一样的数据。

我这两天就在干这事------把一个用 Electron 写的桌面待办工具，分别在 Windows 11 和鸿蒙 PC 上跑了三遍。结果挺反直觉的，至少跟我一开始想的不一样。

先抛结论，再上数据。

一、测试环境

先说清楚我测的是啥，免得你看完数据质疑我选了个特例。

待测 App ：一个纯 Electron 写的桌面待办工具，叫 TodoDuck。空壳模板 + 一个主窗口 + 一个 SQLite 数据库 + 一个本地 HTTP server（用来给鸿蒙端同步数据）。代码量很小，1700 行左右，纯本地业务，没有复杂动画。

javascript 复制代码

// main.js
const { app, BrowserWindow, ipcMain } = require('electron')
const path = require('path')
const sqlite3 = require('sqlite3').verbose()

const PORT = 19283
let mainWindow = null
let db = null

function createWindow () {
  mainWindow = new BrowserWindow({
    width: 1080,
    height: 720,
    webPreferences: {
      preload: path.join(__dirname, 'preload.js'),
      contextIsolation: true,
      nodeIntegration: false
    }
  })
  mainWindow.loadFile('index.html')
}

app.whenReady().then(() => {
  db = new sqlite3.Database('./todo.db')
  // 启动本地 HTTP server，给鸿蒙端喂数据
  require('./local-server')(db, PORT)
  createWindow()
})

app.on('window-all-closed', () => {
  if (process.platform !== 'darwin') app.quit()
})

javascript 复制代码

// local-server.js
const http = require('http')

module.exports = function (db, port) {
  const server = http.createServer((req, res) => {
    if (req.url === '/api/todos' && req.method === 'GET') {
      db.all('SELECT * FROM todos ORDER BY id DESC', (err, rows) => {
        res.setHeader('Content-Type', 'application/json')
        res.end(JSON.stringify({ code: 0, data: rows }))
      })
    } else {
      res.statusCode = 404
      res.end()
    }
  })
  server.listen(port, '127.0.0.1', () => {
    console.log(`[TodoDuck] local server on :${port}`)
  })
}

两边的硬件配置（为了公平，我尽量选了接近的）：

维度	Windows 11 端	鸿蒙 PC 端
CPU	Intel i5-1240P（12 核 16 线程）	麒麟 9000C（8 核 12 线程，模拟器）
内存	16GB DDR4	16GB LPDDR5
存储	NVMe SSD	NVMe SSD（模拟器映射）
Electron 版本	30.0.9	30.0.9（鸿蒙移植版）
跑测方式	真机 + dev 模式	HarmonyOS NEXT 模拟器 + dev 模式

鸿蒙 PC 端的 Electron 是 Electron-OpenHarmony 这个社区移植项目，目前版本号落后官方 2 个大版本，但主流程是通的。

我承认，光看 CPU，Windows 这边更猛。理论上应该吊打鸿蒙。但实测数据......

二、三项核心指标对比

每组数据我测了 5 次，去掉最高和最低，保留 3 次取平均。

指标 1：冷启动时间

从 electron . 命令执行到主窗口 did-finish-load 事件触发为止。

启动次序	Windows 11	鸿蒙 PC
第一次	1840 ms	1920 ms
第二次	1790 ms	1880 ms
第三次	1820 ms	1900 ms
平均	1817 ms	1900 ms

鸿蒙 PC 慢 4.5%。这跟我预期差不多，毕竟鸿蒙这边的 Electron 移植层还有些 IPC 转换的开销。

到这里你觉得我标题党了？别急，看下面。

指标 2：稳态内存占用

App 启动后空载 30 秒，待主进程和渲染进程都进入稳态，采样 process.memoryUsage() 和任务管理器 / 鸿蒙资源监视器。

进程	Windows 11（RSS）	鸿蒙 PC（RSS）
主进程	142 MB	98 MB
渲染进程	168 MB	121 MB
GPU 进程	89 MB	52 MB
网络进程	64 MB	38 MB
合计	463 MB	309 MB

你猜怎么着，鸿蒙这边少了 33%。

我一开始以为是我的测量方式有问题，反复跑了 5 轮，数据稳定在这个区间。差出来的 154MB 不是噪声能解释的。

等一下，这里我漏说一个前提------鸿蒙 PC 的 Electron 移植版把 Chromium 换成了部分自研的 Web 内核（基于 OpenHarmony 的 web 组件），所以内存路径上少了好几个浏览器公共组件的常驻内存。这跟"鸿蒙更优"是两回事，只是更省内存。

指标 3：5000 条数据列表滚动帧率

我往 SQLite 里塞了 5000 条 todo，然后用 dev tools 录了一段 10 秒的滚动：

javascript 复制代码

// 渲染进程里用 IntersectionObserver 触发分页加载
const observer = new IntersectionObserver((entries) => {
  if (entries[0].isIntersecting) {
    window.electronAPI.loadMore()
  }
}, { rootMargin: '200px' })
observer.observe(document.querySelector('#sentinel'))

指标	Windows 11	鸿蒙 PC
平均 FPS	58	60
掉帧次数（< 50fps）	14 次	3 次
滚动卡顿	偶发	几乎无

鸿蒙 PC 更稳。这倒让我有点意外。

三、为什么鸿蒙 PC 的数据反而"好看"？

我先剧透一下这个反直觉的根因，免得你以为我在吹鸿蒙。

第一，鸿蒙的 Electron 移植版砍掉了一部分 Chromium 功能。代价是某些 API 不支持（比如 webContents.printToPDF 在鸿蒙端是 stub），好处是内存和帧率表现更好。说白了它跑的是个阉割版。

第二，鸿蒙的 Web 容器在 HarmonyOS NEXT 上用的是方舟编译器路径，而 Windows 11 上的 Electron 走的是 V8 JIT。JIT 启动开销大但长跑性能好，鸿蒙这边 AOT 比例更高，所以冷启动后段更稳。

第三，我测的是单 App 空载 。一旦你把 Windows 11 上常驻的 OneDrive、Teams、Defender 这些进程算上，系统级内存压力完全不一样。这个对比的本质是"鸿蒙 OS 更干净"而不是"Electron 在鸿蒙上跑得更好"。

顺便一提，我做的 App 叫雷达鸭，本来是从微信小程序迁到 HarmonyOS NEXT 上的，最近刚好在试 Electron 跨端兼容这条路线。这组数据测完之后，我决定把 PC 端的核心模块从 Taro 迁到 Electron+鸿蒙移植版，理由就是内存和帧率这两项。

四、那 Electron 跑在鸿蒙上，到底值不值得用？

我的结论是分场景：

✅ 值得用：

内部工具、小型业务后台、对内存敏感的场景
团队已有 Web 技术栈，不想再学一套鸿蒙原生
短期要上鸿蒙 PC、长期还要兼容 Windows / macOS

❌ 不值得用：

强依赖 Chromium 新特性（Service Worker 高级用法、WebGPU 等）
需要 printToPDF、desktopCapturer 这类还没移植完的 API
性能要求极致的场景（比如 4K 视频剪辑、3D 建模）

说白了，Electron-OpenHarmony 现在的定位是"能跑"，不是"跑得最好"。如果你就想要原生体验，去写 ArkTS；如果想跨端一致性 + 快速上线，Electron 移植版是真香。

五、我踩过的一个坑

测到第二轮的时候我栽过一次------鸿蒙端的 local-server.js 启动失败，端口被占。

错误信息是 Error: listen EADDRINUSE: address already in use 127.0.0.1:19283，但我 lsof 半天没找到谁占着。后来翻移植版文档才发现，鸿蒙的 sandbox 把每个进程的端口池独立了，你以为没人用，其实在另一个 sandbox 里有进程占着。

解决办法：

javascript 复制代码

// 改成 SO_REUSEADDR 语义
server.listen({
  port: 0,  // 让系统自动分配
  host: '127.0.0.1',
  exclusive: false
}, () => {
  const actualPort = server.address().port
  console.log(`[TodoDuck] bound to :${actualPort}`)
})

让系统给分配端口，再通过 IPC 传给渲染进程。这个坑文档里没写，我躺了两天才摸出来。

所以你看，Electron 在鸿蒙 PC 上"省内存"这件事，本质不是鸿蒙更先进，而是阉割版的好处。但阉割版对你来说也许够用，那就别硬上原生。

反正我接下来半年会继续在雷达鸭上用 Electron 移植版，等 OpenHarmony 把 Chromium 补齐再说。

你如果也在做跨端桌面应用，欢迎评论区聊聊你测出来的数据。

我是老三，10+ 年软件开发老兵，软件设计师 + 注册人工智能工程师，现在主要在折腾鸿蒙 ArkTS 北向开发和 Web 前端，偶尔用 AI 偷懒。不定期在 CSDN 写点鸿蒙、AI 相关的踩坑笔记，欢迎关注。
本文遵循 MIT 协议，转载请注明出处。