React Native Expo中运行后台worker执行密集任务的相关问题咨询

现有实现思路的适用范围 #

你给出的循环消费队列的代码逻辑本身是可行的：

class BackgroundWorker {
    async process() {
      while (true) {
        const job = await this.jobQueue.waitAsync(); // 等待作业入队
        // 作业处理逻辑
      }
    }
}

该逻辑仅在应用JS线程处于活跃状态时可以正常运行，符合你前台使用场景下的即时响应需求。

BackgroundFetch/TaskManager 间隔不准问题说明 #

这两个组件的执行间隔不可控是系统级限制，并不是组件BUG：

• 两个组件本身的定位就是低优先级、低频率的后台调度任务，系统会根据当前设备电量、负载、应用活跃等级动态调整执行间隔，你设置的minimumInterval只是最小间隔，不是保证执行的间隔，因此会出现设置10秒实际1分钟才执行的情况，完全无法满足即时响应需求。
• 如果你需要即时响应作业入队，不要依赖这两个组件做轮询触发，直接在作业入队的位置唤醒你自己写的Worker队列即可。

不同场景下的Worker存活能力说明 #

应用处于后台运行状态 #

如果没有申请特殊后台权限，iOS默认会给应用30秒到3分钟的后台运行时间，安卓根据厂商定制策略不同，后台存活时间从1分钟到10分钟不等，到期后JS线程会被系统挂起，你写的循环消费逻辑会停止运行。
如果申请了后台播放、持续位置更新等特殊后台权限，可以延长后台存活时间，但普通应用如果没有对应使用场景，上架应用商店时大概率会因为滥用后台权限被拒。

应用被手动关闭/系统终止 #

所有JS层逻辑会直接被销毁，不管是你自己写的循环Worker还是TaskManager注册的普通任务都会停止运行，只有两类任务可以继续执行：

• 系统级调度任务：比如BackgroundFetch注册的任务，但是执行延迟依旧不可控
• 原生层托管任务：比如expo-file-system提供的后台上传/下载能力、系统推送服务的消息接收能力，这类任务是交给系统原生进程托管的，不受应用JS线程生命周期影响

实现建议 #

• 应用活跃状态下的轻量作业，直接用你写的循环队列Worker处理即可，满足即时响应需求
• 下载、上传类长耗时任务，优先调用expo-file-system的原生后台传输能力，保障任务在后台甚至应用临时退出后可以继续执行
• 涉及需要即时触发的后台任务，可以配合系统推送能力，收到推送后唤醒应用执行对应逻辑，不需要依赖固定轮询

不要依赖JS层的Worker实现强可靠性的后台作业，JS层逻辑的生命周期完全受系统调度管控，涉及必须保障执行的任务，优先使用原生托管能力。

内容的提问来源于stack exchange，提问作者A. Boz