pin*_*yid 7 javascript browser cross-browser
我设置了一个setTimeout例如10s,在那个10s期间,我暂停/睡眠PC.在醒来时,以下哪项是真的: -
重复的setInterval也是同样的问题.是否保证(不)继续.
我刚刚用这个脚本测试了它：
<html>
<body>
<script>
var d = 120;
var start = new Date ();
document.write(start + " : sleeping for " + d + " seconds");
</script>
<div id='result'><div>
<script>
function cb() {
var now = new Date ();
document.getElementById("result").innerHTML = "" + Date () + " : callback fired after " + (now.getTime() - start.getTime()) / 1000 + " seconds";
};
window.setTimeout(cb, d * 1000);
</script>
</body>
</html>
我在 Firefox 37.0.1 和 Chromium 41.0.2272.118（64 位）中打开了页面，然后我的机器暂停了几分钟。当我恢复时，两个浏览器都等了几分钟，即使计时器到期了。示例输出（机器在 恢复Wed 15 Apr 17:52:11 BST 2015）：
Wed Apr 15 2015 17:49:13 GMT+0100 (BST) : sleeping for 120 seconds
Wed Apr 15 2015 17:53:47 GMT+0100 (BST) : callback fired after 273.705 seconds
简短答案
它被定义为在规范中执行。超时请求将进入排序队列并进行轮询，直到可以将其触发为止。如果系统在恢复时进入睡眠状态，它将在中断处恢复并继续轮询。
长答案 可能比任何人都想知道的更多
w3编写的答案时，Timer's Spec的最新工作草稿（2014年10月28日），它将启动...只要操作系统在进行更新的过程中不会混乱，睡眠/暂停和唤醒/恢复（在示波器外部）。这更多是一个操作系统级别的问题，但是就w3规范而言，它最终将被触发。
无论是setInterval(...)与setTimeout(...)走同样的关闭windowTimer接口，其中window的浏览器实现了对象。
在这两种情况下，客户端都将定义一个间隔或超时请求，方法上下文将经历该间隔或超时请求，方法上下文timer initialization steps将被添加到活动计时器列表中，并为计划任务返回一个句柄。
一旦进入活动计时器列表，系统就会将任务排队等待在请求的持续时间或之后执行（将其他优先级较高的任务以及CPU负载挂起）。如果任务无法保留CPU时间，它将轮询/等待直到可以。因此，如果系统在恢复时进入睡眠状态，它将在中断处恢复。
为了执行任务，其句柄必须存在于活动计时器列表中。任务运行后，如果将repeat标志设置为true（如果使用创建setInterval(...)），则将使用相同的参数重新创建任务，并为其分配完全相同的handle。换句话说，它被添加回队列/列表中，以在下一个间隔或之后的间隔执行。
以下是Timer规范中关于系统从活动计时器列表中删除项目的唯一说明或备注：
处理完任务后，如果repeat标志为false，则可以安全地从活动计时器列表中删除句柄条目（无法在此点之前检测到该条目的存在，因此从技术上讲不会如此）一种方法或另一种方法）
根据规范，如果list of active timers任务在运行时，它将按预期启动。否则将中止。回到我的第一点，如果操作系统在恢复任务时在睡眠/暂停过程中没有搞乱事情，则继续轮询。一旦获得CPU时间，它的句柄仍应存在于活动计时器列表中，因此在处理后将执行。