I3.12.1durable background task设计
长任务需要能在应用退出或设备重启后继续执行或恢复
别名: 退出后续跑 · 重启恢复 · survive reboot · 任务耐久
概念解释
导出、转码、备份、模型下载，往往比一次应用会话更长。人划掉应用、系统杀后台、设备重启，任务必须接着跑或从断点恢复，而不是从零开始、更不是蒸发。耐久的是任务对象：身份还在、已完成的那一段还在、剩下的计划还在。
这条管寿命跨过进程和开机。进度能不能被查询、完成要不要通知，是另一张表面的事。没有耐久，那张表面第二天打开会是空的，不是「可查询」失败，是对象已经死了。
机制
操作系统不保证前台进程活过后台。移动系统尤其会在几分钟后冻结或杀死。长任务若只活在那个进程的内存里，寿命被写成了会话寿命。耐久要求把任务描述（做什么、做到哪、下一步）写进进程之外的存储，并把执行权交给系统还承认的执行器：后台传输、作业调度、开机后的恢复逻辑。重启之后执行器被再次唤醒，读描述，从断点继续。
「继续」和「恢复」不同。继续是进程没了、工作还在系统侧跑（大文件上传交给系统上传服务）。恢复是工作也停了，但断点还在，下次启动从断点往下走而不是重做。两种都比蒸发强；对用户，区别要说出来：「仍在上传」相对「打开后会接着压」。说成还在跑、其实只是存了个待办，是寿命上的谎言。
边界
必须有电源和网络才能进行的工作（上传），关机期间不能继续，只能恢复；不要在关机后还显示「正在上传」。一次性、绑在当前屏幕的短工作（滤镜预览）不必耐久。安全擦除、登出、卸载应能把未完成长任务一起结束，否则耐久变成卸不掉的残留。另一台设备上的同一账号不自动继承这台设备的本地转码——执行现场在这台硬件上。系统在低电量下拒绝后台执行时，任务应进入明确的「等充电」而不是被当成完成或失败。
怎么落地
- 提交长任务时立刻把描述和断点写入耐久存储，不要等「第一次进度回调」。
- 能交给系统执行器的传输就交；不能的，在下次冷启动读未完成列表并从断点续。
- 重启后第一眼能看见未完成件，状态诚实地区分「系统还在跑」和「打开后会续」。
- 验证：开始一次至少两分钟的导出或上传，划掉应用，等进程死。再打开：任务应还在，进度不从零。再做一次：开始后立刻重启设备。开机进入产品，任务应恢复或显示可恢复，已完成的那一段不应重做。若重启后列表空了，对象已死。