UIControl && UIGestureRecognizer && UIResponder

事件传递和响应链

一. 事件传递

1. 用户点击屏幕后产生的一个触摸事件，经过一系列的传递过程后，会找到最合适的视图控件来处理这个事件，找到这个终极视图的过程就是事件传递的过程
2. 方向：由UIApplication -> UIWindow -> UIView -> initial view,以上就是事件的传递，也就是寻找最合适的view的过程。
3. 怎么找的？：利用UIView的方法：
    a. hitTest:(CGPoint)point withEvent:(UIEvent *)event
    b. pointInside:(CGPoint)point withEvent:(nullable UIEvent *)event
从UIWindow的subViews开始一直向子视图循环遍历，寻找手指当前位置最前面的那个 hittest view。
4. 可阻断事件传递：a: userInteractionEnabled = NO；b. 隐藏；c: 控件的透明度<0.01。
5. 如果没有符合条件的子控件，那么就认为自己最合适处理这个事件，也就是自己是最合适的view。
6. 所以如果循环遍历过程中是view1阻断了事件传递，那么view1的父视图则是最合适的view，因为此时view1的父视图也肯定满足：触摸点是在自己身上的条件。

二.响应链

1. 响应者对象（UIResponder）
2. 继承自UIResponder的，所以都能接收并处理事件：
    UIApplication
    UIViewController
    UIView
3. 比如对于touch事件来说有touchesBegan: withEvent:,touchesMoved: withEvent:,touchesCancelled: withEvent:,touchesEnded: withEvent:
4. 如果一个UIResponder子类重写（override）了上述所说事件响应方法，那么事件就算这个被这个类的实例响应了。响应就不再会沿着响应链传递。
5. 一个UIControl，不管它有没有被增加一个target，响应传递到它这里就终止了，不会再向父视图寻找响应。UIControl应该是实现了上面说的几个响应事件的方法。

6. UIResponder是所有可以响应事件的类的基类(从名字应该就可以看出来了)，其中包括最常见的UIView和UIViewController甚至是UIApplication，所以我们的UIView和UIViewController都是作为响应事件的载体。

那么响应链跟这个UIResponder有什么关系呢？
事实事件响应链的形成和事件的响应和传递，UIResponder都帮我们做了很多事。我们的app中，所有的视图都是按照一定的结构组织起来的，即树状层次结构，每个view都有自己的superView，包括controller的topmost view(controller的self.view)。
当一个view被add到superView上的时候，他的nextResponder属性就会被指向它的superView，当controller被初始化的时候，self.view(topmost view)的nextResponder会被指向所在的controller，而controller的nextResponder会被指向self.view的superView，这样，整个app就通过nextResponder串成了一条链，也就是我们所说的响应链。
所以响应链就是一条虚拟的链，并没有一个对象来专门存储这样的一条链，而是通过UIResponder的属性串连起来的

注意点： 当viewController的自带self.view的交互userInteractionEnabled关闭的时候，点击self.view页面，写在controller里面的touchbegin事件也不会响应；
此处touchbegin属于controller，如果顺着响应链，self.view不响应，传给viewController，vc应该是响应事件的，但是，userInteractionEnabled = NO，阻断了一开始的事件传递，相当于hittest寻找到的最合适的view是self.view的父视图，而不是vc，所以vc就不存在响应touchbegin这一说法了。

响应链：

00.png

三.UIGestureRecognizer

1. UIGestureRecognizer是继承NSObject, 而不是UIResponder
2. 在一个button上添加一个UITapGestureRecognizer手势，默认情况只有手势的事件，不响应button的TouchUpInside点击事件(但是响应TouchDown的事件)；若设置tap.cancelsTouchesInView = NO; 则会响应手势事件，然后再响应button的点击事件，就是两个事件都会触发。
3. cancelsTouchesInView： 
默认为YES,这种情况下当手势识别器识别到touch之后，会发送touchesCancelled给hit-testview以取消hit-test view对touch的响应（但是已经触发的TouchDown或者touchBegin取消不了，只取消了后续的事件eg. touchUpInside），这个时候只有手势识别器响应touch。

当设置成NO时，手势识别器识别到touch之后不会发送touchesCancelled给hit-test，这个时候手势识别器和hit-test view均响应touch。

四.cancelsTouchesInView/ delaysTouchesBegan/ delaysTouchesEnded

 1.这3个属性是作用于GestureRecognizers(手势识别)与触摸事件之间联系的属性。实际应用中好像很少会把它们放到一起，大多都只是运用手势识别，所以这3个属性应该很少会用到。

2.对于触摸事件，window只会有一个控件来接收touch。这个控件是首先接触到touch的并且重写了触摸事件方法（一个即可）的控件

3.手势识别和触摸事件是两个独立的事，只是可以通过这3个属性互相影响，不要混淆。
(1)在默认情况下（即这3个属性都处于默认值的情况下），如果触摸window，首先由window上最先符合条件的控件(该控件记为hit-test view)接收到该touch并触发触摸事件touchesBegan。同时如果某个控件的手势识别器接收到了该touch，就会进行识别。手势识别成功之后发送触摸事件touchesCancelled给hit-testview，hit-test view不再响应touch。

(2)cancelsTouchesInView:
 默认为YES,这种情况下当手势识别器识别到touch之后，会发送touchesCancelled给hit-testview以取消hit-test view对touch的响应，这个时候只有手势识别器响应touch。
当设置成NO时，手势识别器识别到touch之后不会发送touchesCancelled给hit-test，这个时候手势识别器和hit-test view均响应touch。

(3)delaysTouchesBegan:
默认是NO，这种情况下当发生一个touch时，手势识别器先捕捉到到touch，然后发给hit-testview，两者各自做出响应。如果设置为YES，手势识别器在识别的过程中（注意是识别过程），不会将touch发给hit-test view，即hit-testview不会有任何触摸事件。只有在识别失败之后才会将touch发给hit-testview，这种情况下hit-test view的响应会延迟约0.15ms。

(4)delaysTouchesEnded:
默认为YES。这种情况下发生一个touch时，在手势识别成功后,发送给touchesCancelled消息给hit-testview，手势识别失败时，会延迟大概0.15ms,期间没有接收到别的touch才会发送touchesEnded。如果设置为NO，则不会延迟，即会立即发送touchesEnded以结束当前触摸。