如何在事件页面扩展中替换短(不到一分钟)setTimeouts

有关从后台持久扩展转换为非持久性事件页面的文档说明:

如果您的扩展使用window.setTimeout()或window.setInterval(),请切换到使用警报API.如果事件页面关闭,则不会遵守基于DOM的计时器.

很公平,但警报API 文档说明:

何时可以在"现在"之后设置为不到1分钟而没有警告但实际上不会导致警报至少1分钟.

所以,我在EventPage中有一个简短的setTimeout,需要5s,如果我不能在那些短时间内使用闹钟,我怎样才能确保它完成.设置1分钟长的闹钟对我来说不是解决方案.

如果您需要经常做这样的事情，那么wOxxOm是绝对正确的：事件页面是满足您需求的不好方法。

不应误解文档：绝不弃用持久性后台页面。对于不定期和/或很少处理事物的后台页面，事件页面是一种更有效的解决方案。

常用计时器不属于此类。毕竟，频繁地“启动”事件页面是相当大的资源/性能损失，而不是始终保持就绪状态。

现在，当您只需要不定期（而不是定期）执行此超时操作（而您认为这些操作之间的长时间停顿可以从事件页面模型中受益）时，该问题就变得更加棘手。这可能发生！

这样目标就会变得对Chrome足够“忙”，以使事件页面不会关闭。

最简单的方法可能是更频繁地调用计时器，因为事件页面可以保证持续几秒钟：

var SAFE_DELAY = 1000; // Guaranteed not to fall asleep in this interval

function setBusyTimeout(callback, delay) {
  if(delay <= SAFE_DELAY) {
    setTimeout(callback, delay);
  } else {
    var start = Date.now(); // setTimeout drifts, this prevents accumulation
    setTimeout(
      function() {
        setBusyTimeout(callback, delay - (Date.now() - start));
      }, SAFE_DELAY
    );
  }
  // Can be expanded to be cancellable by maintaining a mapping
  //   of "busy timeout IDs" to real timeoutIds
}

这是一种非常“稀疏”的繁忙等待，它不应该消耗太多资源-如果不经常使用，则同样如此。

其他灵魂可以包括通过chrome.runtime.connect和朋友保持开放的端口。我怀疑它比上面的CPU效率更高。