如何在事件页面扩展中替换short（少于一分钟）setTimeouts [英] How to replace short (less than a minute) setTimeouts in Event Page Extensions

问题描述

有关从后台持久性扩展转换为非持久性事件页面的文档指出：
$ b

如果您的扩展使用window.setTimeout（）或window.setInterval（），请改为使用警报API。

足够公平，但警报API documentation 指出：

在now之后可以设置为小于1分钟而不发出警告，但实际上并不会导致闹钟至少触发1分钟。

因此，我在EventPage中有一个简短的setTimeout，它需要5秒，我如何确保它完成，如果我不能在短时间内使用闹钟。
设置1分钟长的闹钟对我来说不是一个解决方案。 解决方案

如果你需要做这样的事情通常情况下，那么wOxxOm是绝对正确的：事件页面对您的需求是一个不好的方法

文档不应该被误解：持久背景页面不以任何方式弃用。事件页面对于后台页面来说是一个更有效的解决方案，它可以不规则地和/或很少地处理事情。

频繁的计时器不属于这个类别。毕竟，经常跳转活动页面是一个<相当大的资源/性能损失，而不是始终保持准备就绪。

---

现在，如果您只需要将此超时设置为不频繁的一部分，与常规操作相反，当您认为这些操作之间的长时间停顿可以获益时，问题就变得更加棘手来自事件页面模型。这可能发生！

然后，目标变得足够忙到Chrome，这样就不会发生事件页面关闭。

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

  var SAFE_DELAY = 1000; //保证不会在这段时间内入睡
 
函数setBusyTimeout（callback，delay）{
 if（delay< = SAFE_DELAY）{
 setTimeout（callback，delay）; 
} else {
 var start = Date.now（）; // setTimeout漂移，这可以防止累积
 setTimeout（
 function（）{
 setBusyTimeout（callback，delay  - （Date.now（） -  start））; 
}，SAFE_DELAY 
）; 
} 
 //可以通过维护映射
 //繁忙超时ID为true timeoutIds 
} 
  

这是一种非常稀疏的忙碌等待，应该不会消耗太多资源 - 如果不经常使用的话。

其他可能包括通过 chrome.runtime.connect 和朋友维护一个开放端口。我怀疑它比上面的CPU更高效。

The documentation about transitioning from background persistent extensions to non persistent Event Pages, states:

If your extension uses window.setTimeout() or window.setInterval(), switch to using the alarms API instead. DOM-based timers won't be honored if the event page shuts down.

Fair enough, but the alarms API documentation states:

when can be set to less than 1 minute after "now" without warning but won't actually cause the alarm to fire for at least 1 minute.

So, i have a short setTimeout in my EventPage, it takes 5s, how can i ensure it completes, if i can't use an alarm for those short times. Setting a 1 minute long alarm is not a solution for me.

解决方案

If you need to do something like this often, then wOxxOm is absolutely correct: Event page is a bad approach for your needs.

Documentation should not be misinterpreted: persistent background pages are not in any way deprecated. Event pages are a more efficient solution for background pages that process things irregularly and/or rarely.

Frequent timers do not fall into this category. After all, "spinning up" the Event page frequently is a considerable resource/performance loss as opposed to keeping it ready at all times.

---

Now, the question becomes more tricky when you only need to do this timeout as a part of infrequent, as opposed to regular, action, when you think that long pauses between those actions can benefit from Event page model. This can happen!

The goal then becomes to appear "busy" enough to Chrome so that the Event page shutdown does not happen.

Probably the easiest way is to just invoke the timer a bit more frequently, as the Event page is guaranteed to persist for a couple of seconds:

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
}

It's a sort of a very "sparse" busy-wait, that should not consume much resources - again, if used infrequently.

Other soultions may include maintaining an open port through chrome.runtime.connect and friends. I doubt it's more CPU-efficient than the above.

这篇关于如何在事件页面扩展中替换short（少于一分钟）setTimeouts的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！