ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

状态机卡片、服务卡片、小艺建议卡片怎么选:HarmonyOS 7 先判断任务再画界面

状态机卡片、服务卡片、小艺建议卡片怎么选:HarmonyOS 7 先判断任务再画界面 状态机卡片、服务卡片、小艺建议卡片怎么选HarmonyOS 7 先判断任务再画界面同一份“下载进度”设计稿被同时做成状态机卡片、服务卡片和小艺建议卡片结果信息密度、停留时长和交互都不合适。华为在 2026 年 9 月更新的鸿蒙卡片指南明确区分了多类卡片状态机卡片用于把任务过程可视化服务卡片承载长期复访的信息与操作小艺建议卡片强调出现时机和推荐理由。先选类型再画视觉。先把边界说明白关注点应该怎么理解容易踩的坑状态机卡片有明确触发、流程持续、需要稳定反馈不适合长期复访入口服务卡片高频或长期复访、核心信息直达信息和操作仍需克制小艺建议卡片由场景触发的主动建议必须解释推荐理由并建立信任这张表不是把官方文档换一种说法而是把接口边界变成能检查的工程条件。适配前先确认当前应用是否命中条件再决定是否改代码。没有命中的模块不应为了“统一写法”一起重构命中的模块也不能只改到编译不报错。案例一根据任务属性做类型决策把触发是否明确、是否长期复访、是否强时效和是否需要桌面常驻作为输入。下面是项目内部的示例决策树用于防止团队先画好卡片再硬套类型最终仍需对照官方设计和当前产品入口。type CardNeed { triggered: boolean; revisit: boolean; timeSensitive: boolean; proactive: boolean }; function chooseCard(n: CardNeed): state|service|suggestion { if (n.proactive) return suggestion; if (n.triggered n.timeSensitive !n.revisit) return state; return service; } if (chooseCard({ triggered:true, revisit:false, timeSensitive:true, proactive:false }) ! state) throw new Error(任务型卡片选择错误); if (chooseCard({ triggered:false, revisit:true, timeSensitive:false, proactive:false }) ! service) throw new Error(复访型卡片选择错误);这一段先验证外围决策。它的价值是让输入和结果可重复不依赖页面当前碰巧处于什么状态接入 ArkUI 或系统能力时再把结果映射成实际节点、路由或接口调用。案例二同一数据在三类卡片中使用不同信息密度快递数据可以有三种表达状态机卡片突出当前位置和下一节点服务卡片展示待收列表与常用操作建议卡片只在“即将送达”时出现并解释为何提醒。共享的是数据模型不是完整 UI。先把每类卡片限制为一个主目标再决定辅助按钮。type Parcel { state: moving|arriving|done; count: number }; function primaryMessage(kind: state|service|suggestion, p: Parcel): string { if (kind state) return p.state arriving ? 即将送达 : 运输中; if (kind suggestion) return 预计今天送达建议留意接听; return 待收包裹 p.count 件; } if (!primaryMessage(suggestion,{state:arriving,count:2}).includes(建议)) throw new Error(建议卡片缺少理由);第二个案例故意覆盖与第一个不同的失败条件。真实工程还应加入快速重复操作、前后台切换、窗口尺寸变化、空数据和恢复路径避免只验证一次成功流程。为什么选择这种做法一套模板改颜色虽然快却会抹平卡片职责。共享数据适配器和设计 token 即可信息结构、出现时机和交互需要分别设计。最新指南还强调色彩克制、主体清晰、深浅色适配和信息量控制验收时必须看桌面实际缩略尺寸。如果团队准备封装建议把公开接口保持在“输入事实、输出决策”的层级不让调用方直接依赖底层节点对象。这样既方便复用也便于写断言需要系统能力的部分留在薄薄的适配层升级时更容易定位。怎样验证哪些结论还不能提前说先把验证分成三层。第一层是纯逻辑输入、状态转换和边界条件可以在宿主环境运行断言第二层是 API 26 编译检查接口签名、系统能力和模型约束第三层才是目标设备检查触摸、键鼠、屏幕朗读、横竖屏、窗口缩放和前后台恢复。三层证据不能混在一句“已经跑通”里。当前示例中的纯 TypeScript 决策函数可以独立测试用于证明分支没有自相矛盾涉及 ArkUI 节点、系统手势、跨设备能力和系统服务的片段仍要使用 API 26 SDK 编译并在支持该能力的 HarmonyOS 7 设备或云调试设备上验收。这样写不是保守而是避免把没有发生过的真机结果当成事实。动态页面还要观察状态变化后的第二次结果首次进入正确不代表弹窗关闭、列表更新或窗口缩放后仍然正确。每次状态切换都应重新核对当前节点、焦点目标、返回路径和数据快照避免旧缓存继续影响新页面。建议每次留下以下记录DevEco Studio、SDK、targetSdkVersion 和设备系统版本。触发输入、页面层级、窗口尺寸、操作方式与最终状态。正常路径、空数据、快速重复操作、旋转或窗口缩放后的结果。屏幕朗读、字体放大、深浅色和键盘焦点是否仍然可用。性能对照使用同一批数据、同一设备状态和同一测量区间。可以复用成什么不要把适配判断散落在页面 Builder 中。更稳的结构是“能力探测或尺寸输入 - 纯函数决策 - 页面渲染 - 设备证据”。纯函数负责输出稳定的布局或交互意图页面只消费结果下一次系统升级时优先修改边界层和测试样本不必把所有页面重新翻一遍。发布前自查文章讨论的是 HarmonyOS 7 / API 26 当前资料不拿旧版本页面替代新接口。两个案例的输入、失败现象和解决目标不同不是同一段代码换名称。代码中的常量有来源没有来源的数值明确写成示例策略不伪装成系统规定。性能、兼容性与无障碍结论都有可重复的检查方法。日志不保存账号、文件内容、设备标识和其他敏感数据。官方资料鸿蒙卡片设计指南2026 年 7 月开发者月刊
返回列表