No JavaScript framework can stop the execution or change the behaviour of the underlying JS engine. They will not be able to influence setTimeout.
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:
This API does not guarantee that timers will run exactly on schedule. Delays due to CPU load, other tasks, etc, are to be expected.
and, even more explicit:
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.
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.
You might also want to have a look at the WindowAnimationTiming draft.
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()).
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
