（一）触摸事件由触屏生成后如何传递到当前应用？
系统响应阶段
1.指触碰屏幕，屏幕感应到触碰后，将事件交由IOKit处理。
2.IOKit将触摸事件封装成一个IOHIDEvent对象，并通过mach port传递给SpringBoad进程。
mach port 进程端口，各进程之间通过它进行通信。
SpringBoad.app 是一个系统进程，可以理解为桌面系统，可以统一管理和分发系统接收到的触摸事件。
3.SpringBoard进程因接收到触摸事件，将触摸事件交给前台app进程来处理。
APP响应阶段
1.APP进程的mach port接受到SpringBoard进程传递来的触摸事件，主线程的runloop被唤醒，触发了source1回调。
2.source1回调又触发了一个source0回调，将接收到的IOHIDEvent对象封装成UIEvent对象，此时APP将正式开始对于触摸事件的响应。
3.source0回调内部将触摸事件添加到UIApplication对象的事件队列中。事件出队后，UIApplication开始一个寻找最佳响应者的过程，这个过程又称hit-testing，另外，此处开始便是与我们平时开发相关的工作了。
4.寻找到最佳响应者后，接下来的事情便是事件在响应链中的传递及响应了。
5.触摸事件历经坎坷后要么被某个响应对象捕获后释放，要么致死也没能找到能够响应的对象，最终释放。至此，这个触摸事件的使命就算终结了。runloop若没有其他事件需要处理，也将重归于眠，等待新的事件到来后唤醒。
简单点说：
触摸事件从触屏产生后，由IOKit将触摸事件传递给SpringBoard进程，
再由SpringBoard分发给当前前台APP处理。
二）应用接收触摸事件后如何寻找最佳响应者？
事件自下而上的传递
hit-testing场景：
图层结构：
A
├── B
│ └── D
└── C
├── E
└── F
现在假设在E视图所处的屏幕位置触发一个触摸，应用接收到这个触摸事件事件后，先将事件传递给UIWindow，然后自下而上开始在子视图中寻找最佳响应者。事件传递的顺序如下所示：
1.UIWindow将事件传递给其子视图A 2.A判断自身能响应该事件，继续将事件传递给C（因为视图C比视图B后添加，因此优先传给C）。 3.C判断自身能响应事件，继续将事件传递给F（同理F比E后添加）。 4.F判断自身不能响应事件，C又将事件传递给E。 5.E判断自身能响应事件，同时E已经没有子视图，因此最终E就是最佳响应者。
Hit-Testing的本质 上面讲了事件在响应者之间传递的规则，视图通过判断自身能否响应事件来决定是否继续向子视图传递。那么问题来了：视图如何判断能否响应事件？以及视图如何将事件传递给子视图？
hitTest:withEvent:
每个UIView对象都有一个 hitTest:withEvent: 方法，这个方法是Hit-Testing过程中最核心的存在，其作用是询问事件在当前视图中的响应者，同时又是作为事件传递的桥梁。 hitTest:withEvent: 方法返回一个UIView对象，作为当前视图层次中的响应者。默认实现是：
1.若当前视图无法响应事件，则返回nil
2.若当前视图可以响应事件，但无子视图可以响应事件，则返回自身作为当前视图层次中的事件响应者
3.若当前视图可以响应事件，同时有子视图可以响应，则返回子视图层次中的事件响应者
一开始UIApplication将事件通过调用UIWindow对象的 hitTest:withEvent:传递给UIWindow对象，UIWindow的 hitTest:withEvent:在执行时若判断本身能响应事件，则调用子视图的 hitTest:withEvent: 将事件传递给子视图并询问子视图上的最佳响应者。最终UIWindow返回一个视图层次中的响应者视图给UIApplication，这个视图就是hit-testing的最佳响应者。
重写hitTest:withEvent: 实操应用场景： 子视图的frame 超过 父视图的部分，为了让子视图能够得到响应，在父视图中 进行重写 hittest方法得到解决：
open override func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? {
if !self.point(inside: point, with: event) {
for subview in self.subviews.reversed(){
let convertedPoint = subview .convert(point, from: self)
let hitTestView = subview .hitTest(convertedPoint, with: event)
if (hitTestView != nil) {
return hitTestView
}
}
}
return super .hitTest(point, with: event)
}
响应者对于事件的操作方式：
响应者对于事件的拦截以及传递都是通过 touchesBegan:withEvent:方法控制的，该方法的默认实现是将事件沿着默认的响应链往下传递。
响应者对于接收到的事件有3种操作：
1.不拦截，默认操作 事件会自动沿着默认的响应链往下传递
2.拦截，不再往下分发事件 重写 touchesBegan:withEvent: 进行事件处理，不调用父类的 touchesBegan:withEvent:
3.拦截，继续往下分发事件 重写touchesBegan:withEvent: 进行事件处理，同时调用父类的 touchesBegan:withEvent: 将事件往下传递
实操应用场景： 自定义弹框视图，视图view 添加 self.contentView， self.contentView(半透明背景视图) ，view同时添加了tabbleView,点击 contentView dismiss当前页面（默认点击事件被tableview拦截了，无法dismiss contentview）
override func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?) {
for genre in touches {
let point = genre.location(in: self.contentView)
let contentViews = self.contentView.hitTest(point, with: event)
if contentViews == nil {
self.dismiss(animated: true, completion: nil)
}
}
}
响应链中的事件传递规则：
每一个响应者对象（UIResponder对象）都有一个nextResponder 方法，用于获取响应链中当前对象的下一个响应者。因此， 一旦事件的最佳响应者确定了，这个事件所处的响应链就确定了。
对于响应者对象，默认的 nextResponder 实现如下：
1.UIView 若视图是控制器的根视图，则其nextResponder为控制器对象；否则，其nextResponder为父视图。
2.UIViewController 若控制器的视图是window的根视图，则其nextResponder为窗口对象；若控制器是从别的控制器present出来的，则其nextResponder为presenting view controller。
3.UIWindow nextResponder为UIApplication对象。
4.UIApplication 若当前应用的app delegate是一个UIResponder对象，且不是UIView、UIViewController或app本身，则UIApplication的nextResponder为app delegate。
///扩展中的方法
extension UIView {
var getCurrentVC: UIViewController? {
var next = superview
while (next != nil) {
let nextResponder = next?.next
if (nextResponder is UIViewController) {
return nextResponder as? UIViewController
}
next = next?.superview
}
return nil
}
}
