关于从后台持久扩展转换到非持久性事件页面的documentation,声明：
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.
很公平,但API documentation警报声明：
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.
所以,我在EventPage中有一个简短的setTimeout,需要5s,如果我不能在那些短时间内使用闹钟,我怎样才能确保它完成.
设置1分钟长的闹钟对我来说不是解决方案.
不应误解文档：持久性背景页面不以任何方式弃用.对于不规则和/或很少处理事物的后台页面,事件页面是一种更有效的解决方案.
频繁的计时器不属于这一类.毕竟,经常“旋转”事件页面是一个相当大的资源/性能损失,而不是始终保持准备.
现在,当您只需要将此超时作为常见操作的一部分而不是常规操作时,当您认为这些操作之间的长时间暂停可以从事件页面模型中受益时,问题变得更加棘手.这可能发生！
然后,目标变得对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效率更高.
