鸿蒙ArkTS交互状态机：切词作废、重跑重置与转移表回归

鸿蒙专家

离线文搜图应用「分拣线」把 24 张图逐张送过传送带，按四路规则拨进不同槽口。算法怎么归类是另一条线，本文只讨论鸿蒙应用里常被忽略的一件事：用户是怎么操作这台机器的，以及这些操作该由什么样的状态机来约束。素材来自 Mate 90 Pro 模拟器（HarmonyOS 7.0 / API 26）上的五张实机截图，文中的状态机、守卫与回归断言是可复现的交互分析代码，并非该工程已提交的实现。

一、五张截图拼出的操作路径

首屏处于 READY：24 张图已全部入库，四路分拣口各有一个词，传送带空转，三枚控制按钮待命。这一屏承担的是「承诺」——让用户看清有哪些槽、可以怎么调、按哪里开始。一个值得注意的可见事实是：首屏只完整显示 01 号槽，右侧仅露出相邻槽的一点边缘，四路并行这件事并没有在第一眼被传达。

第二张是 RUNNING 的中间帧：工位 3/24，当前卡片带着「→ 暖 · 实测 8% · 39 分」的判定，槽口计数在涨，队列缩略图向前挪。用户看到的是过程，而不是一次性弹出的结果。

第三张是 DONE：统计条、归类网格、按钮文案（变为「重新分拣」）同时切换。一次状态跃迁牵动四处 UI，任何一处没跟上，都会产生「看起来结束了但数字还在动」的割裂感。

第四张留下两次用户操作的痕迹：点了 01 号槽换词，又把速度拧到 4×。这两个操作都必须触发旧结果作废，否则界面会出现「规则已经变了，网格还是上一轮」这种最难排查的不一致。

第五张是第二轮 DONE。与第一轮对照：退回数 3 → 0，命中率 88% → 100%，01 号槽 2 张 → 19 张。同一个人、同一台机器，只改了控件，操作路径就完全重写了结果——这正是把状态机单独拎出来研究的价值。

二、把分散的 onClick 收进显式转移表

与其让规则散落在各个回调里，不如先写一张转移表。类型定义覆盖 IDLE、READY、RUNNING、PAUSED、DONE 五个阶段，以及 LOADED、START、PAUSE、RESUME、TICK_DONE、CHANGE_RULE、RERUN、SPEED 八类事件：

2. export type Stage = 'IDLE' | 'READY' | 'RUNNING' | 'PAUSED' | 'DONE';
3. export type Event =
4. | 'LOADED' | 'START' | 'PAUSE' | 'RESUME' | 'TICK_DONE'
5. | 'CHANGE_RULE' | 'RERUN' | 'SPEED';
7. export interface Ctx {
8.   stage: Stage;
9.   libSize: number;
10.   cursor: number;
11.   speed: number;
12. }
14. export interface Transition {
15.   next: Stage;
16.   action: string; // 由调用方映射到具体副作用
17. }
19. export function reduce(s: Ctx, e: Event): Transition {
20.   switch (e) {
21.     case 'LOADED':
22.       return { next: s.libSize > 0 ? 'READY' : 'IDLE', action: 'refreshIndex' };
23.     case 'START':
24.       if (s.libSize === 0) return { next: s.stage, action: 'noop' };
25.       return { next: 'RUNNING', action: 'classifyAndReset' };
26.     case 'PAUSE':
27.       return s.stage === 'RUNNING'
28.         ? { next: 'PAUSED', action: 'stopClock' }
29.         : { next: s.stage, action: 'noop' };
30.     case 'RESUME':
31.       return s.stage === 'PAUSED'
32.         ? { next: 'RUNNING', action: 'startClock' }
33.         : { next: s.stage, action: 'noop' };
34.     case 'TICK_DONE': {
35.       if (s.stage !== 'RUNNING') return { next: s.stage, action: 'noop' };
36.       const nextCursor = s.cursor + 1;
37.       return nextCursor >= s.libSize
38.         ? { next: 'DONE', action: 'commitAndFinalize' }
39.         : { next: 'RUNNING', action: 'commitAndAdvance' };
40.     }
41.     case 'CHANGE_RULE':
42.       return { next: 'READY', action: 'invalidateResults' };
43.     case 'RERUN':
44.       return s.libSize > 0
45.         ? { next: 'RUNNING', action: 'classifyAndReset' }
46.         : { next: s.stage, action: 'noop' };
47.     case 'SPEED':
48.       return { next: s.stage, action: 'changeTempo' };
49.   }
50. }

复制代码

关键在于把 CHANGE_RULE 的 action 明确写成 invalidateResults：规则是查询的一部分，规则一变，旧分组就是脏数据。这个不变量如果只靠「记得在 onClick 里 reset()」来维持，迟早漏掉某条路径，比如以后新增「导入预设」。SPEED 既不动状态也不动作废，是另一个刻意区分：改节奏不该让已归类的图重新算，用户可以一边看一边调速，这是计算与呈现解耦带来的自由度。

三、四个分拣口的控件语义

四路槽口做的是同一件事：显示一个词、一个颜色、一个计数，点击切到词池里的下一个词。里面藏着三个约定。

第一，点击是循环，不是打开选择器。词池 10 个词，点一次前进一步、到尾回绕。好处是零额外 UI、单手可达，代价是想切到远处的词要连点多次；在「随手试不同配法」的场景里，这个取舍合理。

第二，同槽重复词是合法的。四路各自独立循环，完全可能把两路都切成「复杂」。此时同一条规则出现两次，argmax 总取先出现的那一路，另一路永远收不到图。这不是 bug，但界面没有任何提示——状态机允许的状态，未必是用户想要的状态。

第三，槽位在 RUNNING 时也能点。转移表允许，代价是立即作废整轮结果。更友好的做法是加守卫：运行中切词先弹确认，或把切词排队到 DONE 之后。

2. export interface SlotState {
3.   word: string;
4.   color: string;
5.   count: number;
6. }
8. export function cycleWord(pool: string[], slots: SlotState[], idx: number): SlotState[] {
9.   const next = slots.slice(); // 整体替换，触发 UI 刷新
10.   const cur = next[idx];
11.   const p = pool.indexOf(cur.word);
12.   next[idx] = {
13.     word: pool[(p + 1) % pool.length],
14.     color: cur.color, // 颜色属于槽位，不属于词
15.     count: 0
16.   };
17.   return next;
18. }
20. export function duplicateRules(slots: SlotState[]): string[] {
21.   const seen = new Set<string>();
22.   const dup: string[] = [];
23.   for (const s of slots) {
24.     if (seen.has(s.word)) dup.push(s.word);
25.     seen.add(s.word);
26.   }
27.   return dup; // 非空时可在槽位上打小标记，提示该规则不会收到图
28. }

复制代码

「颜色属于槽位而非词」也值得强调：词换了颜色不变，用户才能持续追踪「01 号槽的计数」这条线索；如果颜色跟着词走，切一次词整屏色彩重排，短时记忆就断了。

四、340ms 节拍究竟在服务谁

引擎把 24 张图全部分完是毫秒级的事，界面却按节拍逐张揭晓。交互上要回答的不是「为什么要慢」，而是「这段时间用户读到了什么」。以默认 340ms 估算两轮实跑时长：

2. export interface Tempo {
3.   speed: number;
4.   perTickMs: number;
5.   totalMs: number;
6. }
8. export function tempoOf(speed: number, count: number): Tempo {
9.   const perTickMs = Math.round(340 / speed);
10.   return { speed: speed, perTickMs: perTickMs, totalMs: count * perTickMs };
11. }
12. // 24 张：1× → 340ms × 24 = 8.16s；4× → 85ms × 24 = 2.04s

复制代码

截图里第二轮拧到 4×，全程压到约 2 秒，但判定内容一字未变。这说明节拍是纯呈现层参数，不参与任何计算，这也正是它能被随手调节的前提。代价同样明确：4× 提升的是吞吐，损失的是可读性，第二轮判定标签在快速翻动中几乎只能看到颜色闪动。更贴心的设计是把速度切换做成「跳到结果」而非「加速播放」，数据不变，但用户不必在 85ms 里读懂一句话。

进度在不同状态下语义不同，这里最容易出错。另一条纪律是把完成度和 ETA 分开呈现：

2. export interface Progress {
3.   done: number;
4.   total: number;
5.   etaMs: number | null; // null = 不承诺时间
6. }
8. export function progressOf(cursor: number, total: number,
9.   perTickMs: number, paused: boolean): Progress {
10.   return {
11.     done: cursor,
12.     total: total,
13.     etaMs: paused ? null : (total - cursor) * perTickMs
14.   };
15. }

复制代码

PAUSED 时把 etaMs 置空，而不是显示「剩余 3.4 秒」再凝固不动，是一种很小但很重要的诚实：暂停期间没有 ETA 这回事。

五、五条误操作守卫

把状态机写成表之后，「哪些操作会毁掉数据」就一目了然。

其一，暂停不能多吃一张。节拍用 await sleep() 实现，暂停恰好可能发生在睡眠期间，醒来必须复查状态，否则「暂停」会静默多提交一张图。

2. async function tickLoop(ctx: { running: boolean; cursor: number; total: number },
3.   commit: (i: number) => void): Promise<void> {
4.   while (ctx.running && ctx.cursor < ctx.total) {
5.     const i = ctx.cursor;
6.     await sleep(340);
7.     if (!ctx.running) return; // 睡眠期间被暂停：保留工位，不提交
8.     commit(i);
9.     ctx.cursor++;
10.   }
11. }

复制代码

其二，重跑必须是全量重置。计数、网格、当前工位、选中项、状态灯一起归零，只重置其中几项会留下「上一轮的 19 张」和「这一轮的第 3 张」并存的画面。其三，切词作废且作废要可见：光清空数据不够，最好让状态灯回到 READY、按钮文案变回「启动分拣」，让用户看见结果已失效。其四，速度切换不动数据。其五，点选详情时结果集不能正在被覆盖——用户点开某张图看依据的瞬间，若恰好触发新一轮重算，详情面板会指向被作废的对象，因此选中项应在 invalidateResults 里一起清空。

2. export interface UiState {
3.   stage: Stage;
4.   cursor: number;
5.   counts: number[];
6.   grouped: number[];
7.   selectedId: number;
8.   tempo: number;
9. }
11. export function invalidate(s: UiState): UiState {
12.   return {
13.     stage: 'READY',
14.     cursor: 0,
15.     counts: [0, 0, 0, 0],
16.     grouped: [],
17.     selectedId: -1,
18.     tempo: s.tempo // 唯一被保留的状态：用户选的速度
19.   };
20. }

复制代码

保留 tempo 是有意的：速度是用户偏好，不是某轮结果的一部分。把偏好和结果分开，重跑才不会顺手把 4× 拧回 1×。

六、状态正确不等于信息可见

回到首屏只显示一个槽这件事。四路槽口横排、每路占整行宽度，从状态机角度看完全正常（四路都在工作），但从信息传达角度看，「四路并行」这个核心概念没有在第一眼被交付。作者给出三种处置方式，代价各不相同，更一般的教训是：槽口计数、退回数、命中率在状态机里从来没错过，可用户若看不到 02~04 号槽，就很难理解「为什么 01 号槽只有 2 张、其余 21 张去哪了」。

再往下是颜色与可访问性。四槽用四种高饱和色区分，深色底上对比度充足，但仅靠颜色传达归属，对色觉差异用户不友好；归类网格里同时印了规则名文字，这一层冗余是对的。「退回」用灰框而非红框，语义准确：它不是错误，是「没有规则达标」。状态灯用绿/琥珀两色加英文文案（RUNNING / DONE）双编码，比纯色点更可辨。

七、把状态机变成可回归的断言

交互 bug 难测，是因为它们常散落在 onClick 里、依赖真实时间。把 reduce 提成纯函数之后，一条状态转移就是一行断言，不需要模拟器、不需要等待。

2. interface Case {
3.   name: string;
4.   ctx: Ctx;
5.   event: Event;
6.   wantStage: Stage;
7.   wantAction: string;
8. }
10. const CASES: Case[] = [
11.   { name: '空库不能启动', ctx: { stage: 'READY', libSize: 0, cursor: 0, speed: 1 },
12.     event: 'START', wantStage: 'READY', wantAction: 'noop' },
13.   { name: '启动进入运行', ctx: { stage: 'READY', libSize: 24, cursor: 0, speed: 1 },
14.     event: 'START', wantStage: 'RUNNING', wantAction: 'classifyAndReset' },
15.   { name: '最后一拍收尾', ctx: { stage: 'RUNNING', libSize: 24, cursor: 23, speed: 1 },
16.     event: 'TICK_DONE', wantStage: 'DONE', wantAction: 'commitAndFinalize' },
17.   { name: '运行中切词作废', ctx: { stage: 'RUNNING', libSize: 24, cursor: 9, speed: 1 },
18.     event: 'CHANGE_RULE', wantStage: 'READY', wantAction: 'invalidateResults' },
19.   { name: '完成态调速不动数据', ctx: { stage: 'DONE', libSize: 24, cursor: 24, speed: 1 },
20.     event: 'SPEED', wantStage: 'DONE', wantAction: 'changeTempo' },
21.   { name: '暂停只能从运行进入', ctx: { stage: 'PAUSED', libSize: 24, cursor: 5, speed: 1 },
22.     event: 'PAUSE', wantStage: 'PAUSED', wantAction: 'noop' }
23. ];
25. export function runTransitions(cases: Case[]): string[] {
26.   const fails: string[] = [];
27.   for (const c of cases) {
28.     const t = reduce(c.ctx, c.event);
29.     if (t.next !== c.wantStage || t.action !== c.wantAction) {
30.       fails.push(`${c.name}: got ${t.next}/${t.action}`);
31.     }
32.   }
33.   return fails;
34. }

复制代码

再补一条全路径回放：从 READY 起模拟 24 次 TICK_DONE，断言恰好在第 24 次进入 DONE，中途任何一次都不提前结束。

2. export function replayFullRun(libSize: number): Stage[] {
3.   let ctx: Ctx = { stage: 'READY', libSize: libSize, cursor: 0, speed: 1 };
4.   const trace: Stage[] = [ctx.stage];
5.   ctx = { ...ctx, stage: reduce(ctx, 'START').next };
6.   for (let i = 0; i < libSize; i++) {
7.     ctx = { ...ctx, stage: reduce(ctx, 'TICK_DONE').next };
8.     ctx.cursor++;
9.     trace.push(ctx.stage);
10.   }
11.   return trace; // 长度 = libSize + 2；末项必须是 DONE，倒数第二项仍是 RUNNING
12. }

复制代码

把这类断言接进 CI 的价值很直接：以后有人给 DONE 状态新加一个按钮（比如「导出分组」），如果忘了在 reduce 里登记事件，测试会立刻指出「出现了一个未定义的转移」，而不是等用户点出诡异画面。

八、一条完整操作路径的验收轨迹

把五张截图对应的事件序列写全，就是状态机的验收轨迹：

LOADED(24) → READY，首屏四槽就位、计数 0、按钮「启动分拣」；
START → RUNNING，分类一次、开 340ms 节拍；
TICK_DONE × 2 → RUNNING，工位 3/24，当前卡「花间翠鸟 → 暖」；
TICK_DONE × 21 → RUNNING，归类网格逐张增长；
TICK_DONE → DONE，24/24、退回 3、命中率 88%、按钮「重新分拣」；
CHANGE_RULE(01→简洁) → READY，作废：网格清空、选中清空、速度保留；
SPEED(1×→4×) → READY，仅改 tempo；
START → RUNNING，重分类、开 85ms 节拍；
TICK_DONE × 24 → DONE，24/24、退回 0、命中率 100%、01 槽 19 张。

这条轨迹里有两个纯实现文档不会写、但交互复盘必须写的细节。第一，第 4 步和第 5 步之间，用户很可能点开某张图看依据，此时 selectedId 非 -1，第 6 步的 invalidate 必须连同它一起清掉，否则详情面板会挂在已作废的结果上。第二，第 7 步顺序可交换，先调速再切词或反过来都行，因为 SPEED 与 CHANGE_RULE 一个只动偏好、一个只动作废，互不读写对方字段。能交换的操作，才允许用户按任意习惯来。

九、小结

这台分拣机在算法上做的是「多规则流式归类」，在交互上做的其实是另一件事：把一次不可见的计算，编排成一段可暂停、可加速、可推翻重来的操作路径。显式转移表让「切词作废」「重跑全量重置」这类不变量有了唯一归属；340ms 节拍是呈现层参数，与计算解耦，因此能随手拧到 4×，代价是判定标签的可读时间被压缩到 85ms；进度、ETA、暂停守卫、选中项作废这四条细节，决定用户是否会在某个瞬间看到自相矛盾的画面；首屏只显示一个槽，则提醒我们状态正确不等于信息可见。最后，纯函数的 reduce 让每条状态转移都变成一行可回归的断言，这对 ArkTS 页面逻辑同样适用。

FAQ

问：为什么专门写状态机，直接在 onClick 里判断不行吗？
答：小规模时行得通，但「切词作废」「重跑重置」「暂停不重复提交」这些规则会散落到多个回调里，新增一个入口就多一处遗漏。集中成转移表后，不变量只有一份，还能直接跑断言。

问：4× 速度下判定标签读不完，是不是设计失误？
答：是取舍。快放服务的是「看整体分布」，不是「逐张读依据」，两者由同一个节拍承担，必然顾此失彼。改进方向是把 4× 做成「跳到结果」，或单独提供「只看当前卡」的暂停定格。

问：运行中允许切词吗？
答：当前允许，代价是立即作废整轮。更稳妥的是加守卫：运行中切词先确认，或把新规则排队到 DONE 后生效。转移表里 CHANGE_RULE → READY 已为这两种改法留好了位置。

问：为什么重跑要保留速度？
答：速度是用户偏好，不是某轮结果。作废函数里只保留 tempo，其余全清，重跑时不会把 4× 悄悄拧回 1×。

问：状态机测试需要真机或模拟器吗？
答：不需要。reduce 是纯函数，输入 Ctx + Event、输出 Transition，在普通单元测试里跑完即可；只有节拍与动画这类时序逻辑才需要集成测试。

问：这套方法能用在别的应用上吗？
答：能。凡是「有开始/暂停/完成、有会作废结果的操作」的界面——上传、导出、批处理、分步表单——都可以套用同一张转移表与同一组回归断言。

热心网友6

看完很有共鸣，把分散的 onClick 收进 reduce 转移表这一段很清晰，尤其是 CHANGE_RULE 对应 invalidateResults、SPEED 只改节奏不作废旧结果这个区分，确实把“规则是查询的一部分”落成了不变量。实际落地时建议把 action 到具体副作用的映射集中在一处，不然转移表再清楚，漏接 invalidateResults 仍然会出脏数据。首屏只完整露出 01 号槽这一点也值得处理，哪怕加个横向可滑动的边缘暗示或四路总数提示，让用户第一眼知道是并行四槽。同槽重复词既然合法，界面最好给个轻量提示，比如重复词标记或该槽命中说明，避免用户误以为另一路失效。整体思路对做鸿蒙交互状态机很有参考价值。

热心网友6

这篇把交互状态机从分散回调里抽出来，用转移表和 action 映射副作用，思路很清楚。尤其是 CHANGE_RULE 显式标成 invalidateResults，把“规则变了旧分组就是脏数据”当成不变量，比依赖各个 onClick 记得 reset 可靠得多；SPEED 只 changeTempo 不作废结果也讲得通，调速不该触发重算。 有两个小建议：同槽重复词既然合法，UI 上最好给个轻提示，否则用户看到某一路一直不收图容易误判；另外 DONE 后切词直接回 READY，是否要保留上一轮统计做对照，可以在交互上再明确一下。整体很有启发，特别是首屏四路并行只完整露出一路这个细节，说明状态机之外可见性也要一起设计。

热心网友6

这篇把交互状态机从界面回调里拎出来讲得很清楚，尤其是 CHANGE_RULE 明确映射到 invalidateResults、SPEED 只改节奏不作废旧结果，这两个不变量分开很关键。转移表把分散的 onClick 收拢后，后续新增入口确实不容易漏掉作废逻辑。 另外首屏只完整露出 01 号槽这点也值得注意，四路并行如果第一眼传达不足，用户可能低估可调空间。还有同槽重复词合法但 argmax 总取先出现的那一路，虽然不算 bug，但最好在槽口计数或提示上让用户感知到，否则容易误判算法结果。整体思路很受用。