事件驱动编程
2023-08-13 22:02:18 
阿炯
事件驱动程序设计（英语：Event-driven programming）是一种计算机程序设计模型。该模型的程序执行流程是由使用者的动作（如滑鼠的按键，键盘的按键动作）或者是由其他程序的讯息来决定的。相对于批处理程序设计（batch programming）而言，程序执行的流程是由设计师来决定。批处理（batch）的程序设计在初级程序设计教学课程上是一种方式。然而，事件驱动程序设计这种设计模型是在互动程序（Interactive program）的情况下孕育而生的。
事件驱动程序可以由任何程序语言来实作，然而使用某些语言来撰写会比其他的语言来的简单。有些整合开发环境（简称IDE）也会影响实作事件驱动程序设计的难易程度。有的 IDE 会使的开发工作变的很简单，有的则不一定甚至反之。
在GUI编程中事件是非常常见的。比如用户在界面点击了按钮，就会发送一个“点击”事件，而相应的会有一个处理“点击”事件的事件处理器会来处理该事件。因此所谓事件驱动，简单地说就是你点什么按钮（即产生什么事件），电脑执行什么操作（即调用什么函数）。当然事件也不仅限于用户的操作。事件驱动的核心自然是事件。从事件角度说，事件驱动程序的基本结构是由一个事件收集器、一个事件发送器和一个事件处理器组成。事件收集器专门负责收集所有事件，包括来自用户的（如鼠标、键盘事件等）、来自硬件的（如时钟事件等）和来自软件的（如操作系统、应用程序本身等）。事件发送器负责将收集器收集到的事件分发到目标对象中。事件处理器做具体的事件响应工作，它往往要到实现阶段才完全确定。对于框架的使用者来说，他们唯一能够看到的是事件处理器。这也是他们所关心的内容。
对一个事件驱动（event driven）系统进行程序设计，因此可以视为改写系统预设触发函式的行为，来符合自己需要的一种动作。输入的事件可以放进事件回圈或者是经由已经注册的中断处理器来与硬体事件互动；而许多的软体系统使用了混和这两种技术的处理。预先设计好的演算法确定了一件事，那就是当他们被需要的时候，就会在适当的时机被触发。也因此提供了一个模拟中断驱动环境（interrupt driven environment）的软体抽象架构。事件驱动程序设计基本上包含了许多小程序片段，这些小程序片段被称为事件处理器并且被用来回应外部的事件与分发事件。通常尚未被事件处理器处理的事件，都会被系统放在一个称为事件队列的资料结构中，等待被处理。
事件驱动编程通常只是用一个执行过程，CPU之间不是并发的，在处理多任务的时候，事件驱动编程是使用协作式处理任务，而不是多线程的抢占式。事件驱动简洁易用，只需要注册感兴趣的事件，在回调中设计逻辑就可以了。在调用的过程中，事件循环器（Event Loop）在等待事件的发生，跟着调用处理器。事件处理器不是抢占式的，处理器一般只有很短的生命周期。
优势
在大部分的应用场景中，事件编程优与多线程编程。
相对与多线程编程来讲，事件驱动编程比较容易，复杂度低，是开发者乐于接受的。
大多数的GUI框架，都是使用事件驱动编程了架构的。每一个事件会绑定一个处理器，这些事件通常是点击按钮，选择菜单，等等。处理器r来实现具体的行为逻辑。
事件驱动经常使用在I/O框架中，可以很好的实现I/O复用。很多高性能的I/O框架都是使用事件驱动模型的，例如：Netty、Mina、Node.js。
易于调试。时间依赖只和事件有关系，而不是内部调度。问题容易暴露。
劣势
如果处理器占用时间较长，那会阻塞应用程序的响应。
无法通过时间来维护本地状态，因为处理器必须返回。
通常在单CPU环境下，比多线程编程要快，因为没有锁的因素，没有线程切换的损耗。CPU不是并发的，这样的话就不适合用在一些科学计算的应用中。
基本架构
主要由三部分构成:
1.事件收集器
2.事件发送循环器(EventLoop)
3.事件处理器
收集器专门负责收集所有事件，如gui例子中的键鼠事件、来自硬件的、网络的、操作系统的等等；发送器负责将收集器收集到的事件发送到目标对象中；处理器做具体的事件响应 -- 非抢占式执行，且一般拥有很短的生命周期。
事件循环器（Event Loop）的实现
Event Loop是一个程序结构，用于等待和发送消息和事件。事件驱动编程的代码核心就是事件循环器，在Linux下推荐使用epoll实现，在其它没有epoll 的系统上可以使用kqueue/ports/poll/select实现。
下图是事件循环器的工作示例图。事件循环器不断接受来自客户端（Client）的请求，事件循环器把请求转交给注册了某类事件的工作线程（Worker）处理。
事件驱动的优点是做了解耦, 并发编程简单, 易于调试。缺点是容易陷入事件森林不可拔, 如果处理器占用cpu时间过长, 容易阻塞app, 且用在单cpu环境下破环力更大。
在处理多任务的时候，事件驱动编程使用协作式处理任务，而不是传统的多线程抢占；这更简单易用，只需要注册感兴趣的事件，在回调中设计动作就可以了，在执行过程中eventloop不断消费事件，然后对应着调用处理器。
EventLoop是一个程序结构，用于等待和发送消息和事件，是事件驱动编程的代码核心。比较著名的有linux下的epoll，bsd下的kqueue实现。
EventLoop不断的运行、不断的接受来自client的请求，然后把请求转交给注册了某类事件的worker线程处理。依据实现的方式不同，主要有两种设计模式：reactor以及proactor。
Reactor
首先来回想一下普通函数调用的机制：
程序调用某函数->函数执行
程序等待->函数将结果
控制权返回给程序->程序继续处理
和普通函数调用的不同之处在于：应用程序不是主动的调用某个API完成处理，而是恰恰相反，应用程序需要提供相应的接口并注册到Reactor上，如果相应的事件发生，Reactor将主动调用应用程序注册的接口，这些接口又称为“回调函数”。
用“好莱坞原则”来形容Reactor再合适不过了：不要打电话给我们，我们会打电话通知你。
举个例子：你去应聘某xx公司，面试结束后。
“普通函数调用机制”公司HR比较懒，不会记你的联系方式，那怎么办呢，你只能面试完后自己打电话去问结果；有没有被录取啊，还是被拒了；
“Reactor”公司HR就记下了你的联系方式，结果出来后会主动打电话通知你：有没有被录取啊，还是被拒了；你不用自己打电话去问结果，事实上也不能，因为你没有HR的联系方式。
Reactor模式的优点
编写高性能网络服务器的必备技术之一，它具有如下的优点：
1）响应快，不必为单个同步时间所阻塞，虽然Reactor本身依然是同步的；
2）编程相对简单，可以最大程度的避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销；
3）可扩展性，可以方便的通过增加Reactor实例个数来充分利用CPU资源；
4）可复用性，Reactor框架本身与具体事件处理逻辑无关，具有很高的复用性。
Reactor模式框架
使用Reactor模型，必备的几个组件：事件源、Reactor框架、事件多路复用机制和事件处理程序，先来看看Reactor模型的整体框架，接下来再对每个组件做逐一说明。
1）事件源：Linux上是文件描述符，Windows上就是Socket或者Handle了，这里统一称为“句柄集”；程序在指定的句柄上注册关心的事件，比如I/O事件。
2）事件多路复用机制：由操作系统提供的I/O多路复用机制，比如select和epoll。程序首先将其关心的句柄（事件源）及其事件注册到多路复用机制上。当有事件到达时，事件多路复用机制会发出通知“在已经注册的句柄集中，一个或多个句柄的事件已经就绪”。程序收到通知后，就可以在非阻塞的情况下对事件进行处理了。
3） Reactor。是事件管理的接口，内部使用事件多路复用机制注册、注销事件；并运行事件循环，当有事件进入“就绪”状态时，调用注册事件的回调函数处理事件。
4）事件处理程序。事件处理程序提供了一组接口，每个接口对应了一种类型的事件，供Reactor在相应的事件发生时调用，执行相应的事件处理。通常它会绑定一个有效的句柄。
使用Reactor模式后，事件控制流是什么样子呢？可以参见下面的序列图。
分别以读操作和写操作为例来看看Reactor中的具体步骤：
1) 应用程序注册读就绪事件和相关联的事件处理器；
2) 事件分离器等待事件的发生；
3) 当发生读就绪事件的时候，事件分离器调用第一步注册的事件处理器；
4) 事件处理器首先执行实际的读取操作，然后根据读取到的内容进行进一步的处理。
写入操作类似于读取操作，只不过第一步注册的是写就绪事件。
Proactor
来看看Proactor模式中读取操作和写入操作的过程：
1) 应用程序初始化一个异步读取操作，然后注册相应的事件处理器，此时事件处理器不关注读取就绪事件，而是关注读取完成事件，这是区别于Reactor的关键。
2) 事件分离器等待读取操作完成事件。
3) 在事件分离器等待读取操作完成的时候，操作系统调用内核线程完成读取操作（异步I/O都是操作系统负责将数据读写到应用传递进来的缓冲区供应用程序操作），并将读取的内容放入用户传递过来的缓存区中。这也是区别于Reactor的一点。
4) 事件分离器捕获到读取完成事件后，激活应用程序注册的事件处理器，事件处理器直接从缓存区读取数据，而不需要进行实际的读取操作。
Proactor中写入操作和读取操作，只不过感兴趣的事件是写入完成事件。
从上面可以看出，Reactor和Proactor模式的主要区别就是真正的读取和写入操作是有谁来完成的，Reactor中需要应用程序自己读取或者写入数据，而Proactor模式中，应用程序不需要进行实际的读写过程，它只需要从缓存区读取或者写入即可，操作系统会读取缓存区或者写入缓存区到真正的I/O设备。
事件驱动程序可以由任何程序语言来实作，然而使用某些语言来撰写会比其他的语言来的简单。有些整合开发环境（简称IDE）也会影响实作事件驱动程序设计的难易程度。有的 IDE 会使的开发工作变的很简单，有的则不一定甚至反之。
在GUI编程中事件是非常常见的。比如用户在界面点击了按钮，就会发送一个“点击”事件，而相应的会有一个处理“点击”事件的事件处理器会来处理该事件。因此所谓事件驱动，简单地说就是你点什么按钮（即产生什么事件），电脑执行什么操作（即调用什么函数）。当然事件也不仅限于用户的操作。事件驱动的核心自然是事件。从事件角度说，事件驱动程序的基本结构是由一个事件收集器、一个事件发送器和一个事件处理器组成。事件收集器专门负责收集所有事件，包括来自用户的（如鼠标、键盘事件等）、来自硬件的（如时钟事件等）和来自软件的（如操作系统、应用程序本身等）。事件发送器负责将收集器收集到的事件分发到目标对象中。事件处理器做具体的事件响应工作，它往往要到实现阶段才完全确定。对于框架的使用者来说，他们唯一能够看到的是事件处理器。这也是他们所关心的内容。
对一个事件驱动（event driven）系统进行程序设计，因此可以视为改写系统预设触发函式的行为，来符合自己需要的一种动作。输入的事件可以放进事件回圈或者是经由已经注册的中断处理器来与硬体事件互动；而许多的软体系统使用了混和这两种技术的处理。预先设计好的演算法确定了一件事，那就是当他们被需要的时候，就会在适当的时机被触发。也因此提供了一个模拟中断驱动环境（interrupt driven environment）的软体抽象架构。事件驱动程序设计基本上包含了许多小程序片段，这些小程序片段被称为事件处理器并且被用来回应外部的事件与分发事件。通常尚未被事件处理器处理的事件，都会被系统放在一个称为事件队列的资料结构中，等待被处理。
事件驱动编程通常只是用一个执行过程，CPU之间不是并发的，在处理多任务的时候，事件驱动编程是使用协作式处理任务，而不是多线程的抢占式。事件驱动简洁易用，只需要注册感兴趣的事件，在回调中设计逻辑就可以了。在调用的过程中，事件循环器（Event Loop）在等待事件的发生，跟着调用处理器。事件处理器不是抢占式的，处理器一般只有很短的生命周期。
优势
在大部分的应用场景中，事件编程优与多线程编程。
相对与多线程编程来讲，事件驱动编程比较容易，复杂度低，是开发者乐于接受的。
大多数的GUI框架，都是使用事件驱动编程了架构的。每一个事件会绑定一个处理器，这些事件通常是点击按钮，选择菜单，等等。处理器r来实现具体的行为逻辑。
事件驱动经常使用在I/O框架中，可以很好的实现I/O复用。很多高性能的I/O框架都是使用事件驱动模型的，例如：Netty、Mina、Node.js。
易于调试。时间依赖只和事件有关系，而不是内部调度。问题容易暴露。
劣势
如果处理器占用时间较长，那会阻塞应用程序的响应。
无法通过时间来维护本地状态，因为处理器必须返回。
通常在单CPU环境下，比多线程编程要快，因为没有锁的因素，没有线程切换的损耗。CPU不是并发的，这样的话就不适合用在一些科学计算的应用中。
基本架构
主要由三部分构成:
1.事件收集器
2.事件发送循环器(EventLoop)
3.事件处理器
收集器专门负责收集所有事件，如gui例子中的键鼠事件、来自硬件的、网络的、操作系统的等等；发送器负责将收集器收集到的事件发送到目标对象中；处理器做具体的事件响应 -- 非抢占式执行，且一般拥有很短的生命周期。
事件循环器（Event Loop）的实现
Event Loop是一个程序结构，用于等待和发送消息和事件。事件驱动编程的代码核心就是事件循环器，在Linux下推荐使用epoll实现，在其它没有epoll 的系统上可以使用kqueue/ports/poll/select实现。
下图是事件循环器的工作示例图。事件循环器不断接受来自客户端（Client）的请求，事件循环器把请求转交给注册了某类事件的工作线程（Worker）处理。
事件驱动的优点是做了解耦, 并发编程简单, 易于调试。缺点是容易陷入事件森林不可拔, 如果处理器占用cpu时间过长, 容易阻塞app, 且用在单cpu环境下破环力更大。
在处理多任务的时候，事件驱动编程使用协作式处理任务，而不是传统的多线程抢占；这更简单易用，只需要注册感兴趣的事件，在回调中设计动作就可以了，在执行过程中eventloop不断消费事件，然后对应着调用处理器。
EventLoop是一个程序结构，用于等待和发送消息和事件，是事件驱动编程的代码核心。比较著名的有linux下的epoll，bsd下的kqueue实现。
EventLoop不断的运行、不断的接受来自client的请求，然后把请求转交给注册了某类事件的worker线程处理。依据实现的方式不同，主要有两种设计模式：reactor以及proactor。
Reactor
首先来回想一下普通函数调用的机制：
程序调用某函数->函数执行
程序等待->函数将结果
控制权返回给程序->程序继续处理
和普通函数调用的不同之处在于：应用程序不是主动的调用某个API完成处理，而是恰恰相反，应用程序需要提供相应的接口并注册到Reactor上，如果相应的事件发生，Reactor将主动调用应用程序注册的接口，这些接口又称为“回调函数”。
用“好莱坞原则”来形容Reactor再合适不过了：不要打电话给我们，我们会打电话通知你。
举个例子：你去应聘某xx公司，面试结束后。
“普通函数调用机制”公司HR比较懒，不会记你的联系方式，那怎么办呢，你只能面试完后自己打电话去问结果；有没有被录取啊，还是被拒了；
“Reactor”公司HR就记下了你的联系方式，结果出来后会主动打电话通知你：有没有被录取啊，还是被拒了；你不用自己打电话去问结果，事实上也不能，因为你没有HR的联系方式。
Reactor模式的优点
编写高性能网络服务器的必备技术之一，它具有如下的优点：
1）响应快，不必为单个同步时间所阻塞，虽然Reactor本身依然是同步的；
2）编程相对简单，可以最大程度的避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销；
3）可扩展性，可以方便的通过增加Reactor实例个数来充分利用CPU资源；
4）可复用性，Reactor框架本身与具体事件处理逻辑无关，具有很高的复用性。
Reactor模式框架
使用Reactor模型，必备的几个组件：事件源、Reactor框架、事件多路复用机制和事件处理程序，先来看看Reactor模型的整体框架，接下来再对每个组件做逐一说明。
1）事件源：Linux上是文件描述符，Windows上就是Socket或者Handle了，这里统一称为“句柄集”；程序在指定的句柄上注册关心的事件，比如I/O事件。
2）事件多路复用机制：由操作系统提供的I/O多路复用机制，比如select和epoll。程序首先将其关心的句柄（事件源）及其事件注册到多路复用机制上。当有事件到达时，事件多路复用机制会发出通知“在已经注册的句柄集中，一个或多个句柄的事件已经就绪”。程序收到通知后，就可以在非阻塞的情况下对事件进行处理了。
3） Reactor。是事件管理的接口，内部使用事件多路复用机制注册、注销事件；并运行事件循环，当有事件进入“就绪”状态时，调用注册事件的回调函数处理事件。
4）事件处理程序。事件处理程序提供了一组接口，每个接口对应了一种类型的事件，供Reactor在相应的事件发生时调用，执行相应的事件处理。通常它会绑定一个有效的句柄。
使用Reactor模式后，事件控制流是什么样子呢？可以参见下面的序列图。
分别以读操作和写操作为例来看看Reactor中的具体步骤：
1) 应用程序注册读就绪事件和相关联的事件处理器；
2) 事件分离器等待事件的发生；
3) 当发生读就绪事件的时候，事件分离器调用第一步注册的事件处理器；
4) 事件处理器首先执行实际的读取操作，然后根据读取到的内容进行进一步的处理。
写入操作类似于读取操作，只不过第一步注册的是写就绪事件。
Proactor
来看看Proactor模式中读取操作和写入操作的过程：
1) 应用程序初始化一个异步读取操作，然后注册相应的事件处理器，此时事件处理器不关注读取就绪事件，而是关注读取完成事件，这是区别于Reactor的关键。
2) 事件分离器等待读取操作完成事件。
3) 在事件分离器等待读取操作完成的时候，操作系统调用内核线程完成读取操作（异步I/O都是操作系统负责将数据读写到应用传递进来的缓冲区供应用程序操作），并将读取的内容放入用户传递过来的缓存区中。这也是区别于Reactor的一点。
4) 事件分离器捕获到读取完成事件后，激活应用程序注册的事件处理器，事件处理器直接从缓存区读取数据，而不需要进行实际的读取操作。
Proactor中写入操作和读取操作，只不过感兴趣的事件是写入完成事件。
从上面可以看出，Reactor和Proactor模式的主要区别就是真正的读取和写入操作是有谁来完成的，Reactor中需要应用程序自己读取或者写入数据，而Proactor模式中，应用程序不需要进行实际的读写过程，它只需要从缓存区读取或者写入即可，操作系统会读取缓存区或者写入缓存区到真正的I/O设备。