我们所说的状态机实际上是指 FSM（Finite State Machine，有限状态机），它表示有限个状态以及在这些状态下执行动作和状态转移等行为的模型。FSM 可分为两种类型：

举例说明 FSM 及其两种类型的区别。游戏中士兵的行为状态有 巡逻 、 追击敌人 、 攻击敌人 、 逃跑 等；响应的事件有 发现敌人 、 追到敌人 、 敌人逃跑 、 敌人死亡 、自己 血量不足 等。这些状态的转移及对事件的响应如下表所示。

从表格中可以看出，FSM 分类依据中的 输出 不是指某个状态的输出，而是 状态机系统对外的输出 。状态机本身状态的转移与状态机当前状态和当前输入都是相关的。

实际上，系统中常使用混合状态机，即状态机既包含了 Moore 状态机也包含了 Mealy 状态机。仅部分单一功能的设计采用单纯的状态机类型（如：检测 1001 字符串）。其中由于 Moore 状态机中状态的增加与事件处理的修改对其输出影响不大，所以它具备安全可扩展的特点，因此混合状态机需要尽可能地 Moore 化。

用代码实现的思路描述 FSM 则是：不同的状态下都有一个 handleEvent 的方法供调用处理输入的不同的 Event，运行时 State 将根据事件输入进行转换，由于所处状态的不同，导致了即使向系统输入同一事件，它表现出来的行为都不一样。这也正是状态模式（State Pattern）的含义。

如何改进呢？我们可以站在巨人的肩膀上进行思考，回想一下所知道的 GUI 系统是怎么处理用户输入事件的。例如 Android 系统，它处理触摸事件使用的是事件分发机制，将事件分发到子控件处理，如果子控件未处理则事件流回到父控件，重复此流程直至最高处理级别。整个处理逻辑体现了一种分层的结构设计，事件始终被尝试处理着，该设计模式是典型的责任链模式（Interator Pattern）

将这种事件处理的分层结构引入 FSM 则产生了 HFSM（Hierarchical Finite State Machines，分层状态机）。典型结构如下图所示。

HFSM 最重要的设计为父子状态的引入。新定义状态可 继承 父状态的行为逻辑，因此只需要定义与现有状态的差异来快速引入新的状态，并且可以 复写 对事件的处理来 覆盖或扩展 父状态的事件处理。

HFSM 另一重要设计是状态的进入（Enter）与退出（Exit）操作。Enter 与 Exit 操作与状态相关，而与其转移条件无关，该设计即 Moore 状态机的表现。通常 Enter 与 Exit 用于状态资源的初始化与释放，其执行顺序为 从父状态往下进行初始化，退出则以相反顺序执行 ，这个设计可与 面向对象编程中的构造和销毁 对比。该设计的典型应用为状态间对系统稀有资源的复用，仅需要通过这两个方法进行使用与释放。

这是 HFSM 中每个状态的典型接口：

这个是 ISate 的默认实现：

一般情况下，StateMachine 中的状态选择继承 State 而不用直接实现接口。其实我觉得 State 类设计成抽象类更合适。

1
2
3
4

private void initStateMachine(String name, Looper looper) {
    mName = name;
    mSmHandler = new SmHandler(looper, this);
}

可以看出，状态机内部有一个 Handler 来处理消息，这个 Handler 可以在创建时传入，也可以内部自动创建子线程来构建。因此，我们可以知道，状态机消息处理时是处在 Handler 所在的线程中，这一点在主动传入外部 Handler 时要特别注意，不要因为外部的消息处理阻塞了状态机的消息处理。

更进一步，我们看以下这些状态机的公共方法的处理，可以发现，所有真正的执行动作都是在其内部的 Handler 中，与调用方法的上下文无关。因此，如果清楚 StateMachine 处理消息的线程，就不用担心它的处理会阻塞调用线程。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

public class StateMachine {
    // 初始化
    public final void addState(State state) {}
    public final void addState(State state, State parent) {}
    public final void setInitialState(State initialState) {}
    public void start() {}

    // 发送消息
    public final Message obtainMessage() {} // 一系列同名方法
    public void sendMessage(Message msg) {} // 一系列同名方法
    public void sendMessageDelayed(Message msg, long delayMillis) {} // 一系列同名方法
    public final void deferMessage(Message msg) {}
    protected final void sendMessageAtFrontOfQueue(Message msg) {} // 一系列同名方法

    // 状态操作
    public final void transitionTo(IState destState) {}
    public final void removeState(State state) {}
    public final void transitionToHaltingState() {}

    // 退出
    public final void quit() {}
    public final void quitNow() {}

    // 其他
    public final Handler getHandler() {}
    public final IState getCurrentState() {}
    public final Message getCurrentMessage() {}
}

我们先把 public 方法进行分类，分别说明。

注意：不要在调用 start 之前给状态机发送消息，否则会导致崩溃。

1
2
3
4
5
6

protected void onPreHandleMessage(Message msg) {}
protected void onPostHandleMessage(Message msg) {}
protected void unhandledMessage(Message msg) {}
protected void haltedProcessMessage(Message msg) {}
protected void onHalting() {}
protected void onQuitting() {}

对正常消息来说，在处理前后会分别调用 onPreHandleMessage 和 onPostHandleMessage 方法，重写 onPreHandleMessage 方法时切记 不要修改 Message 对象 ，否则出问题很难定位。

如果子状态及其所有父状态都未处理消息，则将调用 unhandledMessage 为状态机提供最后一次处理消息的机会。

上文说到状态机提供了两个特殊的状态，分别是 Halting 和 Quitting。在进入 Quitting 状态后，会调用 onQuitting 方法，这一般用来通知状态机本身进行资源的释放。同样地，在进入 Halting 状态后，会调用 onHalting 方法使得状态机了解该事件，可以释放暂时不需要的资源，并且后续的消息都由 haltedProcessMessage 进行处理，子类可重写该方法以便根据特定消息从 Halting 状态转移恢复到正常状态。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// 日志调试
public void setDbg(boolean dbg) {}
public boolean isDbg() {}
protected void log(String s) {} // 一系列 log 方法

protected String getWhatToString(int what) {}
public final void setLogOnlyTransitions(boolean enable) {}
protected boolean recordLogRec(Message msg) {}

public final String getName() {}
public final int getLogRecSize() {}
public final void setLogRecSize(int maxSize) {}
public final int getLogRecMaxSize() {}
public final int getLogRecCount() {}
public final LogRec getLogRec(int index) {}
public final Collection<LogRec> copyLogRecs() {}
public void addLogRec(String string) {}
public void dump(FileDescriptor fd, PrintWriter pw, String[] args) {}
protected String getLogRecString(Message msg) {}

在开发调试时，最好打开 Debug 开关， setDbg 为 true 之后，处理消息和状态转移时会在日志中打印相关信息。状态机内部可以直接调用 log 系列方法打印出相同 TAG 的日志，与其内部保持一致。实践中，记得在 log 调用前加上 isDbg 判断，从而在上线版本中 setDbg 为 false 关闭日志输出。

log 打印的日志信息比较简单，如果要查看消息更多的信息，可以调用 StateMachine 的 toString 方法，实际上它也是调用了 dump 方法对这些所谓的 LogRec 进行输出。LogRec 的记录默认记录 20 条所有消息，这个可以通过查看 LogRecMaxSize 为 20 以及 recordLogRec 方法默认对所有消息返回 true 知道。如果只记录状态转移的消息可以 setLogOnlyTransitions(true) 。但这些信息打印消息时只打印 what，不够直观，我们可以重写 getWhatToString(int what) 方法，把 what 转成容易理解的字符串。

参考资料：