移动端熄屏时setTimeout变慢 Web Audio主时钟方案咨询

已尝试方案与待验证思路 #

编辑补充：根据评论参考的setTimeout与节流相关文档说明，我尝试添加AudioContext规避执行变慢问题，实现代码如下：

document.addEventListener('click', ev => {
    let audCtxt = new AudioContext({});
});

注：AudioContext需要用户交互触发才可创建，因此将初始化逻辑绑定在点击事件监听器中。

该方案实际测试并未生效。我梳理了2种待验证的实现思路：

• 使用while循环，通过Date.now()判断是否到达10ms间隔，但预判该方案会导致页面崩溃
• 评估是否可使用requestAnimationFrame实现该时钟

原始问题描述 #

我在Web应用中使用每0.01秒触发一次的setTimeout作为主时钟，应用需要播放可响应用户交互的同步音频，因此对时钟精度有要求，简化后的实现代码如下：

let counter = 0;
setTimeout(() => {
    counter++;
    console.log(counter);
}, 10);

在安卓移动端设备（暂未测试iOS设备）测试时发现，当屏幕锁定/熄灭时，setTimeout执行速度会变慢（约为正常速度的25%-50%，即慢2-4倍）。该现象可通过上述代码的日志输出验证，也可设置为counter值为100的倍数时触发音效来验证。

待解答的两个核心问题：

1. 如何避免移动端熄屏时setTimeout被节流变慢的问题？
2. 若要实现可同步触发音频采样、同时支持实时响应用户交互的“主时钟”，是否需要采用其他更合适的实现方案？

问题解答 #

1. 熄屏setTimeout节流的本质 #

移动端系统在屏幕熄灭后会主动收紧非前台可见应用的资源分配，JS主线程会被降频，定时器最小触发间隔会被强制拉长，这是系统级的电源优化策略，没有100%绕过的方法。
你之前试的空AudioContext方案没用很正常，现在主流移动端浏览器早就堵上了这个空子：只有真实正在输出音频的AudioContext才会临时提升线程优先级，空上下文创建了也不会触发保活，熄屏久了照样被节流。
你列的两个待验证思路都不可行：while循环死等会占满整个JS主线程，直接导致页面交互卡死，甚至会被系统判定为无响应进程直接杀掉；requestAnimationFrame在页面不可见（熄屏、切后台）时会直接暂停执行，根本跑不起来，完全不适合做后台时钟。

2. 适配音频同步的高精度主时钟实现方案 #

别用setTimeout/setInterval做音频相关的时钟，这类定时器跑在JS主线程上，本来就会受GC、渲染任务、系统节流影响，精度从根上就达不到音频同步的要求。正确的实现逻辑是：

• 彻底抛弃“靠固定间隔定时器累加计时”的思路，把AudioContext.currentTime作为全局唯一的时间基准。这个时间由音频硬件时钟驱动，精度可达微秒级，不会受JS主线程阻塞、系统节流影响，哪怕主线程半天没响应，这个时间的走时也是准的。
• 音频播放不要等主线程定时器触发了再调，提前用Web Audio API的调度接口把要播放的音频按时间片排进音频渲染队列，让独立的音频渲染线程按硬件时钟自己触发播放，完全绕开主线程的限制。
• 如果需要在时钟节点同步触发UI更新、交互响应这类非音频逻辑，也不要开10ms的轮询，只要在每次requestAnimationFrame触发、每次用户交互事件进来的时候，对比当前的AudioContext.currentTime和上一次处理到的时间点，算出时间差，批量跑完这段区间内应该触发的逻辑就行。哪怕熄屏时主线程被节流到1s才跑一次，只要时间基准是硬件时钟，恢复后算出来的累计时间就是对的，不会出现计时慢2-4倍的问题。
• 如果确实需要熄屏后持续运行，可调用navigator.wakeLock申请屏幕常亮，同时保持低音量的静音轨播放，尽可能降低系统节流的概率，但要说明的是，这也不能完全阻止极端省电模式下系统对进程的休眠限制，这是Web平台本身的能力边界，没有完美解法。

内容的提问来源于stack exchange，提问作者ultraGentle