I3.12.2background task priority设计
多个后台任务并发时需要优先级调度而非先到先得
别名: 任务优先级 · 不是 FIFO · job priority · 先做哪件
概念解释
几件后台工作同时在，带宽、CPU、电量是一份。先到先得（FIFO）会让一件两小时的备份堵住一件三十秒的「把这张图发出去」。优先级调度按人此刻更需要的那件来排：小的、交互依赖的、用户刚提交的，可以插到大的、可延后的前面。没有优先级，并发只是把等待从「一件接着一件」变成「大家一起慢慢熬」，而最急的那件并不更快。
这条是调度策略。列表里能不能手动改顺序，是人的覆盖；这里先要求系统自己别用队列位置当重要性。
机制
执行器看见的是任务流，人看见的是「我现在等哪一件」。人的等待成本不是均匀的：发出这张图挡着对话，备份挡着的是半夜。FIFO 把到达时间当成重要性，等于用提交顺序冒充目标。资源又是互斥的：上行带宽被备份占满，小上传的完成时间从三十秒变成「等备份到某个缝」。优先级把任务分成至少两档——交互关键与可延后——并允许高档抢占或穿插。抢占要保存低档的断点，否则优先级变成破坏耐久。
默认优先级也应可推断：用户前台正在看的对象上的任务、体积小的、截止近的，高于静默的全库扫描。推断错了会比 FIFO 更气人，所以默认要保守，把明显的交互关键提前即可，不要做复杂的隐式打分让人无法预测。
边界
只有一件任务时优先级无意义。所有任务同等紧急（批量导出十份同样的报告）FIFO 是可预测的，强行打分会让人觉得被插队。实时约束（直播推流）不是优先级问题，是独占资源，其他后台应让路到暂停，而不是「稍微优先一点」。系统自己的作业（系统备份、应用更新）会和产品抢资源；产品内的优先级无法指挥系统，但可以在系统忙碌时把可延后任务自己降档，避免两头抢。电量低时应把所有可延后的降到停，只留交互关键，这是优先级随情境翻转，不是取消优先级。
怎么落地
- 至少两档：用户正在等的（发送、导出当前打开的文件）高于可延后（全库备份、预取）。高档可穿插，低档被抢占时从断点续。
- 不要只按提交时刻排序。同等档内可以用 FIFO，档与档之间不行。
- 正在被等待的那件应能从状态上看出「正在占用资源」，避免人以为卡住。
- 验证：先提交一次长备份，三十秒后再提交一张图的发送。发送应在备份仍未完成时先结束。若发送排在备份之后整整两小时，就是 FIFO。再在前台打开一份正在导出的文档：这份导出应高于同一时刻提交的后台预取。