iOS事件传递

前言

无论是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
1) 什么是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。

2) 怎样才能成为First Responder？
这里还需要关注的一个概念就是First Responder，First Responder是第一个可以处理当前事件的对象，如果First Responder不能处理当前事件，则传递到nextResponder。然后依次传递给nextResponder。

我们用一张官方的图，来具体地看看Responder是如何在响应链之间传递的

 
图-1

我们来分析一下，事件的传递过程：
第一步，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系统获取当前点击视图对象的过程：

 
图-2


假设用户点击了视图D：
1) 检测到点击坐标在View A范围之内。
2) 继续检测点击范围是否在其子视图B，C范围内。发现点击范围在视图C范围内，则忽略掉B视图及其子视图分支。
3) 继续检测点击范围是否在其子视图D范围内，如果是，则用户当前视图即为视图D。如果不是，继续检测其子视图。

根据上述分析：iOS系统会从父视图向子视图依次查找，直到找到点击范围在当前视图边界范围以内。如果点击范围在某子视图范围内，并且没有了子视图，则该视图即为当前点击视图。如果点击范围在某子视图范围之内，并且不在其子视图范围之内，则点击视图即为当前点击视图。

PS：感兴趣的同学可以自己去证明一下点击视图的查找过程。

下面开始事件传递的证明：

 
图-3


为此我们创建如上图所示的一个简单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，回调上图中的方法。

 
图-4


看到如下输出日志：悦德财富：https://www.yuedecaifu.com

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

【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/oceansea/p/5949279.html