根据 IE docs引入 setImmediate 是为了在不对功耗产生负面影响的情况下解决核心性能问题。 IE 是如何做到这一点的？ (特别是如果将 setTimeout 限制为 4ms 的原因是因为“试图增加每秒回调的数量”导致高功耗)
我的问题是:
- 在引入 4 毫秒限制之前，setImmediate() 是否具有 setTimeout(func,0) 的所有缺点？
- 那么为什么有人应该使用 setImmediate() 而不是 setTimeout(func,0)？
最佳答案
我不是专家，但这是我对此的看法:
setTimeout(func, 0) 基本上是“当此函数返回且 UI 线程下一次空闲时，运行此函数”的 hack。这明显不同于它的预期用法“2 秒后运行此代码”。在前者中，我们并不真正关心函数何时运行 - 它可以在 10 毫秒、20 毫秒内运行，如果 UI 线程真的很忙，它可以在 3 秒后运行。
因为 setTimeout 和 setInterval 是时间相关的，浏览器使用本地操作系统计时器 API 来最有效地实现这一点。计时器 API 有一个分辨率，它决定了它在请求时间运行函数的精确度。标准的windows API提供了大约15ms的分辨率，这意味着CPU每15ms需要唤醒并检查是否有定时器回调需要执行。还有高分辨率计时器 API，如果您使用它们，CPU 将更频繁地唤醒以检查是否需要任何回调，因此会消耗更多 CPU 功率。
在 setTimeout(func, 0) 的情况下，浏览器将安排它使用计时器 API 运行，并且它将在下次操作系统计时器唤醒并检查回调时运行，如果使用标准计时器 API，则可能是从 0 到 15 毫秒，具体取决于上次迭代的时间。这都是不必要的，因为我们根本不在乎时间。我们应该独立于任何计时器运行它，因此使用 setImmediate API。当然，如果你一直调用 setImmediate，它会增加功耗，但当你不使用它时不会，这与使用高分辨率计时器不同。
所以回答你的问题:
1) 可以这么说，我不认为计时器必须限制在 4 毫秒。他们的分辨率从未超过 4 毫秒。是的，大量使用 setImmediate 会增加功耗。如上所述，我认为省电来自于空闲时。
2) 由于上述原因!!
关于javascript - 在 IE 中使用 setImmediate() 而不是 setTimeout(func,0)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25090606/