Electron 在鸿蒙 PC 上启动慢？我把冷启动从 7 秒压到 1.5 秒的完整记录

Electron 在鸿蒙 PC 上启动慢？我把冷启动从 7 秒压到 1.5 秒的完整记录

上周把 Electron 应用移植到鸿蒙 PC 上跑了一圈，结果用户反馈说"启动慢得像在加载 PS"。我掐表测了一下，从双击图标到主窗口完全可交互，居然要 7 秒多。这放在 Windows 上也就 2 秒出头，鸿蒙 PC 怎么就这么拉胯？我花了三天时间用各种手段往下压，最终把冷启动干到了 1.5 秒左右。下面把完整过程记录下来，避免你们再走弯路。

先搞清楚时间花在哪了

拿到性能问题，我的习惯是不打无准备之仗。Electron 启动链路很长：主进程初始化 → 创建 BrowserWindow → 加载入口 HTML → 渲染进程启动 → 预加载脚本执行 → 前端框架初始化 → 首屏渲染完成。到底哪一步在鸿蒙 PC 上慢得离谱？不量化一下就是瞎猜。

我在主进程和渲染进程里埋了一堆performance.mark和console.time，写了个简单的打点模块：

// utils/perf-timer.jsconst{performance}=require('perf_hooks');constfs=require('fs');constpath=require('path');classPerfTimer{constructor(){this.marks=[];this.logFile=path.join(require('electron').app.getPath('userData'),'startup-perf.json');}mark(label){consttime=performance.now();this.marks.push({label,time:Math.round(time*100)/100});console.timeLog?console.timeLog('startup',label):console.log(`[startup]${label}:${time.toFixed(2)}ms`);}save(){fs.writeFileSync(this.logFile,JSON.stringify(this.marks,null,2));}diff(from,to){consta=this.marks.find(m=>m.label===from);constb=this.marks.find(m=>m.label===to);returna&&b?(b.time-a.time).toFixed(2)+'ms':'N/A';}}module.exports=newPerfTimer();

主进程入口main.js里这样用：

constperf=require('./utils/perf-timer');const{app,BrowserWindow}=require('electron');perf.mark('app-before-ready');app.whenReady().then(()=>{perf.mark('app-ready');constwin=newBrowserWindow({width:1280,height:800,show:false,webPreferences:{preload:require('path').join(__dirname,'preload.js'),contextIsolation:true,nodeIntegration:false}});perf.mark('window-created');win.loadFile('index.html');perf.mark('load-file-called');win.webContents.on('did-finish-load',()=>{perf.mark('did-finish-load');win.show();perf.mark('window-shown');perf.save();// 输出各阶段耗时console.log('=== 启动耗时分析 ===');console.log('主进程准备:',perf.diff('app-before-ready','app-ready'));console.log('窗口创建:',perf.diff('app-ready','window-created'));console.log('页面加载:',perf.diff('window-created','did-finish-load'));console.log('总耗时:',perf.diff('app-before-ready','window-shown'));});});

跑了几遍取平均值，结果让我有点意外。主进程初始化（app-before-ready到app-ready）居然占了 3.8 秒，页面加载才 2.1 秒，窗口创建反倒只有 200 毫秒。看来主进程启动才是罪魁祸首，而不是我以为的渲染进程慢。

第一刀：砍掉主进程的 require 洪水

打开主进程的main.js，我发现自己犯了一个低级错误——为了图省事，把所有模块都在文件顶部一次性require了：

// 优化前 —— 典型的 require 洪水const{app,BrowserWindow,ipcMain,dialog,Menu,Tray,nativeImage}=require('electron');constpath=require('path');constfs=require('fs');constos=require('os');constlog=require('./utils/logger');constconfig=require('./config/app-config');constupdateChecker=require('./services/update-checker');consttrayManager=require('./services/tray-manager');constmenuBuilder=require('./services/menu-builder');constshortcutManager=require('./services/shortcut-manager');constharmonyosBridge=require('./native/harmonyos-bridge');

问题出在哪？Electron 打包后，Node.js 的模块解析在鸿蒙 PC 上比 Windows 慢不少（我猜测跟文件系统实现有关）。这一堆模块里，updateChecker、trayManager、harmonyosBridge在应用启动阶段根本用不上，它们完全可以等到窗口创建完成后再加载。

优化策略很简单：把非核心模块改成懒加载：

// 优化后 —— 只保留启动必须的模块const{app,BrowserWindow}=require('electron');constpath=require('path');// 延迟加载：这些模块启动阶段不需要letupdateChecker,trayManager,menuBuilder,shortcutManager,harmonyosBridge;functiongetUpdateChecker(){if(!updateChecker)updateChecker=require('./services/update-checker');returnupdateChecker;}functiongetHarmonyosBridge(){if(!harmonyosBridge)harmonyosBridge=require('./native/harmonyos-bridge');returnharmonyosBridge;}app.whenReady().then(()=>{// 只创建窗口，其他服务延迟初始化createWindow();// 窗口显示后 500ms 再初始化非核心服务setTimeout(()=>{getUpdateChecker().check();getHarmonyosBridge().init();},500);});

这一刀砍下去，主进程初始化从 3.8 秒降到 1.9 秒。效果立竿见影，但也引入了一个坑——harmonyosBridge内部在require时会执行一段原生模块的探测逻辑，延迟加载确实快了，但如果在探测完成前就有 IPC 调用进来，会直接报错。我后来给它加了个 Promise 锁才解决：

// native/harmonyos-bridge.jsletinitPromise=null;functioninit(){if(initPromise)returninitPromise;initPromise=newPromise((resolve)=>{// 原生模块探测逻辑...setTimeout(()=>resolve(true),100);});returninitPromise;}functioncallNative(method,args){returninit().then(()=>{// 实际调用...});}module.exports={init,callNative};

第二刀：预加载脚本瘦身

预加载脚本 (preload.js) 是 Electron 的安全桥梁，但它会在每个渲染进程创建时执行。我的preload.js最初有 400 多行，里面塞了一大堆 IPC 通道注册、工具函数、甚至还有一些常量配置。在鸿蒙 PC 上，这段脚本的执行时间比 Windows 长了将近一倍。

我的做法是把preload.js拆成"核心必加载"和"按需注入"两部分：

// preload.js —— 只保留最核心的 API 暴露const{contextBridge,ipcRenderer}=require('electron');contextBridge.exposeInMainWorld('electronAPI',{// 只有这 3 个是首屏必须用到的invoke:(channel,...args)=>ipcRenderer.invoke(channel,...args),on:(channel,callback)=>ipcRenderer.on(channel,callback),platform:process.platform});

那些不急着用的 API，改成在渲染进程里动态请求：

// renderer.js —— 首屏渲染完成后再加载扩展 APIasyncfunctionloadExtendedAPI(){constextended=awaitwindow.electronAPI.invoke('get-extended-api-manifest');// 按需注册...}window.addEventListener('DOMContentLoaded',()=>{renderApp();// 先渲染核心界面setTimeout(loadExtendedAPI,0);// 空闲时加载扩展});

预加载脚本从 400 行砍到 30 行，执行时间从 800 毫秒降到 120 毫秒。这里有个细节：鸿蒙 PC 的 Chromium 版本可能跟 Windows 有差异，contextBridge的序列化性能表现不太一致，所以尽量减少传递的数据量总没错。

第三刀：加个 Splash 屏做"心理加速"

说实话，Splash 屏并不能真正减少启动时间，但它能改变用户对启动时间的感知。我从双击图标到窗口显示之间有 1 秒多的空窗期，用户会怀疑"是不是点错了"。加一个轻量的 Splash 窗口，让用户立刻看到反馈，体验好很多。

// splash.jsconst{BrowserWindow}=require('electron');constpath=require('path');letsplash=null;functionshowSplash(){splash=newBrowserWindow({width:400,height:300,frame:false,alwaysOnTop:true,transparent:true,skipTaskbar:true,webPreferences:{nodeIntegration:false,contextIsolation:true}});splash.loadFile('splash.html');}functioncloseSplash(){if(splash&&!splash.isDestroyed()){splash.close();splash=null;}}module.exports={showSplash,closeSplash};

在main.js里调用：

const{showSplash,closeSplash}=require('./splash');app.whenReady().then(()=>{showSplash();// 立刻显示 SplashconstmainWindow=newBrowserWindow({show:false,// 先不显示主窗口// ...});mainWindow.loadFile('index.html');mainWindow.webContents.on('did-finish-load',()=>{mainWindow.show();closeSplash();// 主窗口就绪后关闭 Splash});});

splash.html要尽量轻量——我只放了一个 CSS 动画和一个 logo，没有任何 JS 框架。文件大小控制在 15KB 以内，加载几乎是瞬时的。

第四刀：鸿蒙 PC 特有的进程优先级调优

这一步是我踩坑最狠的地方。我查到鸿蒙 PC（OpenHarmony 桌面版）支持通过ohos.app相关 API 设置进程优先级，于是兴冲冲地在主进程里加了一段代码，想把渲染进程的优先级调高：

// 坑货代码，不要直接抄！const{exec}=require('child_process');exec('renice -n -5 -p '+process.pid);// 在鸿蒙 PC 上这段直接报错

鸿蒙 PC 的进程管理跟 Linux 并不完全一样，renice命令不存在，而且沙箱权限也不允许随意修改优先级。我反复试了五六次，查阅了华为开发者论坛的零散帖子，最后发现 Electron 在鸿蒙 PC 上跑的是基于 OpenHarmony 的容器环境，进程调度由系统统一管控，应用层没法直接干预。

不过也不是完全没办法。虽然不能调优先级，但可以通过减少进程数量来降低调度开销。Electron 默认会为每个窗口创建一个独立的渲染进程，如果你的应用有多个隐藏的 Background Window，它们会吃掉不少启动资源。我把几个不急着用的后台服务合并到了一个专门的隐藏窗口里，减少了两个多余的渲染进程：

// 合并后台服务到一个隐藏窗口constbackgroundWindow=newBrowserWindow({show:false,webPreferences:{nodeIntegration:true,contextIsolation:false,preload:path.join(__dirname,'preload-background.js')}});backgroundWindow.loadFile('background.html');// background.html 内部通过 iframe 或模块化方式加载各个后台服务

这一招减少了进程创建开销，主进程初始化又快了 300 毫秒左右。

优化效果汇总

我把优化前后的数据整理了一下，对比相当明显：

用户感知启动时间指的是"从双击图标到界面可交互"的完整时间。Splash 屏的贡献主要体现在"心理层面"——用户不再觉得那 1.5 秒很难熬。

几个需要注意的坑

优化启动速度的过程中，我还遇到了一些杂七杂八的问题，一并记下来：

不要把所有优化手段一次性堆上去。我一开始同时改了 require 策略、预加载瘦身、还加了个 V8 缓存，结果应用在鸿蒙 PC 上直接白屏了。排查了两个小时才发现是 V8 快照缓存跟鸿蒙的 Chromium 版本不兼容。建议每改一个优化点就测一遍，稳扎稳打。

Splash 屏的关闭时机要把握好。如果主窗口还没完全渲染就关闭 Splash，会出现一段"桌面空白期"；如果关太晚，用户会觉得 Splash 碍事。我的做法是在did-finish-load事件触发后延迟 150 毫秒再关闭，给首次渲染留一点缓冲。

鸿蒙 PC 的userData路径跟 Windows 差异很大，如果你在启动阶段读写配置文件，路径解析可能耗时。建议把配置缓存到内存里，避免重复读盘。

写在最后

Electron 应用在鸿蒙 PC 上的启动性能问题，本质上不是 Electron 本身的锅，而是跨平台移植时各种环境差异叠加的结果。文件系统性能、进程调度策略、Chromium 版本差异，这些因素单独看都不致命，但凑在一起就能把启动时间拖垮。我的建议是：先量化、再动手，用performance.mark找到真正的瓶颈，别像我一样一开始瞎猜是渲染进程慢，结果在主进程上浪费了半天时间。

如果你也在做 Electron + 鸿蒙 PC 的适配，欢迎评论区交流。这块目前资料不多，基本都是靠开发者互相填坑。

本文遵循 MIT 协议，转载请注明出处。欢迎转载，但请保留原文链接及作者信息。