事件驱动
事件的驱动机制是，让驴打磨，它不拉，用鞭子抽，它开始拉。 然后又停了下来，你再吸一次，它又继续了。 这叫做用“鞭子”带动“驴”往程序里折。 程序在那里停止。 单击按钮后，它会有反应。 过了一会儿，又没有反应了。 再按一下，它又会继续移动。 这就是在“活动”中运行“程序”
0 .基本概念
窗口/组件
活动
消息(队列)
事件响应(服务处理程序)
调度算法
进程/线程
无阻塞I/O
程序执行可以看作一次消耗CPU、存储器、IO资源
现代操作系统支持多任务，可以时分复用上述资源。
1 .为什么要采用事件驱动模式？
事件驱动模式是我们常说的观察者或公众-订阅模式。了解几个关键点：
首先是对象间的一对多关系； 最简单的就像信号灯一样，信号灯是目标(一方)，行人凝视着信号灯)。
当目标发送改变(发布)时，观察者(订阅者)可以接收改变
观察者如何处理(行人如何走、快走/慢走/不走、目标不管理)、目标不需要干涉，所以将它们的关系平缓地结合起来。
2 .代码执行流程
在传统或“过程式”APP应用程序中，APP应用程序本身控制着执行哪些部分代码以及以什么顺序执行代码。 从第一行代码中运行程序，根据APP应用程序中的预定路径运行，并根据需要调用进程。
在事件驱动APP表示中，代码不会按预期的路径执行，而是在响应不同的事件时执行不同的代码片段。 事件还可以通过用户交互、来自操作系统或其他APP应用程序调度算法的消息，以及APP应用程序本身的消息来发生。 每次执行APP应用程序时经过的代码路径都不一样，因为这些事件的顺序决定了代码执行的顺序。
3 .事件驱动模型
在UI编程中，经常与鼠标点击相对应，那么首先如何获得鼠标点击呢？
方法1 )如果创建一个总是循环检测是否有鼠标单击的线程，则此方法具有以下缺点：
虽然可能会浪费CPU资源，而且鼠标单击频率非常低，但是扫描线程总是在循环中被检测到，这会浪费很多CPU资源。 如果扫描和单击鼠标的界面被阻止了呢？
如果堵塞，则会出现以下问题。 除了鼠标单击外，还将扫描键盘是否被按下。 扫描鼠标时被卡住了，所以可能不会扫描键盘。
如果一个周期需要扫描的设备非常多，则会出现响应时间问题。 所以，这种方式非常不好。
方式2 )事件驱动模型目前大多数UI编程都是事件驱动模型，它表示鼠标按下事件，就像许多UI平台提供onClick )事件一样。 事件驱动模型的大致思路如下。
有事件(消息)队列
按下鼠标时，将单击事件(消息)添加到此队列；
存在一个循环，用于继续从队列中检索事件，并为每个事件调用不同的函数，如onClick ()、onKeyDown ()
一般情况下，事件(消息)分别保持各自独立的处理函数指针。 这样，每个消息都有独立的处理函数； 图：
Paste_Image.png
4 .事件驱动处理库
选择
保罗
电子邮件
libev
消息驱动
消息驱动与事件驱动非常相似。 首先是事件，然后生成相应的消息，将消息排队并从所需的项目中检索。 他们的区别在于新闻是谁产生的
消息驱动：鼠标管自己点击，不需要与系统交互。 消息由系统(第三方)循环检测并捕获到消息队列中。 新闻对于点击事件来说是被动产生的，高凝聚。
事件驱动：发生鼠标单击事件后，向系统发送“已单击”消息。 消息是自发产生的。 发送到消息队列。
事件：当您按下鼠标、按下键盘、按下游戏手柄或将u盘插入u盘接口时，将发生事件。 例如，按下鼠标左键会发生按下鼠标左键的事件。
消息：如果发生鼠标按下、鼠标按下的事件，windows将检测到该事件的发生，并向消息队列发送鼠标按下的消息。 此消息附加了一系列事件信息，包括鼠标按下了哪个按钮、在哪个窗口按下了鼠标，以及按下的点的坐标是多少。 是吗？
1 .要理解事件驱动程序和程序，需要将其与非事件驱动程序进行比较。 实际上，大多数现代程序肯定是事件驱动的，例如多线程程序是事件驱动的。 早期存在很多非事件驱动的程序。 当需要等待触发某个条件时，此类程序会继续检查该条件，直到满足该条件。 这是浪费cpu时间。 事件驱动的程序有机会释放cpu并进入休眠状态。 (请注意有机会。 当然，程序也可以自己决定不释放cpu。 )事件发生时让操作系统唤醒，可以更有效地使用cpu.2。 什么是事件驱动的程序？ 典型的事件驱动程序是一个死循环，作为线程存在。 该死循环由两部分组成，第一部分是接收并选择要根据特定条件处理的事件，第二部分是事件的处理过程。 的执行过程是选择和处理事件。 如果没有发生事件，程序将无法联系事件队列并进入休眠状态，从而释放cpu。 3 .事件驱动程序必须直接
或者间接拥有一个事件队列，用于存储未能及时处理的事件。4.事件驱动的程序的行为，完全受外部输入的事件控制，所以，事件驱动的系统中，存在大量这种程序，并以事件作为主要的通信方式。5.事件驱动的程序，还有一个最大的好处，就是可以按照一定的顺序处理队列中的事件，而这个顺序则是由事件的触发顺序决定的，这一特性往往被用于保证某些过程的原子化。6.目前windows,linux,nucleus,vxworks都是事件驱动的，只有一些单片机可能是非事件驱动的。事件模式耦合高，同模块内好用；消息模式耦合低，跨模块好用。事件模式集成其它语言比较繁琐，消息模式集成其他语言比较轻松。事件是侵入式设计，霸占你的主循环；消息是非侵入式设计，将主循环该怎样设计的自由留给用户。如果你在设计一个东西举棋不定，那么你可以参考win32的GetMessage，本身就是一个藕合度极低的接口，又足够自由，接口任何语言都很方便，具体应用场景再在其基础上封装成事件并不是难事，接口耦合较低，即便哪天事件框架调整，修改外层即可，不会伤经动骨。而如果直接实现成事件，那就完全反过来了。
最近在学习《Unix编程艺术》。以前粗略的翻过，以为是介绍unix工具的。现在认真的看了下，原来是介绍设计原则的。它的核心就是第一章介绍的unix的哲学以及17个设计原则，而后面的内容就是围绕它来展开的。以前说过，要学习适合自己的资料，而判断是否适合的一个方法就是看你是否能够读得下去。我对这本书有一种相见恨晚的感觉。推荐有4~6年工作经验的朋友可以读一下。
正题：
作者在介绍Unix设计原则时，其中有一条为“表示原则：把知识叠入数据以求逻辑质朴而健壮”。结合之前自己的一些经验，我对这个原则很有共鸣，所以先学习了数据驱动编程相关的内容，这里和大家分享出来和大家一起讨论。
数据驱动编程的核心
数据驱动编程的核心出发点是相对于程序逻辑，人类更擅长于处理数据。数据比程序逻辑更容易驾驭，所以我们应该尽可能的将设计的复杂度从程序代码转移至数据。
真的是这样吗？让我们来看一个示例。
假设有一个程序，需要处理其他程序发送的消息，消息类型是字符串，每个消息都需要一个函数进行处理。第一印象，我们可能会这样处理： void msg_proc(const char *msg_type, const char *msg_buf) { if (0 == strcmp(msg_type, "inivite")) { inivite_fun(msg_buf); } else if (0 == strcmp(msg_type, "tring_100")) { tring_fun(msg_buf); } else if (0 == strcmp(msg_type, "ring_180")) { ring_180_fun(msg_buf); } else if (0 == strcmp(msg_type, "ring_181")) { ring_181_fun(msg_buf); } else if (0 == strcmp(msg_type, "ring_182")) { ring_182_fun(msg_buf); } else if (0 == strcmp(msg_type, "ring_183")) { ring_183_fun(msg_buf); } else if (0 == strcmp(msg_type, "ok_200")) { ok_200_fun(msg_buf); }
。。。。。。 else if (0 == strcmp(msg_type, "fail_486")) { fail_486_fun(msg_buf); } else { log("未识别的消息类型%sn", msg_type); } } 上面的消息类型取自sip协议(不完全相同，sip协议借鉴了http协议)，消息类型可能还会增加。看着常常的流程可能有点累，检测一下中间某个消息有没有处理也比较费劲，而且，没增加一个消息，就要增加一个流程分支。
按照数据驱动编程的思路，可能会这样设计： typedef void (*SIP_MSG_FUN)(const char *);
typedef struct __msg_fun_st { const char *msg_type;//消息类型 SIP_MSG_FUN fun_ptr;//函数指针 }msg_fun_st;
msg_fun_st msg_flow[] = { {"inivite", inivite_fun}, {"tring_100", tring_fun}, {"ring_180", ring_180_fun}, {"ring_181", ring_181_fun}, {"ring_182", ring_182_fun}, {"ring_183", ring_183_fun}, {"ok_200", ok_200_fun},
。。。。。。 {"fail_486", fail_486_fun} };
void msg_proc(const char *msg_type, const char *msg_buf) { int type_num = sizeof(msg_flow) / sizeof(msg_fun_st); int i = 0;
for (i = 0; i < type_num; i++) { if (0 == strcmp(msg_flow[i].msg_type, msg_type)) { msg_flow[i].fun_ptr(msg_buf); return ; } } log("未识别的消息类型%sn", msg_type); }
下面这种思路的优势：
1、可读性更强，消息处理流程一目了然。
2、更容易修改，要增加新的消息，只要修改数据即可，不需要修改流程。
3、重用，第一种方案的很多的else if其实只是消息类型和处理函数不同，但是逻辑是一样的。下面的这种方案就是将这种相同的逻辑提取出来，而把容易发生变化的部分提到外面。
隐含在背后的思想：
很多设计思路背后的原理其实都是相通的，隐含在数据驱动编程背后的实现思想包括：
1、控制复杂度。通过把程序逻辑的复杂度转移到人类更容易处理的数据中来，从而达到控制复杂度的目标。
2、隔离变化。像上面的例子，每个消息处理的逻辑是不变的，但是消息可能是变化的，那就把容易变化的消息和不容易变化的逻辑分离。
3、机制和策略的分离。和第二点很像，本书中很多地方提到了机制和策略。上例中，我的理解，机制就是消息的处理逻辑，策略就是不同的消息处理(后面想专门写一篇文章介绍下机制和策略)。
数据驱动编程可以用来做什么：
如上例所示，它可以应用在函数级的设计中。
同时，它也可以应用在程序级的设计中，典型的比如用表驱动法实现一个状态机(后面写篇文章专门介绍)。
也可以用在系统级的设计中，比如DSL(这方面我经验有些欠缺，目前不是非常确定)。
它不是什么：
1、 它不是一个全新的编程模型：它只是一种设计思路，而且历史悠久，在unix/linux社区应用很多；
2、它不同于面向对象设计中的数据：“数据驱动编程中，数据不但表示了某个对象的状态，实际上还定义了程序的流程；OO看重的是封装，而数据驱动编程看重的是编写尽可能少的代码。”
书中的值得思考的话：
数据压倒一切。如果选择了正确的数据结构并把一切组织的井井有条，正确的算法就不言自明。编程的核心是数据结构，而不是算法。——Rob Pike
程序员束手无策。。。。。只有跳脱代码，直起腰，仔细思考数据才是最好的行动。表达式编程的精髓。——Fred Brooks
数据比程序逻辑更易驾驭。尽可能把设计的复杂度从代码转移至数据是个好实践。——《unix编程艺术》作者。
喜欢 (5)or分享 (0)