本文共 1219 字，大约阅读时间需要 4 分钟。
一、事件驱动模型的引入。
在引入事件驱动模型之前，首先来回顾一下传统的流水线式编程。
开始--->代码块A--->代码块B--->代码块C--->代码块D--->......--->结束
每一个代码块里是完成各种各样事情的代码，但编程者知道代码块A,B,C,D...的执行顺序，唯一能够改变这个流程的是数据。输入不同的数据，根据条件语句判断，流程或许就改为A--->C--->E...--->结束。每一次程序运行顺序或许都不同，但它的控制流程是由输入数据和你编写的程序决定的。如果你知道这个程序当前的运行状态（包括输入数据和程序本身），那你就知道接下来甚至一直到结束它的运行流程。
事件驱动模型的大体执行流程：
开始---->初始化---->等待
当基于事件驱动模型的程序一旦执行，就会开始等待，等待一个事件被触发。（其实等待一个事件被触发的情况，在传统的流水线式编程中也有，“等待”的情况存在，比如说一个raw_input会导致程序去等待用户的输入一个数据。）但是，你需要知道，这两种等待是有不同的！
流水线编程的“等待”是程序的编写者提前知道，或者需要去强制程序的使用者去输入一些数据。
但是事件驱动模型中的”等待“，完全不知道程序的使用者到底要做什么，某件事一旦发生（比如，用户单击了一下鼠标，或者敲了下键盘按键，以及系统内部定时器的触发。）程序就会做出相应的“反应”。
二、简单介绍事件驱动模型。
常用的事件驱动模型大概可以分为3类。
-
当每收到一个请求的时候，创建一个线程来处理请求。
-
当每收到一个请求的时候，创建一个进程来处理请求。
-
当每收到一个请求的时候，将一个请求放进事件列表，让主进程通过非阻塞I/O方式来处理请求。#（这种方法是指协程事件驱动的方式。）
假设，现在需要创建一个线程，利用死循环的方式，去检测用户的鼠标是否有一个点击的动作。
-
首先使用死循环去检测鼠标是否有点击动作这个做法就很浪费cpu资源！
-
如果检测鼠标是否点击的接口阻塞了，程序停在这了，又会引发另一个问题，如果这时候还要检测，键盘是否有被按下，（有多个事件需要被检测），检测鼠标是否被按下的接口还在阻塞状态，接下来就永远不会去检测键盘。
所以说，现在大部分的UI编程，都基于事件驱动模型，大部分的UI编程都会提供一个onClick()事件，这个事件代表了按下鼠标的一个事件，这个事件处理的大体模型如下：
首先先来看上图：
1.事件驱动模型，首先是要有一个事件列表（这个列表相当于消息队列）。
2.一旦点击鼠标，就会在这个事件列表（消息队列）中，添加一个事件（消息）。
3.此时，会有一个循环，不断的从事件列表（消息队列）里面取事件，根据不同的事件调用不同的函数。
4.事件（消息）都有一个独立的处理函数。
本文转自苏浩智 51CTO博客，原文链接：http://blog.51cto.com/suhaozhi/1926755，如需转载请自行联系原作者