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

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

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

typescript 复制代码

// renderer.ts
let lastStatus = '';

setInterval(async () => {
  const status = await window.electronAPI.getDeviceStatus();
  if (status !== lastStatus) {
    lastStatus = status;
    updateUI(status);
    console.log('状态更新:', status);
  }
}, 1000);

主进程配合也很简单：

typescript 复制代码

// main.ts
ipcMain.handle('getDeviceStatus', async () => {
  // 实际读取硬件状态
  return readDeviceStatus();
});

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

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

一条新日志都没有。

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

我开始在 IPC 通道上加日志：

typescript 复制代码

// main.ts - 加了调试日志
ipcMain.handle('getDeviceStatus', async () => {
  console.log('[Main] 收到状态查询请求');  // 加了这行
  return readDeviceStatus();
});

渲染进程里也加了：

typescript 复制代码

setInterval(async () => {
  console.log('[Renderer] 准备查询状态');  // 加了这行
  const status = await window.electronAPI.getDeviceStatus();
  console.log('[Renderer] 收到响应:', status);  // 加了这行
  // ...
}, 1000);

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

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

那渲染进程崩了？我打开鸿蒙 PC 的任务管理器看了看，进程列表里渲染进程活得好好的，内存占用也没异常。WebSocket 连接、其他 IPC 通道都在正常工作------唯独这个 setInterval 像是被按了暂停键。

我一度怀疑是不是鸿蒙 PC 对后台窗口有什么特殊限制，毕竟这系统对应用生命周期管得比 Windows 严。但转念一想，其他应用的后台逻辑也跑得好好的，没听说有这种限制。

等一下，这里我漏说一个前提。 这个应用用的是 Electron 28，Chromium 版本是 120。我在写这段逻辑之前，其实知道 Chrome 对后台标签页有节能策略，但一直以为是"降低频率"，没想到是直接给你停了。

排查到第四个小时，我在 Chromium 的 issue 追踪器里翻到了那张单子：Issue 1186569: Background timer throttling in non-visible windows。里面写得明明白白：当页面不可见时，setInterval 和 setTimeout 的回调会被节流，最低可降至每分钟一次。

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

这事儿让我哭笑不得。你说 Chrome 做得对不对？从节能角度来说，完全合理。一台鸿蒙 PC 上跑着七八个 Electron 应用，每个都在后台狂刷定时器，续航确实扛不住。但问题是------我的应用真的有需要在后台持续跑的逻辑啊。

比如这个设备状态监控，用户把窗口收起来去做别的，不代表他就不关心设备状态了。

我开始尝试绕过。

第一个想法：Web Worker。

把定时器塞进 Worker 里，Worker 总不会被节流了吧？

typescript 复制代码

// worker.ts
self.onmessage = () => {
  setInterval(() => {
    self.postMessage({ type: 'tick' });
  }, 1000);
};

然后在渲染进程里：

typescript 复制代码

const worker = new Worker(new URL('./worker.ts', import.meta.url));
worker.onmessage = () => {
  window.electronAPI.getDeviceStatus().then(updateUI);
};

测试结果：Worker 里的定时器同样被节流。 Chromium 的节流策略是针对整个页面的，Worker 也逃不掉。这条路走不通。

第二个想法：audio context hack。

听说过一个邪门技巧------维持一个播放中的 AudioContext 可以让页面被认为是"有音频活动"的，从而绕过部分节流。我试了一下：

typescript 复制代码

const audioCtx = new AudioContext();
const oscillator = audioCtx.createOscillator();
oscillator.connect(audioCtx.destination);
oscillator.start();

确实能让定时器在后台保持一定的频率，但代价太荒谬了------就为了跑个轮询，我得让应用一直"播放"一段无声的音频？ 这不仅在任务栏会显示音频指示，而且从工程伦理角度我都过不了自己这关。放弃。

第三个想法：把逻辑搬到主进程。

这是最朴素、最稳妥的方案。既然渲染进程在后台会被节流，那我就不在渲染进程里跑定时器了，改在主进程里跑，需要更新 UI 时再通过 IPC 推给渲染进程。

typescript 复制代码

// main.ts
let cachedStatus = '';

setInterval(async () => {
  const status = await readDeviceStatus();
  if (status !== cachedStatus) {
    cachedStatus = status;
    // 推送给所有窗口
    BrowserWindow.getAllWindows().forEach(win => {
      win.webContents.send('device-status-changed', status);
    });
  }
}, 1000);

// renderer.ts - 只需要被动接收
window.electronAPI.onDeviceStatusChanged((status: string) => {
  updateUI(status);
  console.log('收到主进程推送:', status);
});

这个方案的核心思路是：谁不受限制，谁来干活。

主进程是 Node.js 环境，setInterval 不受 Chromium 的节流策略影响。窗口在不在前台，主进程的逻辑都按自己的节奏跑。渲染进程只需要注册一个 IPC 监听器，轻量又省心。

不过这里有个细节需要注意。当窗口处于隐藏状态时，UI 其实没必要刷新------反正用户也看不见。所以我在实际项目中加了一层判断：

typescript 复制代码

// main.ts
setInterval(async () => {
  const status = await readDeviceStatus();
  if (status !== cachedStatus) {
    cachedStatus = status;
    BrowserWindow.getAllWindows().forEach(win => {
      // 只有可见窗口才推送，节省资源
      if (win.isVisible() && !win.isMinimized()) {
        win.webContents.send('device-status-changed', status);
      }
    });
  }
}, 1000);

等一下，这里我又漏说一个前提。 这个 isVisible() 在鸿蒙 PC 上的 Electron 里，最小化时返回 false，但窗口被别的窗口挡住时仍然返回 true。不过没关系，消息推送过去，渲染进程更新 UI 的实际开销并不大，真正的大头已经被主进程扛下来了。

最后我花了一行配置解决了一个附带问题------当窗口从后台切回前台时，渲染进程需要立刻获取一次最新状态，避免显示过期的数据：

typescript 复制代码

win.on('show', () => {
  win.webContents.send('device-status-changed', cachedStatus);
});

整个过程下来，我最深的感触不是技术层面的。是这个排查过程让我重新意识到：Electron 应用虽然看起来像个原生应用，但它的渲染进程本质上还是网页。网页有的限制，它一个不落。 我们不能因为在写桌面应用，就忘了底层仍然是 Chromium 在管着。

回头一看，其实不是什么高深问题，就是文档少写了一行。Electron 官方文档里对 background timer throttling 有说明，但藏在 BrowserWindow 的 backgroundThrottling 配置项里，不专门去搜根本注意不到。

还有一个更简单的办法------如果你确定不需要 Chromium 的节流：

typescript 复制代码

const win = new BrowserWindow({
  webPreferences: {
    backgroundThrottling: false,  // 关闭后台节流
  },
});

但我没这么干。 一方面是因为节能考量，另一方面是------我觉得让主进程托管轮询逻辑，代码结构反而更清晰了。渲染进程只管展示，数据逻辑全在主进程，这才是 Electron 应用该有的样子。

你遇到过类似的情况吗？后台逻辑莫名其妙停摆，排查半天发现是浏览器在"帮你省电"。欢迎聊聊你的经历。

关于我

我叫老三，一个写了十年代码的前端 + 鸿蒙 ArkTS 水手。

目前主业做 Taro 多端项目，业余时间全泡在 AI 自动化和独立开发上------不是因为多热爱加班，而是打心底觉得，程序开发这件事正在被 AI 重构，我不跟上就会被甩下。

这个账号记录的就是我在这条路上的真实经历：踩过的坑、推翻过的方案、以及偶尔值得高兴的小进展。不写教科书，不讲大道理，只分享我自己试过、做过、确认过的东西。

如果你也在写代码，或者也在思考 AI 时代开发者该往哪走------欢迎留言聊聊，一起摸索。

本文遵循 MIT 协议，转载请注明出处。