其实，

Electron 窗口切后台，我的轮询怎么停了？排查一下午才发现是浏览器搞的鬼

下午两点半，我盯着屏幕开始怀疑人生。按理说，

先前的工作正常

刚写完一段设备状态轮询的逻辑。代码看着挺稳的：

let lastStatus = '';setInterval => {
const status = await window.electronAPI.getDeviceStatus;if {
lastStatus = status;updateUI，console.log;}
},1000)，

主进程配合也很简单：

// main.ts
ipcMain.handle => {
// 实际读取硬件状态
return readDeviceStatus;})，

在前台测试，完美。状态一变，UI 跟着刷新，控制台每秒一条日志，干净利落。

说到问题出现。窗口最小化后日志消失

接下来我随手把窗口最小化，去查了会儿资料。钟后回来发现控制台安静得像深夜的办公室。

一条新日志都没有。

我的第一反应是：IPC 通信断了？Electron 在鸿蒙 PC 上有特殊的窗口生命周期？

加日志排查 IPC 是否断连

// main.ts - 加了调试日志
ipcMain.handle => {
console.log;// 加了这行
return readDeviceStatus;})，

// renderer.ts
setInterval => {
console.log;// 加了这行
const status = await window.electronAPI.getDeviceStatus;console.log，},1000);其实，

结果让我更懵了。窗口切到前台，三个日志交替出现，运转如常。窗口一切后台， 准备查询状态这条日志直接消失了。

不是 IPC 的问题。请求根本没发出来，

检查渲染进程是否崩溃

I打开鸿蒙 PC 的任务管理器。看了看渲染进程列表：活得好好的，内存使用也没异常。WebSocket、其他 IPC 通道都正常——唯独这个 setInterval 像是被按了暂停键。

猜测程序限制还是 Chromium 策略？

I怀疑鸿蒙 PC 对后台窗口有特殊限制，但其他应用的后台逻辑跑得还不错。我忽略一个前提：Electron 使用的是 Chromium，而 Chromium 对不可见标签页/窗口默认启用了节能策略。怎么说呢，

再看排查结果。Chromium 的后台定时器节流导致轮询停止

I翻到了 Chromium issue “Background timer throttling in non-visible windows”。里面写明的观点是，当页面不可见时setInterval 和 setTimeout 的回调会被节流。最低可降至每分钟一次，

M一分钟一次。我那个每秒轮询的逻辑，在后台直接被压缩成废铁。

尝试 Web Worker 把定时器搬走

// worker.ts
self.onmessage = => {
setInterval => {
self.postMessage;},1000)，};

// renderer.ts
const worker = new Worker);worker.onmessage = => {
window.electronAPI.getDeviceStatus.n;}，

从测试结果来看，Worker 内部定时器一样被节流。Chromium 节流策略覆盖整个页面包括 Web Workers。

AudioContext

const audioCtx = new AudioContext;const oscillator = audioCtx.createOscillator;说起来，oscillator.connect;oscillator.start;按理说，// 无声音频保持激活

确实能让定时器保持一定频率。但要让应用一直“播放”无声音频，这显然不可取，也会在任务栏显示音频指示。

从合适方案来看，把轮询迁移到主进程执行并通过 IPC 推送给渲染进程

// main.ts
let cachedStatus = '';setInterval => {
const status = await readDeviceStatus;if {
cachedStatus = status;BrowserWindow.getAllWindows.forEach(win => {
win.webContents.send;})，}
},1000);// renderer.ts - 被动接收更新
window.electronAPI.onDeviceStatusChanged => {
updateUI;console.log，});

• 为什么有效？Main process 是 Node.js 环境，不受 Chromium 的节流策略影响；无论窗口是否可见，都按自己的节奏运行.
• 优点 : 渲染进程只负责展示，更轻量；主进程统一管理业务逻辑.
• 细节注意 : 当窗口隐藏时可以省去 UI 更新，以减少资源使用情况.
• ts
setInterval => {
const status = await readDeviceStatus;老实说，
if {
cachedStatus = status;
BrowserWindow.getAllWindows.forEach &&，!win.isMinimized) {
win.webContents.send;
}
});
}
},TIMEOUT);
• 为保证从后台切回前台时显示最新数据，可监听 show/restore:
• ts
win.on => { win.webContents.send;})，
• 如果你确定不需要 Chromium 的节流，还可以在创建 BrowserWindow 时关闭它：
• ts
const win = new BrowserWindow;
• 但通常不推荐，因为省电和资源调整是 Electron 应用的一部分.
.

——不要忘记底层仍是浏览器引擎！

This排查让我重新意识到：虽然 Electron 看起来像原生桌面应用，但它背后依旧是 Chromium。如果你想让后台逻辑持续跑，需要要么禁用背景节流，要么将业务迁移到主进程或其它不受限环境中运行.

关于我

I叫老三。一个写了十年代码的前端 + 鸿蒙 ArkTS 水手。其实，目前主业做 Taro 多端项目，业余时间全泡在 AI 自动化和独立开发上——不是因为多热爱加班。而是打心底觉得程序开发正在被 AI 重构，我不跟上就会被甩下。不过，这账号记录真实经历：踩过的坑、推翻过的方案、偶尔值得高兴的小进展。不写教科书，不讲大道理，只分享自己试过、做过、确认过的东西。如果你也在写代码或思考 AI 时代开发者该往哪走——欢迎留言聊聊，一起摸索.

`