用户接口设计五----应用任务

    应用程序代码对事件进行处理。应用代码的控制流程起源于一个循环，该循环对事件队列进行读取。对一个队列来说，多个写入者是可取的，但是一般来说最好只有一个读取者。如果你出现了需要多个读取者得情形，最好问问自己是否你真正需要的是多个队列。

主循环最主要的特色是如何识辨EventQueueEntry并且如何选择调用合适的函数。有时候，我们应该考虑从用户接口不同部分产生的事件是否可以被不同的任务进行处理，通常这将会使得系统看似更加并行执行以及更好的响应时间。例如，一个单一的任务用来处理按键按下，另外一个可以用来处理超时事件，另一个可以处理录像带插入和移除事件。为了保护对输出硬件以及公共数据结构的并发访问冲突，我们需要锁或者是信号量。

理论上来讲，这可以对确定的事件提供更好的响应时间。例如，一个特定的按键处理消耗30ms 的CPU时间，录像带插入处理消耗300ms。操作者插入录像带并立即按下按键，假使这两个看起来就像两个操作者同时操作一样。开始的50ms时间花费在处理录像带插入上。随后，按键处理操作接管了CPU，并完成按键处理操作。接下来继续处理录像带操作。如果我们考虑到上下文切换的时间，这两个任务所需的时间会有所增加。从这点上看，总的消耗时间组成如下：50ms按键处理，300ms录像带插入，以及两次上下文切换时间。

然而，从操作者的角度来看，按键操作的反馈差不多如同四分之一秒般快速。

在上面的情景中，立即发生的录像带插入操作的第一部分响应，通常会给用户这样的印象：我的操作被机器识别了。例如，点亮一颗LED告诉操作者录像带已经被机器检测到了。在电机开始运转之前，操作者几乎不会察觉到这之间的延时。

    当然，获得如此好的响应时间也是需要付出代价的。为了保护公共数据以及硬件的共享访问，需要使用一些软件保护措施，这将会使得软件的复杂性大大增加。在采用这些保护措施之前，先要对公共硬件以及数据进行分析，看看是否有太多的重叠操作，以至于任务将会等待同一资源，而这就是瓶颈所在。

    在一个通过一个单一屏幕向用户产生输出，并且通过操作屏幕来响应其它动作的系统中，系统响应只能等到与屏幕及其相关的数据结构获取到之后才能产生。在这样情形下的任一事件处理，在它能够给用户任何反馈之前，必须等待前一个事件完成，即便是前一个事件是由另外一个任务控制。因此，所有的工作都是完全的完成，不能够获得丝毫好的响应时间。如果对公共硬件以及数据的访问比较少，则可以获得一个更好的响应时间，但是这通常会带来吞吐量的损失。在RTOS中，这将会导致额外的上下文切换增加，带来额外的CPU负荷。

    更加重要需要考虑的是：事件的顺序是否对系统有意义。如果系统对按下播放键，随后插入录像带的响应与插入录像带然后按下播放键的响应不同，那么按键事件和插入事件必须投入到同一队列中并且被同一个任务进行处理，只有这样，事件的处理顺序以及系统响应才是确定的。