Electron 应用的界面性能几乎完全取决于 Chromium 的渲染效率。即使你的主进程逻辑再精妙，如果渲染进程内的 UI 卡顿、动画掉帧、滚动不跟手，用户的第一印象仍然是“这应用很慢”。本节聚焦三个直接影响渲染性能的核心概念：重排（Reflow）、重绘（Repaint）、合成层（Compositing Layers）以及如何拆分长任务，让你的 Electron 应用在视觉上顺滑如原生。
20.3.1 理解重排与重绘
浏览器的渲染流水线大致可以概括为：解析 HTML/CSS → 构建 DOM 树和 CSSOM 树 → 生成渲染树 → 布局（Layout，即重排）→ 绘制（Paint，即重绘）→ 合成（Composite）。其中，重排和重绘是开销最大、最容易触发的两个阶段。
- 重排：当元素的几何属性（宽高、位置、边距等）发生变化时，浏览器需要重新计算渲染树中受影响部分的布局，然后重新绘制。重排总是会触发重绘，而且会波及周围乃至整个文档。例如，修改一个元素的
width、添加或删除 DOM 节点、读取offsetHeight等布局属性都可能导致重排。
- 重绘：当元素的视觉样式（颜色、背景、可见性等）改变，但布局不受影响时，浏览器只需要重新绘制该元素的外观，而不需要重新计算几何信息。例如，修改
color或background-color会触发重绘，但通常不会重排。
为什么它们会拖慢性能？
浏览器的主线程负责执行 JavaScript、计算样式、布局、绘制等任务。一次重排或重绘可能会耗去十几甚至几十毫秒，而人眼感知到流畅动画的最低帧率是 60fps，即每帧只有 16.6ms 的预算。如果在某一帧里发生了大面积的重排，主线程被长期占用，页面就无法及时更新，造成掉帧和卡顿感。在 Electron 应用中，由于用户往往对“桌面级体验”有更高期待，这种卡顿会格外扎眼。
实用优化建议
- 批量修改样式
尽量通过修改 CSS 类名来一次性完成多个样式的变更，而不是逐个属性设置。这样做可以将多次重排合并为一次。
// 不推荐：多次触发重排
element.style.width = '100px';
element.style.height = '100px';
element.style.margin = '10px';
// 推荐：使用 class 切换
element.classList.add('new-style');
- 使用
documentFragment或离线 DOM 操作
当需要插入大量 DOM 节点时，先在内存中构建完整结构，最后一次性添加到文档中。这可以避免反复的重排。
const fragment = document.createDocumentFragment();
for (let i = 0; i < 1000; i++) {
const div = document.createElement('div');
div.textContent = `Item ${i}`;
fragment.appendChild(div);
}
document.body.appendChild(fragment);
- 避免强制同步布局
在修改样式后立即读取布局属性（如 offsetWidth、scrollTop），会强制浏览器同步执行重排，这称为“布局抖动”。应当把读和写操作分离成两个阶段。
// 布局抖动示例
elements.forEach(el => {
el.style.width = '100px';
console.log(el.offsetHeight); // 每次都强制重排
});
// 优化：先批量读，再批量写
const heights = elements.map(el => el.offsetHeight);
elements.forEach((el, i) => {
el.style.width = heights[i] + 'px';
});
- 善用 CSS 的
transform和opacity
这两个属性的变化不会触发布局或绘制，只会引发合成。对于动画、拖拽、滚动等高频场景，优先使用 transform: translate() 而非修改 left/top，使用 opacity 而非修改 visibility 或 color 实现淡入淡出。
20.3.2 合理利用合成层
Chromium 的合成线程可以将页面的不同部分绘制到不同的图层中，然后由 GPU 进行合成。当一个元素被提升为合成层后，它的变动（如移动、透明度变化）就可以独立于其他层进行，不会导致整个页面的重排或重绘。然而，合成层并非越多越好：每个层都会消耗额外的 GPU 内存，过多层反而可能导致合成开销暴增，甚至引发“层爆炸”。
如何查看和创建合成层
在 DevTools 中打开 Layers 面板（在 More tools 菜单中），可以查看当前页面被拆分成的所有合成层。同时，覆盖 Rendering 工具中的“Layer borders”可以直观看到哪些元素拥有自己的层。
元素满足以下条件之一时，通常会被提升为合成层：
- 3D transform（
transform: translateZ(0)等） <video>、<canvas>等特殊元素- 使用了
will-change属性 - 包含需要合成的 CSS 滤镜
- 被作为其他合成层的裁剪容器
合成层的合理使用
- 用
will-change提前通知浏览器
对于即将发生频繁变化的元素（如即将执行动画的 div），可以先设置 will-change: transform; 或 will-change: opacity;，浏览器会提前为该元素创建合成层，避免动画开始时的层创建延迟。
.animated-box {
will-change: transform;
}
但不要在大量元素上滥用 will-change，也不要在动画结束后保留它——用完应当移除，让浏览器释放资源。
- 避免无意义的合成层
不要为了表示“优化”而在静态元素上强行加 transform: translateZ(0)。如果一个元素从来不会变化，将它提升为合成层只会白白占用 GPU 内存。
- 防止层爆炸
当一个合成层下方的元素也变成了合成层时，它们可能会被“合并”到同一层级，或者产生不必要的重叠绘制。如果发现应用内存异常增长，要检查是否有过多的小元素被提升为合成层，特别是列表中的每一行都带 will-change 的情况。可以为列表容器设置 overflow: hidden 或将动画限制在特定子元素上。
- 使用
content-visibility优化长列表
CSS 的 content-visibility: auto 可以让浏览器跳过后台不可见区域的渲染工作，自动将可见部分提升为层并只渲染当前视口附近的内容。这对于含有海量 DOM 的滚动视图效果显著。
.list-item {
content-visibility: auto;
contain-intrinsic-size: 50px; /* 预估高度，避免滚动条跳动 */
}
20.3.3 拆分长任务，保持主线程响应
Chromium 的主线程不仅负责渲染，还运行 JavaScript。如果一个 JavaScript 任务执行时间过长（通常超过 50ms），就会阻塞渲染流水线，表现为点击无反馈、动画卡顿。这类任务被称为长任务。在 Electron 中，由于应用通常功能复杂、数据处理量大，长任务问题比普通 Web 应用更突出。
识别长任务
Chrome DevTools 的 Performance 面板在录制后会在主线程区域用红色三角标记长任务。你也可以使用 PerformanceObserver API 在代码中监听长任务：
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
console.warn('长任务检测:', entry.duration, 'ms');
}
});
observer.observe({ entryTypes: ['longtask'] });拆分策略
- 时间切片
将一个耗时的循环拆分成多个小任务，利用 setTimeout 或 requestAnimationFrame 将控制权交还给浏览器，让其有时间处理用户输入和渲染。
function processLargeArray(array, chunkSize = 100) {
let index = 0;
function chunk() {
const end = Math.min(index + chunkSize, array.length);
for (; index < end; index++) {
// 处理单个元素
heavyWork(array[index]);
}
if (index < array.length) {
setTimeout(chunk, 0); // 让出主线程
}
}
chunk();
}
对于支持 requestIdleCallback 的环境，也可以用它在浏览器空闲时分步执行，但在 Electron 中 requestIdleCallback 可能被 Chromium 调度得过于松散，建议加超时兜底。
- 使用 Web Workers
将纯计算型的任务移出主线程，放到 Worker 中执行，完全释放主线程的渲染负担。在 Electron 渲染进程中可以直接创建 Worker 实例。
// heavy-worker.js
self.onmessage = (e) => {
const result = performHeavyCalculation(e.data);
self.postMessage(result);
};
// 主线程
const worker = new Worker('heavy-worker.js');
worker.postMessage(largeData);
worker.onmessage = (e) => {
updateUI(e.data);
};
注意 Worker 无法直接访问 DOM，也无法使用 Electron 特定的 API，但足以胜任数据清洗、加密、排序等操作。对于更复杂的多线程需求，还可以考虑 Electron 主进程本身（另开一个 BrowserWindow 作为计算进程），通过 IPC 通信。
- 异步化本地存储操作
在 Electron 应用中，读写本地文件或操作 SQLite 数据库通常很快，但如果处理不当，一次同步 fs.readFileSync 就会直接卡死主线程。这类 I/O 操作应当全部迁移到主进程或 Worker，并始终采用异步 API，让渲染进程只通过 IPC 收发结果。
- 虚拟滚动
对于巨大的数据列表，一次性生成成千上万个 DOM 节点本身就是一次长任务。采用虚拟滚动技术（只渲染当前可见区域附近的元素）可以极大减少 DOM 节点数和初始化时间。像 vue-virtual-scroller、react-window 等库都能开箱即用。
20.3.4 性能优化的整体闭环
性能优化不应该是应用发布前的“临时抱佛脚”，而应融入开发的日常流程。养成用 DevTools Performance 面板定期录制的习惯，重点关注帧率曲线上的尖刺、红色三角标记的长任务和紫色火焰图里的重排重绘密集区。对于 Electron 特有的场景，还要额外检查：
- 窗口重绘是否因为系统主题切换、托盘图标连续闪烁等引起不必要的重新渲染。
- 是否在
BrowserWindow的ready-to-show事件前就完成了所有重排重绘，避免白屏闪现。 - 是否启用了
backgroundThrottling: false导致后台页面仍然疯狂重绘消耗资源。
把重排重绘关在合理的区间内，用合成层保护动画的流畅性，再把主线程的硬骨头拆成小块消化掉，大多数的 Electron 界面性能问题都能迎刃而解。当你的应用能够稳定维持在 60fps，页面切换如书页般轻盈时，用户根本不会意识到自己正面对一个“网页技术做成的东西”——这正是优化所要达成的终极效果。