移动设备网络浏览器在线程休眠方面是否有任何标准? [英] Are there any standards for mobile device web browsers in terms of thread sleeping?
问题描述
给定以下 jsFiddle，这是一个简单的递增计数器
Given the following jsFiddle, which is a simple incrementing counter
....如果我使用移动设备(智能手机或平板电脑)访问上面的 url，如果有 JavaScript 支持，计数器开始按预期递增，然后看起来如果我按主页"按钮，或单击电源按钮一次关闭屏幕(但保持手机开机)然后脚本将停止运行并且计数器停止递增.我希望这会发生，并且我理解为什么在移动设备上保留电池寿命非常重要，因此 UI 线程休眠或类似的原因是有道理的.一旦您重新访问浏览器，计数器就会继续增加.在现实世界中，我假设使用 JavaScript 确定超时时间的网站不会超时，尽管有不活动时间段.
....if I visit the url above using a mobile device (smartphone or tablet for the sake of argument), the counter starts incrementing as you'd expect provided there is JavaScript support, then it appears that if I press the "Home" button, or click the power button once to turn off the screen (but keep the phone powered on) then the script will stop running and the counter stops incrementing. This I expect to happen and I appreciate the reasons why as reserving battery life is hugely important on a mobile device, so it makes sense that the UI thread sleeps, or similar. Once you revisit the browser, the counter continues incrementing. In the real world, websites that determine timeout period using JavaScript would not timeout despite the inactivity period, I am assuming.
我还假设这会因设备、固件甚至软件而异 - 我尝试在这里确定的是是否存在标准方法或默认行为内置于移动开发框架中，用于实现设备行为的任何形式的一致性.
I am also assuming that this will vary by device, by firmware, by software even - what I'm trying to ascertain here is whether there's a standard approach or default behaviour built into mobile development frameworks for this and any form of consistency in how the devices behave.
我不完全确定我在这里问了一个好问题，但我一直在努力从 SO 中找到 100% 相关的信息，或者我不太清楚问题是什么搜索的时候需要问一下.
I'm not totally sure I've asked a good question here, but I've struggled to find 100% relevant information from SO, or I don't quite know what the question is I need to ask when searching.
推荐答案
任何 JavaScript 框架都不能停止执行或更改底层 JS 引擎的行为.他们将无法影响 setTimeout.
No JavaScript framework can stop the execution or change the behaviour of the underlying JS engine. They will not be able to influence setTimeout.
然而，该行为在 上的当前 HTML5 草案中已标准化WindowTimers 接口(这并不意味着它是这样实现的).您会在那里找到注释:
Yet, the behaviour is standardisized in the current HTML5 draft on the WindowTimers interface (which does not mean it was implemented like that). There you will find the note:
此 API 不保证计时器会完全按计划运行.由于 CPU 负载、其他任务等导致的延迟是意料之中的.
This API does not guarantee that timers will run exactly on schedule. Delays due to CPU load, other tasks, etc, are to be expected.
而且，更明确:
9) 或者，等待用户代理定义的进一步时间长度.
9) Optionally, wait a further user-agent defined length of time.
注意:这旨在允许用户代理根据需要填充超时以优化设备的电源使用.例如，一些处理器具有低功耗模式，在这种模式下，定时器的粒度会降低；在此类平台上，用户代理可以减慢计时器以适应此计划，而不是要求处理器使用更准确的模式及其相关的更高功耗.
Note: This is intended to allow user agents to pad timeouts as needed to optimise the power usage of the device. For example, some processors have a low-power mode where the granularity of timers is reduced; on such platforms, user agents can slow timers down to fit this schedule instead of requiring the processor to use the more accurate mode with its associated higher power usage.
您也可以在桌面浏览器上看到这种行为，它实现了 4ms 的最小超时(阅读 MDN 上的说明).因此，每个设备/软件/固件在他们认为有必要时停止此类执行是合法的.
You can see such behaviour also on desktop browsers, which implement a minimum timeout of 4ms (read explanation on MDN). So, it is legitimate for every device/software/firmware to stop such execution if they only think it would be necessary.
您可能还想查看 WindowAnimationTiming 草案.
You might also want to have a look at the WindowAnimationTiming draft.
如果您确实在动画/时钟等中使用了 setInterval/setTimeout，请始终使用 Date 对象(例如通过 Date.now()).
And if you do use setInterval/setTimeout in animations/clocks/etc, always measure the really elapsed time with Date objects (e.g. via Date.now()).
这篇关于移动设备网络浏览器在线程休眠方面是否有任何标准?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
