事件机制

    事件其实就是系统级别的消息。消息的概念更广一些，通常一个对象向另一个对象的请求（Request）就是一条消息。而事件往往是由系统发出来的，经由操作系统到达应用程序来处理，是“反向”的消息。我们和一个应用程序（应用服务或应用系统）交互，看上去我们是和应用直接交互，事实上我们是先和OS交互，我们要先和硬件交互（敲击键盘，点击鼠标，触屏，其他输入设备），而硬件发出中断给驱动程序，这个时候才到软件处理层（此时的硬件“中断”已经转化成了软件中定义的“事件”）。OS是最先接触到这些事件的软件（驱动可以认为是OS的一部分）。OS通过事件调度把这些事件转化为相应的消息传递给合适的应用程序去处理。 这个时候，才轮到我们的应用系统来响应这些事件。我们看上去好像是直接接收到用户的事件，其实在软件之下已经转了一圈，反向的抛给了我们上层的应用。所以事件有别于普通的消息，它是反向传递的。

   事件处理机制，一般都使用Observer设计模式。一个系统处理事件，就如同要处理回调一样。在当前的很多Framework里，处理事件一般都由框架来完成。我们自己的软件只要去实现框架给的事件处理接口就可以了。比如在symbian系统里，响应事件的类对象是控件（CCoeControl），其接口类似HandleKeyEventL( const TKeyEvent& aKeyEvent,TEventCode aType)。这样，要处理事件，只要override该函数就可以了。

  事件通常在系统构建前就是预先知道的。比如鼠标单击事件，双击事件，触屏手势（点击，长按，拖动，快速滑动，双击，捏，两个手指长按），键盘事件，定时器事件等等。只有预先知道，我们的系统才能写代码去处理各种事件（回调接口）。

 

  我们之所以要把事件定义为系统级别的消息，就是因为这些事件都包含了硬件“中断”，而我们软件内部，组件模块间也有很多类似的中断机制，我们把它们成为回调消息，这些消息是我们应用程序中的下层模块向上层模块抛出的消息，机制上很类似OS（Framework）向我们的应用程序抛事件。

  鉴于广大的文章都把事件做了扩充，即非系统事件的消息也统称为事件，这里也有必要继续扩充一下这个话题。

  除了硬件中断产生的事件，还有一类是软件自定义的事件（消息）：比如绘制消息就是这样一类。这类消息可以同系统事件一样进入事件（消息）队列，又框架来派发，也可以指定目标对象去处理。前者一般是postEvent,后者sendEvent。前者是异步的，后者是同步的。对于应用程序来说，有时可以不用区分消息的来源到底是系统硬件产生的还是程序自身产生的，只要做好各种事件（消息）的处理函数（回调）就可以了。这样的设计使得处理事件的模块（或派发模块）更加简单些。

  事件（消息）在对象间的传递一般是从底层向高层传递的。我们可以在每个可能处理事件的对象上设置消息过滤器，这样可以决定该对象是处理该事件（消息）还是忽略之，还可以决定是把消息继续向上传播还是就此中断消息的传递。

 

  关于消息，可以参考之间的文章：《消息的本质》 http://blog.csdn.net/coolmeme/archive/2010/11/29/6042464.aspx