队列消息驱动的状态机与事件驱动的状态机的对比

https://lv.qizhen.xyz/pattern_ui

一般来说一个程序的主程序，就是他的主界面。编写这样的程序是有固定套路的，也就是它的设计模式。

在主程序中，少不了对用户界面操作的处理，因此事件结构时必须的。同时，它也会处理一些非界面上的任务，因此程序也必须还有一个选择结构以应对其它工作。这样一来，就有两种程序结构可供选择了：1.选择结构在外，事件结构在内；2.事件结构在外，选择结构在内。

	队列消息驱动	事件驱动
示意图
工作原理	这是一个典型的状态机结构。使用队列记录消息，控制状态的跳转。 选择结构根据每次发来消息的不同，选择一个分支进行处理。这里有一个特殊的状态“No Action”，在没有其它消息的时候，选择结构进入此分支。这个分支内嵌一个事件结构，用于接收用户的界面操作。	使用事件（包括LabVIEW自带的和用户自定义的事件）来控制程序的运行，在不同分之间跳转。 事件结构有一个特殊分支“用户事件”，用于处理所有的非界面事件。其内部嵌套一个选择结构，以处理不同的事件。 实际上如果为程序的每一个处理分支都定义一个用户事件，那么这个程序中可以不需要选择结构。但定义太多的用户事件，比较麻烦，不如像这样定义一个统一的用户事件，然后在其事件处理分支中再根据事件传来的数据区分其具体是何事件。
发展历史	早些年，状态机结构是相当盛行的。这样的程序结构应该是在状态机基础上一步步改进演化来的。类似的程序结构相当多，截图中这个版本取自NI官方的LabVIEW社区，大概是NI一些系统工程师开发出来的。	我自己在编程过程中不断改进演化而来。状态机盛行那会，我没怎么编写过界面程序。而我开始编写界面程序时，LabVIEW已经具有了事件结构。因此，我开始按照自己认为最简洁的方式来设计界面程序。
封装性	这个架构比较复杂的，架构中包含多个子VI，用户管理消息队列（队列的创建、销毁、消息的入队、出队等）。网络上可以找到一些已经编写好的子VI和模板，但是用起来还是稍显复杂。	LabVIEW自带的事件处理函数已经比较简单了，可以不对其做封装就直接使用。但是我为了让程序更简洁，还是对其作了进一步的封装，把主要功能放在几个子VI中。LabVIEW中某些对话框就是采用此架构编写的，因此，这几个子VI是随LabVIEW一起发布的。无需下载就可以直接使用。
代码可读性、可维护性、扩展性	连线和子VI较多一些，程序复杂度高，是的其几项指标都较差。 此外，界面程序最主要的工作还是对界面事件的相应，其它任务居次要地位。而这个架构中把主要对象放在次要对象中的某一分支内，主次颠倒，看起来比较别扭。	连线和子VI较少，程序复杂度低，因此这几项更好。
调整未被处理的任务	由于程序中用于控制程序流程的消息是用户自己管理的，所以比较灵活。用户可以在任何时候对还没有处理到的消息进行调整，比如删除某些消息、改变其顺序等。 但实际上，这种应用比较罕见。	对事件的管理是在LabVIEW内部进行的。用户不能对其做调整。
其它VI对程序流程的控制	在其它VI中，也可插入新的消息到队列中来，从而控制这个VI的运行。 队列有个优点，就是可以通过队列的名字来得到一个队列，而不需要一定把队列的数据线连出去。这个优势可以使得程序编写稍许简化。	在其它VI中，也可抛出一个事件，来控制这个VI的运行。 事件比队列中的消息有个额外的优势，事件被抛出后，任何VI都可以接收到，这样其它VI不但可以控制当前这个VI的运行，也可以监视当前这个VI有哪些事件发出了。 事件比队列的缺陷在于它不能通过名字来获取，一定要连一根数据线。
使用事件结构定时	这个模式中的事件结构的延时设置有特殊用途，必须设定一个100～300ms的超时事件，超时事件发生后，程序继续向下执行。没有这个超时事件，程序可能会被阻塞在事件结构这里，而失去了对其它状态跳转的响应。 所以这里不能再把超时事件用来做定时用。	任何用户自定义事件都会触发事件结构，因此它不存在阻塞的问题。 程序中如有定时需求（比如每1秒采集一个数据），可以把超时事件做定时器用。
状态跳转时的滞后	程序每次运行至事件结构时，都需要等待100～300ms，超时事件产生后才能继续运行下去，如果这是，有新的消息加入到队列中，程序是不会立刻响应的。	没有响应滞后的问题。
适用场合	各种场合皆可，尤其是需要灵活改变消息的顺序时。	各种场合皆可。

广告