Xuedi's Blog

复杂互动业务中的有限状态机（FSM）设计艺术

Aug 25, 2025
Date
Aug 25, 2025
Slug
fsm-design-principle
Author
Status
Published
Summary
Type
Post
Thumbnail
Tags
💻 Engineer
updatedAt
Feb 2, 2026 03:31 AM
在现代移动应用开发中，我们经常遇到这样一类业务场景：流程简单但规则严谨，参与者众多，且生命周期较长。例如：多人在线游戏、复杂的直播互动、或者即时协作文档。
在这些场景的工程实现中，我们往往面临着状态繁多、异步事件密集、交互逻辑复杂的挑战 。随着业务的快速迭代，如果缺乏一种优雅且健壮的系统设计，代码很快就会沦为难以维护的“各种布尔值”和“If-Else”堆砌的泥潭 。
本文将探讨如何在复杂的客户端业务场景中，利用 有限状态机（Finite-State Machine, FSM）来驯服复杂性，构建可预测、易维护的系统。

一、 为什么我们需要状态机？

想象一个典型的互动场景：用户发起请求、等待对方接受、倒计时开始、进行中、结算、结束。整个过程持续数分钟，期间充斥着服务端的推送消息、用户的操作以及网络环境的波动 。
如果我们使用传统的 if-else 或分散的布尔变量（如 isConnecting, isPlaying, isFinished）来管理，很快就会遇到以下痛点：
  1. 状态混乱（State Mess-up）：系统状态散落在各个变量中。当“连接成功”和“用户取消”这两个异步事件几乎同时到达时，很难判断系统到底该处于什么状态，极易导致 UI 显示错误甚至流程死锁 。
  1. 复杂度爆炸（Complexity Inflation）：每增加一个新功能或新状态，都需要在无数个 if-else 分支中小心翼翼地修改，代码变得极其脆弱 。
引入有限状态机，就是为了给系统带来秩序。

二、 什么是有限状态机？

从概念上讲，有限状态机是一个数学模型。它描述了一个对象在生命周期内所经历的有限个状态（State），以及在响应外部 事件（Event）时，如何从一个状态流转到另一个状态 。
其核心公式可以抽象为：

状态流转图示例

通过 FSM 模型，我们将原本散落在各处的逻辑判断，抽象成了一个结构化、可视化的系统 。

三、 FSM 设计的核心收益

在复杂业务中引入 FSM 主要带来四大收益：
  1. 单一可信数据源（Single Source of Truth）：状态机是系统状态的唯一来源。UI 或其他模块不再猜测当前处于什么阶段，彻底消除了状态不一致的问题 。
  1. 严格的控制流（Strict Control Flow）：明确定义了合法的流转路径。比如在“进行中”状态，系统绝不会响应“发起邀请”的事件，保证了流程的健壮性 。
  1. 高扩展性（High Scalability）：新增业务状态时（如增加一个“准备阶段”），只需增加一个新的状态类并定义相关转换，无需侵入修改现有的复杂逻辑 。
  1. 强制业务规则：通过状态转换规则强制执行业务逻辑，例如“只有双方接受后才能开始”，从架构层面保证业务正确性 。

四、 核心设计原则与代码实践

设计一个优秀的 FSM 应该遵循以下原则：

1. 状态的原子性与互斥性

在任何时刻，系统必须处于且仅处于一个状态 。

2. 状态不可变性 (Immutability)

状态对象本身应该是只读的。发生流转时，不修改旧对象，而是创建新对象。这在多线程环境下尤其重要 。
代码示例:
kotlin

3. 外部事件驱动与内部逻辑封闭

外部调用者（如 UI 层）只负责发送事件（Event），不应直接修改状态。状态机内部决定是否流转以及流转到哪里 。
👎 Bad Practice: fsm.currentState = State.Active (直接修改)
👍 Good Practice: fsm.dispatch(Event.StartClicked) (发送意图)

五、 常见的“坑”与避坑指南

在落地 FSM 时，开发者容易陷入以下误区：

误区一：将“状态”与“数据”混为一谈

现象：状态对象中塞满了业务数据（如用户信息、实时分数、道具列表等），导致状态对象臃肿不堪 。 对策：状态机只管理核心控制状态（如 Invited, Active）。具体的业务数据应存放在独立的**数据模型（Data Model）**中。状态机是骨架，数据模型是血肉 。

误区二：UI 逻辑混入状态机

现象：在状态机内部直接写 showToast() 或 playAnimation() 。 对策：状态机应是纯逻辑核心。UI 层应该订阅状态机的变化。当状态变为 Active 时，UI 监听到变化后自行决定是播放动画还是显示倒计时 。

六、 架构模式：MVI 与单向数据流

为了更好地配合 FSM，建议采用单向数据流的架构（类似 MVI 模式）：
  • UI Components: 负责展示，将用户操作转化为意图（Intent）。
  • Coordinator/ViewModel: 桥梁层。将 UI 意图转化为 FSM 事件；订阅 FSM 状态并转化为 UI 可渲染的 ViewState 。
  • FSM Engine: 纯逻辑核心，接收事件，输出新状态 。
声明式 UI 的最佳拍档在 Flutter、SwiftUI 或 Jetpack Compose 中，这种模式尤为强大。UI 直接绑定 ViewModel，当 FSM 状态改变导致 ViewModel 更新时，界面自动刷新，无需写任何 updateTextView() 之类的指令式代码 。

七、 进阶：处理复杂场景

1. 分层状态机（Hierarchical FSM）

当业务处于“进行中”状态时，可能还存在“加速中”、“Buff 生效中”等子状态。如果在父状态中加标志位，逻辑会再次复杂化。
解决方案：引入分层状态机。Active 状态内部包含一个独立的子状态机，父状态只关心生命周期的开始和结束，子状态机管理内部的细微变化 。

2. 容错与恢复

状态机模型往往是单向的，但在真实网络环境中，请求可能超时。
解决方案：设计顶层的 Recovering 或 Failed 状态。发生可恢复异常时，进入 Recovering 尝试自动重连；不可恢复时进入 Failed 引导用户操作，避免流程卡死 。

结语

对于长流程、多交互的业务，有限状态机不是“杀鸡用牛刀”，而是治理混乱的良药 。通过严格区分状态与数据、分离 UI 与逻辑、采用单向数据流，我们可以构建出逻辑清晰、易于测试且具备高扩展性的业务系统。
下次当你发现自己在一个布尔变量的迷宫中挣扎时，不妨试着画一张状态流转图，也许答案就在其中。