（文章开头先放工程地址：http://mp.weixin.qq.com/s/jkJh3mEUQx8E2Y2SY1WmTw）
游戏开发过程中经常需要控制游戏从一个状态切换到另外一个状态，比如：UI界面的切换（从背包系统切换到商城系统，从商城系统切换到任务系统，从奖励系统切换到聊天系统等等），每个系统之间是相互独立、但是有一些关联（当从商城系统切换到任务系统时，往往会发生这样有趣的对话：嗨，任务，我要谢幕了，接下来该你上场了，说完，商城系统收拾一下自己的道具，黯然离场。任务系统接收到来自商城系统的消息，准备好自己的道具、服装，闪亮登场，一场表演bulinbulin的开始。OK，任务系统要退出了，下一个上场的该是战斗系统了；任务系统通知战斗系统：老兄，该你战斗了，come
on ,说罢，任务系统退出。战斗系统提起早已饥渴难耐的大刀pipipapa，30秒到达了战场，紧接着，Game Over,计分系统老哥出场了，就这样，兄弟几个交替着上场、退出）。切回正题，其实上述描述的场景就是一个使用有限状态机控制的场景。在这样一个场景中，当前需要退出的状态不知道即将要进入的是哪一个状态，而即将要进入的状态也不关心上一个退出的场景是哪一个，两者需要关心的仅仅是：我什么时候该上场，上场之后需要做什么和我什么时候该下场，下场之后需要做什么。那么，既然，两者之间没有任何的联系，又是怎样做到上场和下场的消息通知呢。没错，这就导演的职责了，当一个状态要退出舞台时，通知导演：唉，导演，我的表演
It's Over了，我要卷铺盖走人了，说完，收拾自己的行李，*。导演接收到信息，通知下一个状态：准备一下，小火鸡，该你上场了，下一个状态接收到来自导演的语音：好的，秃鹫收到，即将闪亮登场：Music在哪里，动次打次动次打次.............；从整个过程来分析，状态与状态之间完全是相互独立的、互不影响，我登台了，我干我该干的事，我*了，我只收拾我的东西。至于，下一个上台的人，我只需要通知导演我*了，至于谁上台，关我什么事。这样设计有一个很大的好处，各状态之间相互独立，不互相影响，避免了状态与状态之间的耦合，我们都知道，在计算机程序设计中追求的是高内聚、低耦合，面向对象开发中，我们需要尽量减少类与类之间的耦合度，这样才能增强软件的健壮性，避免产生更多的Bug。好了，犊子扯了这么多，来仔细谈一下什么是有限状态机吧。
有限状态机：又称为有限状态自动机，简称状态机，是表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型。(摘自百度百科)。一般有限状态机有以下几种类型的动作：
1.进入动作（进入当前状态时执行）
2.退出动作（退出当前状态时执行）
3.输入动作（接收到来自管理器消息时执行）
4.转移动作（在进行特定转移时执行）
看张图舒缓舒缓（画的很Low,凑合看吧）
从图中可以看出，状态与状态之间没有任何的关联，极大的降低了程序的耦合度，各个状态之间的消息传递，均通过管理器来完成，这样，状态只需要关心和管理在当前状态下会发生的事，而不需要额外的去获取其它状态的动作和事件，这就是有限状态机的一大好处。下图是一个在Unity Animator
动画管理器中的一个有限状态机示例，实际比下图要复杂的多，在一组动画中，有多个动画状态，各个状态之间是没有关联的，状态与状态之间的切换，包括触发的条件，都是由动画控制器（Animator Controller）来管理的，当然，在Unity的Animator Controller中提供了四种类型的参数可供使用，分别是（bool trigger int float）。
说了这么多，没有写代码来的实在，下面，我就逐步的分析和实现一个基于UI管理器的简单有限状态机，用来控制各个UI状态间的切换。从上述的过程分析可知，每一个状态都有进入、退出等动作，在具体的进入和退出过程中，会执行一些当前状态下需要触发的事件。因此，创建一个基类是非常有必要的，让每个状态类继承它。基类代码如下所示：
我们创建各个系统的实例继承自基类：
一.商店系统
二：任务系统
三：计分系统
接下来就是比较重要的状态切换管理器了管理器了，管理器控制着各个状态间的切换（谁该上台，谁该收拾东西走人）
看一张大概图，文章提供github地址，需要工程文件的请跳转连接。本文大部分只是参考自Unity官方商业案例：Trash Dash,其UI状态的切换使用的就是FSM状态机，需要的可以下载Sample研究一下，其中也涉及一些数据存储，对象池等常用游戏开发技术，很有研究学习的价值，地址：https://www.assetstore.unity3d.com/en/#!/content/87901;
OK,本次有限状态机（FSM)分享就到这了。
再补一张工程文件截图：
