应用启动速度直接影响用户的第一印象。如果你的 Electron 应用在点击图标后需要好几秒才显示窗口，用户很可能在还没看到界面之前就已经失去了耐心。本节梳理了导致 Electron 应用启动慢的几个常见瓶颈，并给出对应的排查思路和优化方案。
19.5.1 启动流程的时间线
首先需要理解 Electron 应用从“双击图标”到“窗口完全可用”经历的阶段。粗略划分如下：
- 操作系统加载可执行文件：启动 Electron 二进制，加载动态链接库。
- 主进程初始化：执行
main.js，require 各种模块，调用app.whenReady()。 - 创建窗口：调用
new BrowserWindow()，初始化 Chromium 渲染进程。 - 加载页面内容：渲染进程加载
index.html、解析 JS/CSS、执行框架初始化代码。 - 首屏渲染完成：用户看到完整的界面并能够交互。
任何一个阶段出现瓶颈，都会拖长整体启动时间。排查时需要有意识地将这些阶段区分开来，分别测量耗时。
19.5.2 瓶颈一：主进程启动阶段的依赖加载
主进程在 app.whenReady() 之前通常会 require 大量模块。如果使用了体积较大的 npm 包，或者引入了需要编译原生模块的库（例如 better-sqlite3、node-pty），其加载时间可能显著拖慢启动。
排查方法：
在开发环境下，可以在 main.js 的最顶部和 app.whenReady() 前后分别打点：
console.time('main-start');
const { app } = require('electron');
// 其他 require...
console.timeLog('main-start', 'after-requires');
app.whenReady().then(() => {
console.timeEnd('main-start');
// 创建窗口...
});如果 after-requires 之前的耗时很长，说明存在某些模块在导入时执行了大量同步操作（如文件解析、网络请求等）。可以使用 Node.js 的 --inspect 标志启动应用，通过 Chrome DevTools 的 Performance 面板分析 require 耗时。
优化建议：
- 将非必须的初始化逻辑延迟到
app.whenReady()之后，甚至使用requestIdleCallback或setImmediate异步执行。 - 对于需要动态加载的模块，使用按需
require（如在窗口创建时才加载特定功能模块）。 - 评估替换体积庞大或初始化慢的依赖，例如用
node-sqlite3的同步初始化可能会阻塞，考虑使用异步版本。
19.5.3 瓶颈二：创建窗口的时机与开销
new BrowserWindow() 本身会启动一个新的渲染进程，这个过程涉及 Chromium 子进程的 fork、GPU 进程的启动、沙箱初始化等，有一定成本。如果在应用中创建多个窗口，全部在启动时同步创建，会使启动时间线性增加。
此外，某些窗口选项（如 transparent: true 或 frame: false）会触发额外的合成器创建，导致更长的初始化时间。如果在创建窗口前开启了 DevTools (win.webContents.openDevTools())，也会增加开销。
排查方法：
在主进程中记录创建窗口前后的时间戳：
console.time('create-window');
const win = new BrowserWindow({ /* options */ });
console.timeEnd('create-window');如果发现单个窗口创建耗时超过几百毫秒，可以检查窗口选项是否必要，以及是否过早调用了某些重操作。
优化建议：
- 避免在启动时创建非必需的隐藏窗口。如果有托盘或后台服务，只在需要时创建。
- 除非必要，不使用
transparent: true，因为它会导致窗口使用离屏渲染，增加绘制复杂度。 - 对于多窗口应用，可以采用“主窗口优先，辅助窗口按需创建”的策略。
19.5.4 瓶颈三：渲染进程的加载阻塞
渲染进程加载页面（loadURL 或 loadFile）是启动阶段最耗时的部分之一。阻塞通常来源于：
- 同步阻塞脚本：HTML 中的
<script>标签（不带async/defer）会阻塞解析，如果某个第三方库很大且同步执行，会显著延迟首屏渲染。 - 大量/体积过大的 CSS 和字体：浏览器需要下载（如果是网络资源）并解析 CSS，构建 CSSOM，这会与 DOM 构建互相阻塞。自定义字体文件如果过大，也可能先展示空白文本。
- 框架初始化耗时：React、Vue 等框架在执行
createApp或ReactDOM.render之前，可能会进行路由初始化、状态管理初始化，甚至发起数据请求。如果这些操作是同步大计算量任务，或者依赖的本地数据加载慢，都会影响白屏时间。
排查方法：
在渲染进程的 <head> 最前方打点，并使用 performance API 记录关键里程碑：
console.time('renderer-load');
window.addEventListener('DOMContentLoaded', () => {
console.timeLog('renderer-load', 'dom-ready');
});
window.addEventListener('load', () => {
console.timeEnd('renderer-load');
});对于框架应用，可以在 main.js（前端入口）开始处打点，并在首屏组件挂载后记录时间。结合 Chrome DevTools 的 Performance 录制，可以清晰地看到脚本执行、样式计算、布局和绘制的时间线。
优化建议：
- 使用代码分割（Code Splitting）减少首屏需要加载的 JS 体积。Webpack、Vite 等打包器都支持动态
import()。 - 将非关键资源（如落地页才需要的图表库）延迟加载。可以利用
requestIdleCallback或路由懒加载。 - 压缩和优化字体文件，使用
font-display: swap避免白屏，或者预加载关键字体。 - 对于本地文件加载（
loadFile），确保 HTML 和资源文件没有被意外地同步阻塞（例如在主进程中用fs.readFileSync读取大文件再注入，这是错误的做法，应使用协议或流式处理）。
19.5.5 瓶颈四：异步初始化未合理编排
很多应用在窗口显示后会执行大量的异步初始化：连接数据库、读取用户配置、检查更新、请求远程数据等。如果这些任务全部在 did-finish-load 或组件挂载后立即发起且没有优先级区分，会造成首屏交互卡顿（尽管技术上是异步的，但大量并发任务可能争抢 CPU 和 I/O）。
更糟糕的是，如果主进程因为等待某一个异步任务（比如等待数据库连接建立）才创建窗口，就会让用户一直盯着空桌面，典型错误代码如下：
// 错误示例
const db = await initDatabase(); // 可能耗时2秒
createWindow();这会导致启动时间完全被这个任务绑架。
优化建议：
- 将窗口创建与异步初始化解耦。主进程应该尽快创建窗口并加载页面，让用户看到界面（即使界面显示“加载中”）。异步初始化可以在窗口创建后并行执行，并通过 IPC 通知渲染进程更新状态。
- 在渲染进程中，对并发请求进行优先级排序，确保核心数据先加载，非紧急任务（如埋点上报、远端配置拉取）可以延迟。
- 利用
webContents的did-finish-load事件，配合ipc进行协调，但避免在此事件中执行重 I/O。
19.5.6 瓶颈五：系统级干扰
有时启动慢并非应用自身代码的问题，而是受系统环境影响：
- 杀毒软件扫描：每次启动新进程时，杀毒软件会检查可执行文件和加载的 DLL/动态库。对于 Electron（包含大量文件），这可能造成显著延迟。可以在开发阶段临时禁用杀软对照测试。
- 机械硬盘与冷启动：如果应用安装在机械硬盘上，且操作系统刚启动，读取 Chromium 的二进制和资源文件会很慢。使用固态硬盘可以大幅改善。
- 网络代理或 VPN：如果应用启动时有网络请求（如检查更新、加载远程配置），而网络环境异常（代理未就绪、DNS 慢），会因为超时等待而拖慢启动。这类操作都应该有合理的超时设置（比如 5 秒）和失败降级，并明确放在页面加载之后。
19.5.7 实用的性能测量与监控
要在真实环境中持续监控启动速度，可以借助 Electron 内置的 app.getAppMetrics() 或第三方工具。可以在主进程中记录从进程启动到窗口首次绘制的总时间：
const startTime = Date.now();
app.on('ready', () => {
const win = createWindow();
win.webContents.on('did-finish-load', () => {
const loadTime = Date.now() - startTime;
console.log(`启动耗时: ${loadTime}ms`);
});
});对于更精细的测量，可以使用 webContents 的 'ready-to-show' 事件在窗口准备好显示时触发（避免白屏闪烁），并结合此事件来衡量从创建窗口到“可显示”的时间。
将启动时间作为一项关键的性能指标，纳入自动化测试或持续集成流程中，可以确保每次改动不会显著劣化启动体验。
通过逐步拆解启动流程，定位到具体瓶颈点，然后运用上述优化手段，大多数 Electron 应用的启动速度都能被控制在 1-2 秒内，给予用户流畅的第一印象。