前言
无论是Android，还是IOS，都是事件驱动的操作系统，事件是操作系统的灵魂。却很少有人能够理清楚事件在操作系统内部是如何进行传递处理的。这篇文章将深入探讨iOS系统事件，阐述事件是如何在iOS系统内部进行传递并处理的，希望这篇文章能够对你有所帮助。
代码说明
本文将使用Objective-C语言进行编码，使用Cocoapods作依赖管理。同时，使用了一个非常优秀的自动布局库PureLayout。PureLayout是拥有非常优秀的自动布局API，支持iOS和OS X双系统，强烈推荐大家使用。
基本原理
事件的分类
iOS系统将事件分为三类：
- Multitouch Events
- Motion Events
- Remote Control Events
Multitouch Events: 所谓的多点触摸事件，非常好理解，即用户触摸屏幕交互产生的事件类型。
Motion Events: 所谓的移动事件。是指用户在摇晃，移动和倾斜手机的时候产生的事件成为移动事件。这类事件依赖于iPhone手机里面的加速计，陀螺仪等传感器。
Remote Control Events：所谓的远程控制事件。这个事件从名称上面看，不太好理解。但其实，这个事件指的是用户在操作多媒体的时候产生的事件。比如，播放音乐、视频等。
仔细分析这三类事件，Multitouch Events有明确的触摸视图，UIKit框架的View对象可以明确获取到当前点击的视图对象以及坐标。然后，对触摸视图做出相应的响应。而Motion Events和Remote Control Events却没有一个明确的交互界面的概念。iOS系统为了支持对这类事件的响应，提出了Responder的概念。
关于Responder，我们后面再来探讨。
鉴于系统对这三类事件处理的区别，我们将这三类事件区分为两类：
- Multitouch Events 有明确的交互界面，可以获取到当前点击的视图组件，并作出相应的响应。
- Motion Events and Remote Control Events 没有明确的交互界面，依赖于Responder对事件作出相应的响应
Continue
首先，让我们来了解一下Responder的概念，什么是Responder，怎样才能成为Responder，Responder又是如何对事件作出响应的。
About Responder
- 什么是Responder？
Responder是UIKit框架封装的一个对象类型，它可以响应并处理事件。所有Responder对象的基类都是UIResponder，下面我们来通过一张类图看看哪些对象具有Responder特性
图-1
从上图可以看出，UIApplication、UIViewController和UIView都是UIResponder对象，都具有对事件进行响应，处理的能力
再来看看UIResponder类里面的一些方法和属性
- (UIResponder* )nextResponder;
- (BOOL)canBecomeFirstResponder; // default is NO
- (BOOL)becomeFirstResponder;
// Touch Event
- (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event;
- (void)touchesMoved:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event;
- (void)touchesEnded:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event;
- (void)touchesCancelled:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event;
// Motion Event
- (void)motionBegan:(UIEventSubtype)motion withEvent:(UIEvent *)event NS_AVAILABLE_IOS(3_0);
- (void)motionEnded:(UIEventSubtype)motion withEvent:(UIEvent *)event NS_AVAILABLE_IOS(3_0);
- (void)motionCancelled:(UIEventSubtype)motion withEvent:(UIEvent *)event NS_AVAILABLE_IOS(3_0);
// Remote Control Event
(void)remoteControlReceivedWithEvent:(UIEvent*)event NS_AVAILABLE_IOS(4_0);
从上面的代码片段，可以看到UIResponder对象可以处理TouchEvent，MotionEvent和Remote Control Event事件。还有一个非常重要的方法nextResponder,这个方法可以获取到下一个关联的Responder，Responder对象正是关联nextResponder引用组成了一个Responder链，我们称之为The Responder Chain,系统事件会沿着这个Responder Chain传播到nextResponder，直到最后一个Responder，如果依然没有处理该事件，事件就会被舍弃。但是，问题来了，系统必须先找到第一个Responder，即第一个可以响应该对象的事件。英文称之为First Responder。
- 怎样才能成为First Responder？
这里还需要关注的一个概念就是First Responder，First Responder是第一个可以处理当前事件的对象，如果First Responder不能处理当前事件，则传递到nextResponder。然后依次传递给nextResponder。
我们用一张官方的图，来具体地看看Responder是如何在响应链之间传递的
我们来分析一下，事件的传递过程：
第一步，Application对象从事件队列中获取事件对象
第二步，Application对象将事件对象传递给Window，Window对象继续传递给First Responder，然后事件就会沿着Responder Chain（响应者链）传递，直到找到可以处理它的对象。
基于上面的讨论，事件的传递过程，我们基本已经讨论清楚。但是，仅仅是讨论还不够，我们缺乏必要的论据，关于事件传递的证明，我会在后面给出代码证明。
这里，我们先来关注一个问题：
对于TouchEvents事件，系统是如何获取到当前正在点击的视图对象的呢？（其实就是寻找First Responder）
这依赖于UIView里面的两个方法：
- (nullable UIView *)hitTest:(CGPoint)point withEvent:(nullable UIEvent *)event;
- (BOOL)pointInside:(CGPoint)point withEvent:(nullable UIEvent *)event;
第一个方法会返回当前点击的View对象，第二个方法判断当前点击的坐标是否在当前视图边界范围内。如果在当前视图范围内，则返回YES，否则，返回NO。第一个方法会根据第二个方法的判断返回当前点击的视图。
下面我们通过一个比较直观的图形来讲述iOS系统获取当前点击视图对象的过程：
假设用户点击了视图D：
- 检测到点击坐标在View A范围之内。
- 继续检测点击范围是否在其子视图B，C范围内。发现点击范围在视图C范围内，则忽略掉B视图及其子视图分支。
- 继续检测点击范围是否在其子视图D范围内，如果是，则用户当前视图即为视图D。如果不是，继续检测其子视图。
根据上述分析：iOS系统会从父视图向子视图依次查找，直到找到点击范围在当前视图边界范围以内。如果点击范围在某子视图范围内，并且没有了子视图，则该视图即为当前点击视图。如果点击范围在某子视图范围之内，并且不在其子视图范围之内，则点击视图即为当前点击视图。
PS：感兴趣的同学可以自己去证明一下点击视图的查找过程。
下面开始事件传递的证明：
为此我们创建如上图所示的一个简单app，三种颜色View分别对应类
红色：FirstView
绿色：SecondView
蓝色：ThirdView
我们以Remote Control Events为例，来看看事件的传递过程：
首先，我们让SecondView成为First Responder
- (BOOL)canBecomeFirstResponder {
return YES;
}
// 然后在ViewController中，执行如下代码
[_secondView becomeFirstResponder];
然后，在三个视图分别添加如下测试语句：
FirstView
- (void)remoteControlReceivedWithEvent:(UIEvent *)event {
switch (event.subtype) {
case UIEventSubtypeRemoteControlPlay:
NSLog(@"FirstView:Play");
break;
default:
break;
}
}
SecondView
- (void)remoteControlReceivedWithEvent:(UIEvent *)event {
switch (event.subtype) {
case UIEventSubtypeRemoteControlPlay:
NSLog(@"SecondView:Play");
break;
default:
break;
}
}
ThirdView
- (void)remoteControlReceivedWithEvent:(UIEvent *)event {
switch (event.subtype) {
case UIEventSubtypeRemoteControlPlay:
NSLog(@"ThirdView:Play");
break;
default:
break;
}
}
运行，从屏幕底部拉出音频播放界面，点击播放。这里会触发Remote Control Event，回调上图中的方法。
看到如下输出日志：
EventDelivery[4559:323237] SecondView:Play
注释掉SecondView里面的 remoteControlReceivedWithEvent:，我们可以看到如下输出日志：
EventDelivery[4559:323237] ThirdView:Play
这里的现象说明：Remote Control Event会沿着父视图往子视图传递，即父视图的nextResponder就是其子视图。这里大家可以考虑一下，如果当前视图有多个直接的子视图呢？nextResponder会是哪一个？请读者们自行证明。
这里，我们更进一步证明，事件是否会从View传递给ViewController，注释掉三个视图里面的remoteControlReceivedWithEvent:方法，并在ViewController中重写该方法，同时添加打印日志输出，运行，可以看到如下日志输出：
EventDelivery[4559:323237] ViewController:Play
这更进一步证明了Responder的传递方向符合上面的分析。
总结
iOS系统将事件分为三类：
- Touch Events
- Motion Events
- Remote Control Events
根据三类事件获取First Responder方式的不同，又可以将事件分为：
- Touch Events
- Motion Events and Remote Control Events
第一类事件通过获取当前用户交互的界面组件，即为First Responder
第二类事件的First Responder由用户手动指定。
成为First Responder必须实现如下两个步骤：
- 重写canBecomeFirstResponder方法，返回YES
- 给UIResponder对象发送becomeFirstResponder消息
综上所述，事件的传递过程可以分为两步：
第一步，获取到First Responder，不同的事件有不同的获取方式。
第二步，从First Responder沿着Responder Chain传递到nextResponder，直到事件被处理或者舍弃。
常见的Responder传递方向有：
Initial View -> Parent View -> ViewController -> Window -> Application
如果最终传递到Application对象，依然没有对事件作出响应，事件就会被舍弃掉。
通常来说，子视图的nextResponder即为其父视图。如果子视图直接依附于ViewController，则该子视图的nextResponder即为其依附的ViewController
PS：本文源码和文章原稿都在下方我的Github仓库中，有任何问题请按照下面的方式联系我。
参考资料：Event Handling Guide for iOS
如果你喜欢这篇文章，请到Fork我的github仓库：
https://github.com/yuanhoujun/jianshu.git
如果你对这篇文章有任何的修改建议，请给我发送Pull Request。如果你想给我留言，可以加我的QQ：626306805，如果你想和更多的人一起讨论iOS，请加入iOS交流群：468167089
