logo
publist
写文章

简介

该用户还未填写简介

擅长的技术栈

可提供的服务

暂无可提供的服务

灯光模拟HarmonyOS应用实战-64-请选择答案为何显示成功色-用FeedbackState表达中性过程与结果

用户尚未选择答案时,提示条如果复用“正确”样式,就会用成功色表达中性过程,误导当前判题状态。本文用 FeedbackState 区分未作答、提交中、正确、错误和异常,统一颜色、图标、文案与无障碍语义,并给出状态迁移和回归矩阵。

文章图片
灯光模拟HarmonyOS应用实战-63-答对一题为何显示合格-用RecordKind区分单题作答与整场考试

单题答对后直接复用整场考试结果模型,页面会把一次正确作答渲染成“合格”,历史记录也难以区分练习与考试。本文引入 RecordKind,拆分单题结果、场次成绩与展示文案,并给出存储迁移、统计口径和边界测试。

文章图片
灯光模拟HarmonyOS应用实战-60-全量洗牌再取20题会丢分类配额:用考试蓝图做分层抽样

把完整题库随机洗牌后直接取前20题,会让小分类在某些场次完全缺席。本文以考试蓝图定义分类配额,拆解分桶、桶内洗牌、逐桶抽取与库存不足策略,并给出可复现测试和统计验收,让随机顺序服从稳定的考试结构。

文章图片
灯光模拟HarmonyOS应用实战-66-JSON语法合法字段仍可能非法-逐字段解码软硬损坏与幂等修复

JSON.parse 成功只证明语法合法,不能保证 exam_history 的字段类型、枚举值和时间范围可用。本文从旧记录读取边界出发,设计逐字段解码、软硬损坏分级、可追踪修复回执与幂等迁移,并给出 ArkTS 示例和验证矩阵。

文章图片
灯光模拟HarmonyOS应用实战-62-保证近光为何还要再点一次-普通灯光与实操超时分支对齐

“保证近光”场景下再次点击近光,本应是幂等确认,却可能被普通灯光分支判成多余操作;实操倒计时又使用另一套规则。本文统一动作归约、前置状态、超时语义与判题回执,让普通练习和实操考试对同一灯光动作给出一致结果。

文章图片
灯光模拟HarmonyOS应用实战-65-onRestore收到BundleVersion却只记日志-用版本握手与回读回执对账exam_history

onRestore 收到 BundleVersion 后只打印日志,无法确认 exam_history 是否完成迁移,也无法区分旧版、部分修复和回写失败。本文设计版本握手、逐步迁移、写后回读与 RestoreReceipt,让恢复过程可重试、可审计且保持幂等。

文章图片
灯光模拟HarmonyOS应用实战-61-自动题ID跟着循环位置漂移:用sourceKind、seedId与generatorVersion固定身份

自动题ID如果来自全局循环位置,新增种子或调整遍历顺序就会让收藏、错题和历史记录指向别的题。本文用 sourceKind、seedId、generatorVersion 与种子内 variantIndex 建立稳定身份协议,并设计旧ID迁移、冲突检测和无法确认时的保守降级。

文章图片
灯光模拟HarmonyOS应用实战-59-生成1000题不代表规则都覆盖:用RuleId与场景维度建立覆盖账本

批量生成1000道题只能证明数量够,不能证明每条灯光规则、场景组合和错误分支都被覆盖。本文设计 RuleId、场景维度、覆盖账本与缺口报告,把题目生成、去重和规则覆盖分开核算,并用验证矩阵约束新增规则不会静默漏题。

文章图片
灯光模拟HarmonyOS应用实战-57-科二分类从两个入口传成两套:用PracticeQuery统一练习上下文

科目二分类从首页与题库页进入时,如果分别拼装 category、mode 和 questionType,页面很容易得到两套含义相同却字段不同的上下文。本文结合现有入口链路,设计 PracticeQuery 解析、归一化、默认值与会话快照,并用契约测试守住深链、返回和恢复行为。

文章图片
灯光模拟HarmonyOS应用实战-58-搜索命中前40题不等于最相关:用MatchScore构建稳定TopK

搜索结果先取前40题再排序,会把真正相关的候选提前截掉,且相同分数下顺序可能漂移。本文从题库匹配链路出发,设计 MatchScore、稳定次级键、TopK 小根堆与可解释命中明细,并给出 ArkTS 实现、边界用例和性能验收方法。

文章图片
    共 189 条
  • 1
  • 2
  • 3
  • 19
  • 请选择