I3.07.3task list as required surface设计
任务列表是长时操作的必需组件
别名: 任务中心 · 后台任务列表 · job list · 导出列表
概念解释
只要产品允许把工作丢到后台跑，就必须有一张任务列表：正在跑的、跑完的、失败的，按件陈列，能点进去。列表是组件，不是某次进度条的集合。人会同时丢出好几件（三份导出、一次视频转码、一次备份），没有列表，查询和通知都没有落点——通知点开只能回首页，进度只能回当时那一页，那一页可能已经卸了。
这条把列表定为长时操作的必需表面。列表里能不能排序、取消、显示耗电，是长任务调度的问题；这里只要承认：没有这张表面，长时操作在界面结构上不完整。
机制
一件后台任务是一个对象：有身份、有寿命、有终态。对象必须有容器。页面级进度条把对象寄生在「当时所在的那一页」，页一走，寄生关系断。通知把对象压缩成一句，一句点开需要一个稳定的目的地。列表就是那个目的地，也是多对象并存时的索引。没有索引，第二件任务在第一件还没结束时被发起，人便失去对第一件的句柄。
长时操作还跨会话。第二天打开产品，人问的不是「当前页的条」，是「昨天那几件怎样了」。问句的语法是列表：按件、按时间、按状态过滤。把这个问句实现成散落的 toast 历史或只能搜邮件，等于没有一等公民的任务对象。
边界
整个产品永远只有一件、且人被钉在那一屏直到结束（安装向导、单次系统更新），列表可以退化成这一屏。一旦允许离开或允许第二件并行，退化立刻失效。极短的后台（发一张图三秒）可以只进通知不进长期列表，但若失败需要事后查找，仍应在短时列表里留几分钟。权限不够看见别人的任务时，列表按身份过滤，不是取消列表。嵌入式设备没有「页面」的，列表可以是一条可翻的状态槽，结构仍是多件可寻址。
怎么落地
- 提供一处全局可达的任务表面：进行中与最近终态同在，每件可点开。
- 从进度查询和完成通知两边都能落到同一件的详情，而不是两套互不相认的记录。
- 列表在零件时仍可打开并说明「没有进行中的任务」，避免入口本身时有时无。
- 验证：连续发起两件导出，离开原页。打开任务入口应看见两件，而不是只看见后一件或什么都没有。点通知应进入列表中的那一件。第二天冷启动，已完成的那件仍应能找到，直到用户清掉或过了保留期。