当你设计一个app的时候，可能会有这样的场景，你想动态的去响应一个事件。例如，在屏幕上的一个触摸事件可能在不同的对象中都发生，并且你不得不决定由哪一个对象来响应这个事件并且尝试去理解怎么样的一个对象接收了到这个事件。
当一个常见的用户事件发生的时候，UIKit会创建一个事件对象Event Object,该对象包含了事件处理所必须得一些信息。然后它会将事件对象置于激活的app事件队列。例如触摸事件，该触摸时事件对象是一系列触摸信息包装集。例如手势事件，该事件是一个动态的变量它取决于你使用了什么框架以及你感兴趣的手势事件类型。
一个事件会游走于指定的传递路径很长的时间直到它被处理。首先，这个单例 UIApplication 对象会从事件队列顶部拿出一个事件对象用于分发处理。比较典型的就是，它会发送这个事件给 Window 对象，Wiindow对象会递交事件给原始对象 initial object去处理。initial object取决于事件的类型。
触摸事件：对于触摸事件，window对象会尝试着首先将事件传递给触摸事件发生点得View。这个View被视为“命中测试view” (hit-test view)。寻找“命中测试view”的过程被称作“命中测试”,关于“命中测试”会在下面的 命中测试返回触摸事件发生点的view 有详情描述。
手势和远程控制事件：对于这些事件，window对象发送震动手势或者远程控制事件给第一响应者去处理，关于第一响应者的定义在下面的响应者链的构造中有详情描述。
最终所有的事件响应路径都是为了去寻找那个能够响应并处理该事件的对象。因此，UIkit会首先发送该事件给最适合处理该事件的对象。对于触摸事件，这个最适合处理的对象就是 hit-test view既“命中测试view”,并且对于其它事件，这个对象就是“第一响应者”。下面的几个部分将详细的解释更多的关于“命中测试view”和第一响应者的选择。
命中测试返回触摸事件发生点的view
iOS使用“命中测试”（hit-testing）去寻找触摸发生下的view。命中测试会执行检测判断是否改触摸点发生在某个具体的view的相对边界之内。如果检测是的，它就会递归的去检测该view的所有子view。该view的层级最底端view包含触摸点，它就成为了“命中测试view”。之后iOS就会决定谁是命中测试view,并且递交触摸事件给它处理。
为了去阐明这个过程，假设用户触摸 view E 如图2-1。iOS会以这样的顺序去寻找命中测试view通过检测所有的子view.
1. 触摸点是否在view A的边界之内，如果是它会检测子视图B和C.
2. 触摸点不在view B的边界之内，但是它在view C的边界之内，因此它就去检测C的子视图D和E。
3. 触摸事件不在view D的边界之内，但是在view E的边界之内。view E是整个包含触摸事件的view层级中最底端的view，因此view E就名正言顺的成为了“命中测试view”。
图：2-1
方法 hitTest:withEvent 传入CGPoint和UIEvent返回命中测试view。这个方法hitTest:withEvent开始执行通过调用自身的 ponitInside:withEvent 方法。如果传入hitTest:withEvent的point在view的边界之内。ponitInside:withEvent方法就会返回YES。然后该方法会递归调用hitTest:withEvent方法在每一个返回YES的子view上。
如果传入的hitTest:withEvent的点不在view的边界之内，首先会调用ponitInside:withEvent方法返回NO,该point会被忽略，并且hitTest:withEvent返回nil，如果一个子view返回NO，那么整个view层级的分支都会被忽略，因为如果触摸点没有发生在子view，她也不可能发生在任何子view的子view。这就意味着任何子view上面的点都在边界之外并且它的父view也不能接受触摸事件，因为触摸点必须同时在父view和子view的边界之内。这种情况可能会发生，如果子view的 clipsToBound 属性设为NO。
注意：一个触摸事件对象将会被关联于命中测试view的整个生命周期，即使这个触摸后来移到了view的边界之外。
命中测试view 被赋予了第一个处理触摸事件的机会，如果命中测试view不能处理该事件，该事件就会交付给view响应者链的上一级处理直到系统找到一个能够处理该事件的对象。
