摘要

本文围绕 HarmonyOS 6.1.1(API 24) 中的 Live View Kit 方向，讨论持续任务状态如何从应用页面延伸到系统级入口。文章以医院取号排队、检查报告生成、配送和下载等场景为例，给出实况窗的状态机设计、应用侧架构、隐私保护、持久化恢复、异常收口和测试清单。

关键词：HarmonyOS 6.1.1；API 24；Live View Kit；实况窗；持续任务；状态机；隐私保护

图 1  HarmonyOS 6.1.1 Live View Kit 能力地图

文章目录

• 1. 为什么实况窗不是“更大的通知”
• 2. 判断一个功能能不能做实况窗
• 3. 状态机是实况窗的核心
• 4. 应用侧架构要把系统能力封装起来
• 5. 医院取号排队案例
• 6. 隐私：系统可见位置必须更克制
• 7. 持久化：清后台后仍要恢复状态
• 8. 代码案例一：任务状态模型
• 9. 代码案例二：LiveViewAdapter
• 10. 代码案例三：异常恢复
• 11. 交互设计：按钮要少而准
• 12. 性能：更新频率要节制
• 13. 审核注意点：实况窗必须尊重用户控制权
• 14. 测试清单
• 15. 本文小结
• 15. 场景矩阵
• 16. 参考资料

1. 为什么实况窗不是“更大的通知”

HarmonyOS 6.1.1 API 24 的 API 变更列表中出现 Live View Kit，这说明持续任务的状态表达正在成为系统级体验的一部分。实况窗适合那些用户离开应用后仍然关心进度的任务，例如外卖配送、网约车行程、运动训练、计时器、下载上传、挂号排队和检查报告生成。它不是把普通通知换个样式，而是把“任务状态”放在系统可见位置，让用户不必反复打开应用确认进度。

2. 判断一个功能能不能做实况窗

不是所有业务都适合实况窗。高质量判断标准有三个：第一，任务有明确开始和结束；第二，状态会随时间变化；第三，用户在应用外也需要知道进度。如果只是普通公告、营销提醒或一次性消息，就不应该占用实况窗。过度使用会降低用户信任，甚至让审核认为通知体验打扰用户。

3. 状态机是实况窗的核心

实况窗最怕状态混乱：页面显示已完成，系统入口还在排队；用户取消订单后，实况窗仍然显示骑手正在路上。解决办法是引入状态机，把任务拆成 pending、running、paused、failed、completed、cancelled、expired 等稳定状态。所有页面、通知和实况窗都从同一状态机读取文案、进度、按钮和下一步动作。

4. 应用侧架构要把系统能力封装起来

页面不应该直接操作 Live View Kit。推荐建立 LiveViewAdapter，把创建、更新、关闭、降级、异常转换封装起来；业务层只提交任务状态。这样 API 变更或设备不支持时，只改适配层即可。适配层还可以统一做节流，避免状态频繁更新造成耗电或系统压力。

图 2  实况窗应用侧分层架构

5. 医院取号排队案例

医护相关应用非常适合说明实况窗价值。用户挂号成功后，实况窗显示科室、候诊状态、前方人数和预计时间；进入检查阶段后，显示排队、检查中、报告生成等状态。为了隐私，实况窗不展示完整姓名、诊断病名和身份证号，只展示就诊序号、科室和必要时间。任务完成后自动收口，进入历史记录。

图 3  医院取号与检查排队案例

6. 隐私：系统可见位置必须更克制

实况窗经常出现在锁屏、状态栏或系统级入口附近，因此隐私标准要高于普通页面。展示内容应遵循最小化原则：外卖可以显示“正在配送”，但不必展示完整地址；医院排队可以显示“检查排队中”，但不应展示疾病名称；企业审批可以显示“有待处理事项”，但不显示合同金额或客户全称。

7. 持久化：清后台后仍要恢复状态

审核和真实用户都会遇到清后台、系统回收、重启后再打开应用的场景。实况窗状态不能只存在内存里。创建任务时应写入本地存储，更新时同步落盘，启动时根据任务过期时间和服务端状态恢复。如果任务已经超时或服务端显示完成，应用应主动关闭实况窗并更新页面。

图 4  一次实况窗任务的完整生命周期

8. 代码案例一：任务状态模型

下面的模型把业务任务和实况窗状态分离。业务可以是订单、排队、训练或下载，实况窗只关心标题、阶段、进度、动作入口和隐私级别。

export type LiveTaskState =
  'pending' | 'running' | 'paused' | 'failed' | 'completed' | 'cancelled' | 'expired'

export interface LiveTask {
  id: string
  scene: 'queue' | 'delivery' | 'training' | 'download'
  title: string
  stageText: string
  progress?: number
  privacyLevel: 'publicSafe' | 'masked' | 'sensitive'
  state: LiveTaskState
  expireAt: number
}

9. 代码案例二：LiveViewAdapter

适配层负责把任务状态转换成系统能力调用。示例使用伪代码表达结构，真实项目应结合官方 Live View Kit API 和设备能力检测实现。

export class LiveViewAdapter {
  async publish(task: LiveTask): Promise<void> {
    if (!this.isSupported()) {
      return this.fallbackToNotification(task)
    }
    const viewData = this.toLiveViewData(task)
    // 调用官方 Live View Kit 创建或更新实况窗
    await liveViewClient.update(task.id, viewData)
  }

  async close(taskId: string): Promise<void> {
    await liveViewClient.finish(taskId)
  }
}

10. 代码案例三：异常恢复

异常恢复要有明确策略：网络失败时保留最后状态，任务超时时转为 expired，用户取消时立即关闭入口。不要让实况窗卡在“进行中”。

async function recoverLiveTasks() {
  const tasks = await taskStore.loadUnfinished()
  for (const task of tasks) {
    const latest = await server.queryTask(task.id)
    if (Date.now() > task.expireAt || latest.done) {
      await liveViewAdapter.close(task.id)
      await taskStore.markFinished(task.id)
    } else {
      await liveViewAdapter.publish({ ...task, ...latest })
    }
  }
}

11. 交互设计：按钮要少而准

实况窗上的操作入口不宜太多。常见按钮包括查看详情、取消任务、继续播放、打开导航、联系服务方。按钮越多，误触概率越高，也越难在不同设备形态上保持一致。高质量设计是把复杂操作放回应用页面，实况窗只保留一到两个关键动作。以医院排队为例，实况窗上可以保留“查看详情”和“取消提醒”，但不应该放缴费、评价、联系客服、改约时间等复杂入口。复杂入口需要上下文、确认弹窗和更多说明，放在应用页面里更安全。

12. 性能：更新频率要节制

实时并不等于每秒更新。倒计时、配送距离和上传进度都可以做节流：只有状态变化明显或达到时间间隔时才更新。频繁更新会增加耗电和系统负担。建议把不同任务分级：秒级任务只用于短时间计时，分钟级任务用于排队和配送，事件级任务用于审批和报告生成。开发时还要避免把服务端轮询、动画刷新和本地持久化绑在同一个高频定时器里，否则用户看见的只是一个小入口，背后却可能造成持续耗电。更稳的做法是服务端推送优先，本地定时兜底，进度变化不足阈值时不刷新。

13. 审核注意点：实况窗必须尊重用户控制权

审核视角会关注实况窗是否打扰用户、是否泄露隐私、是否在任务结束后仍然存在。应用应提供关闭提醒或返回应用管理的入口，任务取消后要立即收口，异常超时后不能长期停留。对于医护、金融、企业办公等敏感场景，还要特别检查锁屏可见内容：如果旁人能从系统入口看到病情、金额、合同客户或身份证信息，就属于设计失败。开发者可以把隐私字段分级，默认只显示安全摘要，进入应用并完成身份校验后再显示完整内容。

图 5  实况窗常见问题与高质量设计

14. 测试清单

测试要覆盖任务创建、状态更新、用户点击入口、取消、失败、超时、应用清后台、系统回收、网络恢复、服务端状态变化、隐私字段脱敏和设备不支持降级。尤其要验证任务结束后实况窗是否清理，否则用户会觉得应用一直占着系统入口。建议把测试拆成三组：第一组测正常生命周期，确认从开始到完成没有状态跳跃；第二组测异常生命周期，包括断网、服务端取消、用户手动取消和任务过期；第三组测隐私和降级，确认锁屏展示安全、低版本设备仍能通过通知或页面入口完成任务。

15. 本文小结

Live View Kit 的价值在于把持续任务从应用内部带到系统体验中。真正高质量的实况窗，不是视觉更醒目，而是状态统一、隐私克制、可恢复、可关闭、可降级。开发者应先设计任务状态机，再考虑系统入口展示。只要状态源统一、落盘恢复可靠、隐私字段可控，实况窗就能成为服务体验的加分项；反过来，如果状态混乱、更新频繁、任务结束不清理，它就会变成用户体验和审核风险。

15. 场景矩阵

场景	适合展示的状态	不应展示的内容
医院排队	科室、序号、前方人数、预计时间	完整姓名、病名、身份证号
配送服务	已接单、配送中、即将送达	完整住址、手机号
运动训练	训练中、暂停、完成率、剩余时间	健康敏感结论
文件上传	上传进度、失败重试、完成	完整文件内容或敏感文件名