文件批量整理、图片备份和资料同步都可能持续上报进度。当任务执行层每秒产生数十次更新时，球态入口只需要展示一个概要百分比，展开窗口需要展示当前任务与操作按钮，完整任务中心还要保留队列顺序和历史记录。若三个界面都直接监听原始事件，每个进度变动都会触发多份状态写入，页面树更新与布局计算可能集中到同一时间段，反而让原本轻量的交互变得迟缓。 此前七篇已经建立TaskPhase状态机、球窗共享快照、幂等切换、

轻任务中心的执行状态、球态摘要和展开窗口已经通过同一套快照同步，并能在前后台切换时重新核对任务事实。真正上线前还有一条关键路径：当轻量窗口创建失败、当前页面上下文失效、用户没有授权相册资源，或者后台恢复的任务数据已经过期，任务应该怎样继续？如果一个悬浮入口失效就把整个任务标记成失败，用户可能会误以为正在整理的文件也丢失了；如果权限不足时仍自动重试，界面又可能陷入反复弹出请求的循环。 这篇关注能力可

一个资料整理任务已处理到68%，用户切换到其他应用。回到任务中心后，球态还停留在68%，展开窗口显示“处理中”，实际上执行服务已经被中断；再按一次继续，又出现两次启动请求。问题不是进度控件显示得慢，而是前后台切换时执行状态、持久快照和界面订阅没有按统一规则衔接。 此前五篇已经建立了任务状态机、窄宽布局、球窗切换命令、进度事件版本与跨页面共享快照。这些设计覆盖同一进程内的界面变化，但前后台切换带来了

一个批量文件整理任务正在执行。用户在任务中心看到进度为64%，切回主页面的球态摘要却停留在52%；从紧凑入口展开轻量窗口后，暂停按钮又显示为“继续”。三处界面读取了不同时间点的数据，导致用户无法判断任务究竟处于什么阶段。这种问题的根源往往不在控件，而在于多个页面各自维护任务副本。 前面的文章已建立轻任务队列、球窗视觉密度切换和触控命令网关。本篇进一步处理跨页面状态：同一进程内的任务中心、应用首页及

轻任务表面越小，用户对反馈的容忍度就越低。一个圆形入口可能只展示任务名称和进度，展开后的轻量窗口则需要暂停、继续、取消等操作。如果点击后界面没有变化，用户容易重复触发；如果进度条能够随意拖到100%，又会把操作意图误写成真正的任务完成情况。解决问题的关键不是增加动画，而是把“触控指令”“任务执行状态”“可视反馈”分成三条清晰的数据链。 前面已经搭建轻任务队列、窄窗与宽窗布局以及球窗切换状态管理。本

文件整理工作台已经建立任务队列，也设计了紧凑和展开两种信息密度。接下来的问题出现在切换那一瞬间：用户点击球态入口，展开任务窗的过程中恰好有一项归档任务完成；如果球态与窗态各自维护进度，很容易出现球上还显示“3项进行中”，展开后却只看到2项。反复点击、返回以及页面重建也可能造成窗口叠加、任务进度回退或按钮被重复响应。 与其把“球变成窗”当作一次组件创建，不如把它当作展示状态的一次受控迁移。本节延续

文件整理工作台正在处理文档归档、图片分类和报告生成时，用户希望只看一眼就知道还有几项待处理；需要排查某项失败原因时，则希望展开完整内容。这两个场景需要的信息密度完全不同。若把业务页里的任务列表按比例缩小塞进轻量窗口，往往会出现进度条拥挤、按钮截断和误触。窗口尺寸变化不仅是 width 数值变化，更是任务信息优先级的重新排列。 前一节建立了 TaskRecord、TaskQueue、TaskPhas

用户在阅读资料、处理订单或上传文件时，往往不愿意一直留在同一个业务页面等待进度。轻量入口可以把“当前还有什么正在处理”放在更容易触达的位置：收起时只留下任务数量与最重要的状态，展开时再显示具体任务、进度和可操作项。HarmonyOS SDK 26 提到了闪控窗 ArkUI 悬浮窗与闪控球的新交互形态。对应用开发而言，窗口外观之外最先需要解决的是同一个任务在球态、窗态和业务页之间始终只有一份可信状态

一套阅读工作台能在手机、折叠屏和平板上切换单栏与双栏，并能恢复文章、目录与阅读锚点，还不能直接说明它已经具备长期使用所需的稳定性。列表中有二百篇文章时，快速滑动会不会因为全量创建节点而拖慢交互？连续切换文章后，旧请求会不会把右侧正文覆盖回去？窗口收窄再展开，选择状态和路由栈是否仍然对应？这些问题需要放在同一组回归场景里处理。 前面的内容已经把业务选择、NavPathStack、分栏比例与持久会话分

阅读工作台已经能在折叠屏与平板间切换栏位，也能在再次进入应用时恢复文章和阅读锚点。但到了真正的长时间阅读场景，界面仍有一类容易被忽略的问题：用户在左侧列表切换文章，右侧的正文和批注要跟着变化；用户调整分栏比例，阅读位置不应清零；临时打开文章详情后返回，列表选中项与目录高亮需要指向同一个业务对象。若把每个区域当成独立页面实现，很容易在一次操作中产生两次路由跳转、两次网络请求或者两个互相覆盖的选中状态