调试iOS用户交互事件响应流程

时间 2020-03-23

标签调试 ios 用户交互事件响应流程栏目 iOS 繁體版

原文原文链接

[TOC]程序员

调试iOS用户交互事件响应流程

2020-03-19windows

一般 iOS 界面开发中处理各类用户交互事件。其中，UIControlEvent以注册的 Target-Action 的方式绑定到控件；UIGestureRecognizer经过addGestureRecognizer:添加到UIView的gestureRecognizers属性中；UIResponder提供了touchesBegin/Moved/Ended/Canceled/:withEvent:、motionsXXX:withEvent:、pressXX:withEvent:系列接口，将用户设备的触摸、运动、按压事件通知到UIResponder对象等等。以上都是经常使用开发者处理用户交互事件的方式，那么隐藏在这些接口之下，从驱动层封装交互事件对象到 UI 控件接收到用户事件的流程是怎样的呢？本文主要探讨的就是这个问题。app

1、响应链

Apple Documentation 官方文档Using Responders and the Responder Chain to Handle Events介绍了利用UIResponder的响应链来处理用户事件。UIResponder实现了touchesXXX、pressXXX、motionXXX分别用于响应用户的触摸、按压、运动（例如UIEventSubtypeMotionShake）交互事件。UIResponder包含nextResponder属性。UIView、UIWindow、UIController、UIApplication都是UIResponder的派生类，因此都能响应以上事件。ide

1.1 Next Responder

响应链结构以下图所示，基本上是经过UIResponder的nextResponder成员串联而成，基本上是按照 view 的层级，从前向后由子视图向父视图传递，且另外附加其余规则。总的响应链的规则以下：函数

View 的nextResponder是其父视图；
当 View 为 Controller 的根视图时，nextResponder是 Controller；
Controller 的nextResponder是 present Controller 的控制器；
当 Controller 为根控制器时，nextResponder是 Window；
Window 的nextResponder是 Application；
Application 的nextResponder是 App Delegate（仅当 App Delegate 为UIResponder类型）；

UIResponder响应touchesXXX、pressXXX、motionXXX事件不须要指定userInteractionEnabled为YES。可是对于UIView则须要指定userInteractionEnabled，缘由是UIView从新实现了这些方法。响应UIGesture则须要指定userInteractionEnabled，addGestureRecognizer:是UIView类的接口。工具

注意：新版本中，分离了 Window 和 View 的响应链。当 Controller 为根控制器时，nextResponder其实是nil；Windows 的nextResponder是 Window Scene；Window Scene 的nextResponder是 Application。在后面的调试过程会有体现。oop

1.1.1 调试nextResponder

使用一个简单的 Demo 调试nextResponder。界面以下图所示，包含三个 Label，从颜色能够判断其层次从后往前的顺序是：A >> B >> C。下面两个按钮另作他用，先忽略。ui

运行 Demo，查看各个元素的nextResponder，确实如前面所述。spa

1.2 Target-Action和响应链

UIControl控件与关联的 target 对象通讯，直接经过向 target 对象发送 action 消息。虽然 Action 消息虽然不是事件，可是 Action 消息的传递是要通过响应链的。当接收到用户交互事件的控件的 target 为nil时，会沿着控件的响应链向下搜索，直到找到实现该 action 方法的对象为止。UIKit 的编辑菜单就是经过这个机制实现的，UIKit 会沿着控件的响应链搜索实现了cut:、copy:、paste:等方法的对象。3d

1.2.1 注册UIControlEvents

当UIControl控件调用addTarget:action:forControlEvents:方法注册事件时，会将构建UIControlTargetAction对象并将其添加到UIControl控件的(NSMutableArray*)_targetActions私有成员中，addTarget:action:forControlEvents:方法的 Apple Documentation 注释中有声明调用该方法时UIControl并不会持有 target 对象，所以无需考虑循环引用的问题。UIControl Events 注册过程的简单调试过程以下：

附注：The control does not retain the object in the target parameter. It is your responsibility to maintain a strong reference to the target object while it is attached to a control.

1.2.2 调试UIControlEvents的传递

前面内容提到，控件的 action 是沿着响应链传递的，那么，当两个控件在界面上存在重合的区域，那么在重合区域触发用户事件时，action 消息会在哪一个控件上产生呢？在 1.1.1 中的两个重合的按钮就是为了验证这个问题。

稍微改造一下 1.1.1 的 Demo 程序，将 Label A、B、C 指定为自定义的继承自UILabel的类型TestEventsLabel，将两个 Button 指定为继承自UIButton的TestEventsButton类型。而后在TestEventsLabel、TestEventsButton、ViewController中，为touchesXXX:系列方法、nextResponder方法、hitTest:withEvent:方法添加打印日志的代码，以TestEventsButton的实现为例（固然也能够用 AOP 实现）：

@implementation TestEventsButton

-(UIResponder *)nextResponder{
    UIResponder* responder = [super nextResponder];
    NSLog(@"Next Responder Button %@ - return responder: %@", [self titleForState:UIControlStateNormal], responder);
    return responder;
}

-(UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event{
    UIView* view = [super hitTest:point withEvent:event];
    NSLog(@"Hit Test Button %@ - return view: %@", [self titleForState:UIControlStateNormal], view);
    return view;
}

-(void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event{
    [super touchesBegan:touches withEvent:event];
    NSLog(@"Button %@ - %s", [self titleForState:UIControlStateNormal], __func__);
}
- (void)touchesEnded:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event{
    [super touchesEnded:touches withEvent:event];
    NSLog(@"Button %@ - %s", [self titleForState:UIControlStateNormal], __func__);
}
-(void)touchesMoved:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event{
    [super touchesMoved:touches withEvent:event];
    NSLog(@"Button %@ - %s", [self titleForState:UIControlStateNormal], __func__);
}
-(void)touchesCancelled:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event{
    [super touchesCancelled:touches withEvent:event];
    NSLog(@"Button %@ - %s", [self titleForState:UIControlStateNormal], __func__);
}

@end
复制代码

结论一：Action不会在同级视图层级中传递

一切准备就绪，运行 Demo，点击“点我前Button”，抓取到了以下日志。注意框①中指定的 target 是self，也就是 Controller。能够发现点击事件产生，调用了若干次碰撞检测（框②），若干次nextResponder（框③），最终只调用了 Controller 中“点我前Button”的 action 方法。这是由于：

Target-Action 消息在传递时，永远不会在同级视图层级中传递；
Target 非空，则 UIKit 在确认控件响应某个事件后，会直接给控件的 target 对象发送 action 消息，这个过程不存在任何视图层级传递或响应链传递的过程；

结论二：Target为空时Action仍能够被响应

接下来将addTarget:action:中指定的 target 设为nil。而后在TestEventsButton中也添加 action 的响应代码，以下所示。

-(void)didClickBtnFront:(id)sender{
    NSLog(@"In Button 点我前Button Did Click Action %s", __func__);
}

-(void)didClickBtnBack:(id)sender{
    NSLog(@"In Button 点我后Button Did Click Action %s", __func__);
}
复制代码

点击“点我前Button”，抓取到了以下日志。此次，由TestEventsButton处理了 action 消息。说明当控件注册 action 时指定的 target 为nil时，action 消息仍然能够被响应，且 action 只响应一次。请记住，此时nextResponder被调用了 5 次。

结论三：Target为空时Action沿响应链传递

再进一步修改代码，将结论二中TestEventsButton的新增代码删除，仍然将addTarget:action:中指定的 target 设为nil。点击“点我前Button”，抓取到了以下日志。此次，处理 action 消息的是 Controller。并且从日志中咱们发现，此次nextResponder调用了 6 次，确切地说，是在 Button touchBegin以后，Controller 处理 action 消息以前（如图中红框所示）。这是由于，target 为nil时，action 消息会沿着响应链传递，直到找到能够响应 action 的对象为止。

能够继续尝试给“点我后Button”，直接将self.btnFront的注册 Target-Action 的代码删掉。运行 Demo，再次点击“点我前Button”，此时didClickBtnBack仍然不触发。这其实只是进一步印证了“结论一”的结论，这里再也不演示。

整个调试过程下来，能够发现，被 ButtonA 覆盖的 ButtonB，全部 action 都会被 ButtonA 拦截，被覆盖的 ButtonB 不会得到任何触发 action 的机会。

1.3 手势识别和响应链

Gesture Recognizer 会在 View 以前接收 Touch 和 Press 事件，当 Gesture Recognizer 对一连串的 Touch 事件手势识别失败时，UIKit 才将这些 Touch 事件发送给 View。若 View 不处理这些 Touch 事件，UIKit 将其递交到响应链。

1.4 修改响应链

响应链主要经过nextResponder方法串联，所以从新实现UIResponder派生类的nextResponder方法能够实现响应链修改的效果。

2、Touch事件传递

当 touch 事件发生时，UIKit 会构建一个与 view 关联的UITouch实例，当 touch 位置变化时，仅改变 touch 的属性值，但不包括其view属性。即便 touch 移出了 view 的范围，view属性仍然是不变的。UITouch的gestureRecognizers属性表示正在处理该 touch 事件的全部 gesture recognizer。UITouch的timestamp属性表示 touch 事件的发生时间或者上一次修改的时间。UITouch的phase属性，表示 touch 事件当前所在的生命周期阶段，包括UITouchPhaseMoved、UITouchPhaseBegan、UITouchPhaseStationary、UITouchPhaseEnded、UITouchPhaseCanceled。

2.1 碰撞检测

UIKit 经过 hit-test 碰撞检测肯定哪些 View 须要响应 touch 事件，hit-test 经过比较 touch 的位置与 View 的 bounds 判断 touch 是否与 View 相交。Hit-test 是在 View 的视图层级中，取层级最深的子视图，做为 touch 事件的 first responder，而后从前向后递归地对每一个子视图进行 Hit-test，直到子视图命中，直接返回命中的子视图。

Hit-test 经过UIView的hitTest:withEvent:方法实现，若 touch 的位置超出了 view 的 bounds 范围，则hitTest:withEvent:会忽略该 view 及其全部子视图。因此，当 view 的maskToBounds为NO时，即便 touch 看起来落在了某个视图上，但只要 touch 位置超出了 view 或者其 super view 的 bounds 范围，则该 view 仍然会接收不到 touch 事件。

碰撞检测方法- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event;中，point参数是碰撞检测点在事件发生的 view 的坐标系中的坐标；event参数是使用本次碰撞检测的UIEvent事件。当目标检测点不在当前 view 的范围内时，该方法返回nil，反之则返回 view 自己。hitTest:withEvent:方法是经过调用UIView的- (BOOL)pointInside:(CGPoint)point withEvent:(UIEvent *)event;方法实现的，该方法忽略userInteractionEnabled为NO或者 alpha 值小于 0.01 的视图。

2.2 调试Touch事件传递

Touch 事件传递过程主要调用了hitTest:withEvent:方法，Touch 事件若未被 gesture recognizer 捕捉则最终会去到touchesXXX:系列方法。在响应链的调试时，已经见到很多hitTest:withEvent:调用的痕迹。

在第一章“结论一”的运行日志中，发现点击“点我前Button”时，也对 Label A、B、C 作了碰撞检测，且并无对“点我后Button”作碰撞检测。注意到 Label 和 Button 都是self.view的子视图，且 Label A、B、C 在“点我前Button”以前，“点我后Button”以后。前面提到过：Hit-test 是在 View 的视图层级中，取层级最深的子视图，做为 touch 事件的 first responder，而后从前向后递归地对每一个子视图进行 Hit-test。所以，self.view调用 Hit-Test 时，首先找到的是 Label C。而后，从前向后递归调用hitTest:withEvent:，所以才会有C >> B >> A >> 点我前Button的顺序。为何到“点我后Button”没有递归到呢？这是由于self.view的hitTest:withEvent:在迭代到“点我前Button”时命中了目标，所以直接返回“点我前Button”。而更后面的“点我前Button”就直接被跳过了。

为验证上面的推测。继续在 Demo 中引入继承自UIView的TestEventsView类型，套路和前面的 Button、Label 一致，就是为了打印关键日志。而后将 Controller 的根视图，也就是self.view的类型设置为TestEventsView。而后再在 Controller 的viewDidLoad中增长打印 Button 信息的代码以做对照。

准备就绪，运行 Demo，点击“点我前Button”，获得如下日志，干扰信息变多了，遮挡掉其中一部分。关注到红色框中的内容，发现self.view的hitTest:forEvent:返回的正是“点我前Button”，并且“点我前Button”的hitTest:forEvent:返回了自身。与前面的推测彻底符合。

步骤零：准备工做

前一小节的调试过程其实已经能够证实改结论，可是因为只是经过对有限的相关共有方法，譬如hitTest:forEvent:、nextResponder的调用次序的打印彷佛还不够深刻。接下来用 lldb 下断点的方式，进行调试。

在这以前须要作一些准备工做，此次是使用 lldb 调试主要经过查看函数调用栈、寄存器数据、内存数据等方式分析，所以不须要打印日志的操做，何况新增的hitTest:withEvent、nextResponder、touchesXXX方法会徒增调用栈的层数，所以将TestEventsLabel、TestEventsButton、TestEventsView、ViewController的这些方法悉数屏蔽。去掉一切没必要要的日志打印逻辑。

准备就绪，运行 Demo，先不急着开始，首先查看 Demo 的视图层级，先记住这个UIWindow实例，它是应用的主窗口，它的内存地址是0x7fa8f10036b0，后面会用到。

注意：从 iOS 13 开始，引入了UIWindowScene统一管理应用的窗口和屏幕，UIWindowScene包含windows和screen属性。上图所展现UIWindowScene只包含了一个子 Window，实际真的如此吗？

步骤一：下断点

首先使用break point -n命令在四个关键方法处下断点：

hitTest:withEvent:
nextResponder
touchesBegan:withEvent:
touchesEnded:withEvent:

注意：汇编代码中的函数一般以pushq %rbp、movq %rsp, %rbp开头，其中bp是基地址寄存器（base pointer），sp是堆栈寄存器（stack pointer），bp保存当前函数栈帧的基地址（栈底），sp保存当前函数栈帧的下一个可分配地址（栈顶），函数每分配一个单元的栈空间，sp自动递增，而bp保持不变。相应地，函数返回前都会有popq %rbp操做。

步骤二：简单分析 touch 事件在 Window 层的分发

点击“点我前Button”，很快触发了第一个hitTest:withEvent:的断点。先用bt命令查看当前调用栈，发现第 0 帧调用了UIAutoRotatingWindow的hitTest:withEvent:，打印寄存器数据获取到r14、r15都传递了UIWindow参数，但实际上调用该方法的是一个UITextEffectsWindow实例，UITextEffectsWindow是UIAutoRotatingWindow。它的内存地址是0x00007fa8ebe05050，显然不是 main window。

而r14传递的地址是0x00007fa8f10036b0，正是 main window。之因此是UITextEffectsWindow接收到hitTest:withEvent:是由于Window 层中的碰撞检测是使用上图中红色框中的私有方法进行处理。接下来一步步弄清红框中的碰撞检测处理的 touch 事件的传递具体经由哪些 Window 实例。frame select 8跳到第 8 帧，跟踪到了一个UIWindow对象0x7fa8f10036b0。所以，Window 层级中最早接收到 touch 事件的确实是 main window。

依次类推打印出全部栈帧的当前对象以下（有些层级到断点行时寄存器已经被修改，会找不到目标类型的实例，此时能够回到上一层打印须要传入下一层的全部寄存器的值便可）：

frame 0: UITextEffectsWindow 0x00007fa8ebe05050 frame 1: UITextEffectsWindow 0x00007fa8ebe05050 frame 2: UITextEffectsWindow 0x00007fa8ebe05050 frame 3: UIWindow +(类方法) frame 4: UIWindowScene -(nil不须要使用self) frame 5: UIWindowScene 0x00007fa8ebd06c50 frame 6: UIWindowScene 0x00007fa8ebd06c50 frame 7: UIWindow +(类方法) frame 8: UIWindow 0x00007fa8f10036b0

能够进一步使用 lldb 调试命令理清上面几个对象之间的关系。首先是图一中 window scene 与 window 之间的关系。图二则打印出了UITextEffectsWindow的视图层级。图三是 main window 的视图层级，注意到红框中的对象，是否似曾相识？没错，到这里追踪到 Controller 的TestEventsView类型的根 view。

图一：WindowScene与Window之间的关系

图二：UITextEffectsWindow的视图层级

图三：Main Window的视图层级

为何新版本 iOS 的 touch 事件传递过程，须要分离出 Window 层和 View 层阶段？是由于自 iOS 13 起引入UIWindowScene后，UITextEffectsWindow和 main window 有各自的视图层级，且二者都没有superview，所以必须修改 touch 的传递策略，让事件都能分发到两个 window 中。

注意：本来猜测，C 语言转化为汇编语言时，遵循声明一个局部变量就要分配一个栈空间的，调用函数时须要将形参和返回值地址推入堆栈，然而从调试过程当中查看 Objective-C 的汇编代码，其实现并非如此。因为现代处理器包含了大量的高效率存储器，所以 clang 编译时会最大限量地合理利用起这些寄存器（一般是通用寄存器）以提升程序执行效率。一般传递参数用到最多的是r12、r13、r14、r15寄存器，但毫不仅限于以上列举的几个。这给源代码调试增长了很大的难度。

步骤三：分析 Touch 事件的产生

注意这里的 touch 事件并非指 UIKit 的 touch event，UIKit 的 touch event 在 UIKit 接收到来自驱动层的点击事件信号后就构建了 touch 事件的UIEvent对象。这里的 touch 事件是指通过碰撞检测肯定了 touch event 的响应者从touchesBegan:withEvent:开始传递以前产生的UITouch对象。

一、如今正式开始追踪 touch 事件。已知，步骤二中打断的第一次hitTest:withEvent:命中，其调用对象是UITextEffectsWindow实例。此时点击调试工具栏中的“continue”按钮，继续执行。

注意：因为调试过程比较长，致使继续运行时 lldb 被打断须要从新运行。不过问题不大，由于前面的工做已经肯定了须要追踪的关键对象。所以从新运行后，从新下断点，再记录一次关键对象的地址便可。

开始收集断点命中（包括第一次命中）：

UITextEffectsWindow：（Hit-Test）
UITextEffectsWindow：（Hit-Test）（调用 UIView 的实现）
UIInputSetContainerView：（Hit-Test）
UIInputSetContainerView：（Hit-Test）（调用 UIView 的实现）
UIEditingOverlayGestureView：（Hit-Test）
UIEditingOverlayGestureView：（Hit-Test）（调用 UIView 的实现）
UIInputSetHostView：（Hit-Test）
UIInputSetHostView：（Hit-Test）（调用 UIView 的实现）
UIWindow：（Hit-Test）（调用 UIView 的实现）
UITransitionView：（Hit-Test）
UITransitionView：（Hit-Test）（调用 UIView 的实现）
UIDropShadowView：（Hit-Test）
UIDropShadowView：（Hit-Test）（调用 UIView 的实现）
TestEventsView：（Hit-Test）（调用 UIView 的实现）

至此 Hit-Test 断点命中了以前自定义的 Controller 的TestEventsView类型的根类，在这里打印一下调用栈。调用栈增长至 38 层以下图。并且上面的层次都是在调用hitTest:withEvents方法，这是个明显的递归调用的表现。并且到此为止，Hit-Test 仍然没有命中任何视图。

二、继续运行收集断点信息：

{TestEventsLabel: 0x7fd8d48071a0; baseClass = UILabel; frame = (121 162; 250 166); text = 'C'; opaque = NO; autoresize = RM+BM; layer = <_UILabelLayer: 0x600003399040>}：(Hit-Test）（调用超类的实现）
{TestEventsLabel: 0x7fd8d4806df0; baseClass = UILabel; frame = (82 116; 250 166); text = 'B'; opaque = NO; autoresize = RM+BM; layer = <_UILabelLayer: 0x600003398f50>}：(Hit-Test）（调用超类的实现）
{TestEventsLabel: 0x7fd8d4805aa0; baseClass = UILabel; frame = (44 75; 250 166); text = 'A'; opaque = NO; autoresize = RM+BM; layer = <_UILabelLayer: 0x600003398870>}：(Hit-Test）（调用超类的实现）
{TestEventsButton: 0x7fd8d48056c0; baseClass = UIButton; frame = (121 478; 173 79); opaque = NO; autoresize = RM+BM; layer = <CALayer: 0x6000010813e0>}：(Hit-Test）（调用 UIControl 的实现）

Hit-Test 断点终于命中了 Demo 的自定义 Label 和 Button 控件。根据收集的信息，命中顺序是 LabelC -> LabelB -> LabelA -> 点我前Button。此时，不急着继续，在调试窗口中使用bt指令，观察到调用栈深度已经来到了 43 层之多，以下图所示。可是注意到一点，以上每次断点命中，其调用栈深度都是 43 层，也就是说上面几个同层视图的碰撞检测过程是循环迭代，而不是递归，三个TestEventsLabel调用hitTest:withEvent:均可以直接返回nil不须要递归。

三、继续运行收集断点信息：

TestEventsButton：（Hit-Test）（调用 UIView 的实现）
UIButtonLabel：（Hit-Test）（调用超类的实现）

调用栈到达了第一个高峰 49 层，以下图一所示。此时若点击继续，会发现调用栈回落到 13 层，以下图二所示。说明 Hit-Test 断点在命中UIButtonLabel后，本次 Hit-Test 递归就返回了。至于具体返回什么对象，实际上在 1.2.2 的调试日志中已经打印出来了，正是“点我前Button”。

图一：Hit-Test调用栈到达顶峰

图二：Hit-Test调用栈回落

四、继续运行，Demo 会进入第二次 Hit-Test 递归，之因此一次点击事件引起了两轮递归，是由于 touch 事件在开始和结束时，各进行了一轮碰撞检测。继续收集断点信息：

UIWindow：（Hit-Test）（调用 UIView 的实现）
UITransitionView：（Hit-Test）
UITransitionView：（Hit-Test）（调用 UIView 的实现）
UIDropShadowView：（Hit-Test）
UIDropShadowView：（Hit-Test）（调用 UIView 的实现）
TestEventsView：（Hit-Test）（调用 UIView 的实现）
TestEventsLabel：（Hit-Test）（调用 UIView 的实现）
TestEventsLabel：（Hit-Test）（调用 UIView 的实现）
TestEventsLabel：（Hit-Test）（调用 UIView 的实现）
TestEventsButton：（Hit-Test）（调用 UIControl 的实现）
TestEventsButton：（Hit-Test）（调用 UIView 的实现）
UIButtonLabel：（Hit-Test）（调用 UIView 的实现）

调用栈再次到达了高峰 41 层以下图所示。

此时先不急着继续。由于以上是 Hit-Test 在本次调试中的最后一次断点命中，点击继续 Hit-Test 递归必然返回“点我前Button”，表示碰撞检测命中了该按钮控件。第二轮 Hit-Test 的调用栈明显浅许多，不难发现其缘由是该轮碰撞检测没有通过UITextEffectsWindow而直接从UIWindow开始（个中缘由不太肯定）。

总结 Hit-Test 的处理过程的要点是：

优先检测本身是否命中，不命中则直接忽略全部 subviews；
若本身命中，则对全部子视图按同层级视图顺序从前向后的顺序依次进行碰撞检测，所以碰撞检测也是 superview 到 subview 的按视图层级从后向前递归的过程；
若全部子视图均未命中，本身的碰撞检测才返回 nil。

文字表述彷佛有点不太直观，仍是用我们程序员的语言吧，伪代码以下：

- (UIView * _Nullable)hitTest:(CGPoint)point withEvent:(UIEvent *)event{
    // 1. 优先检测本身，不命中则马上排除
    BOOL isHit = [self pointInside:point withEvent:event];
    if(!isHit){
        return nil;
    }

    // 2. 从前向后循环迭代全部子视图
    for(UIView* subviews in subviews){
        // 跨视图层级从 superview 向 subview 递归
        UIView* hitView = [subviews hitTest:point withEvent:event];
        if(hitView)
            return hitView;
    }
    
    // 3. 全部子视图未命中返回nil
    return nil;
}
复制代码

步骤四：分析 touch 事件开始后的传递

状况一：点击 Button 控件时

步骤三执行完成，UIKit 产生了UITouch事件并开始传递该事件。紧接在以前的基础上继续调试。再点击 continue，收集断点信息：

_UISystemGestureGateGestureRecognizer：（Touches-Began）
_UISystemGestureGateGestureRecognizer：（Touches-Began）
TestEventsButton：（Touches-Began）（调用 UIControl 的实现）

此时 Button 尝试触发 touchesBegan，开始UITouch事件传递。调用栈以下，是由 UIWindow 发送过来的 touch 事件。注意上面TestEventsButton调用的是UIControl 的实现，记住这个“猫腻”，后面的部分会再次提到。

TestEventsButton：（Next-Responder）（调用 UIView 的实现）

终于命中了 Next-Responder 断点，从上下两个调用栈能够发现，nextResponder是在touchBegan方法内调用的。

再点击 continue，继续运行收集断点信息：

TestEventsView：（Next-Responder）（调用 UIView 的实现）

nextResponder是在touchBegan方法内调用的，且增长了调用栈深度，说明nextResponder也触发了递归的过程。可是递归的不是nextResponder而是UIResponder里面的一个私有方法_controlTouchBegan:withEvent:。该方法彷佛只简单遍历了一轮响应链，其余的什么都没作。

再点击 continue，继续运行收集断点信息：

UIViewController：（Next-Responder）（调用 UIViewController 的实现）
UIDropShadowView：（Next-Responder）（调用 UIView 的实现）
UITransitionView：（Next-Responder）（调用 UIView 的实现）
UIWindow：（Next-Responder）
UIWindowScene：（Next-Responder）（调用 UIScene 的实现）
UIApplication：（Next-Responder）
AppDelegate：（Next-Responder）（调用 UIResponder 的实现）

在AppDelegate层，调用栈达到顶峰，以下图所示。

在调试过程当中，发现响应链上除了第一响应者“点我前Button”外的全部对象都没有调用touchesBegan:withEvent:响应该 touch 事件。那么这就是对 touch 事件该有的处理么？其实否则，因为调试时点击的是 Button 控件，所以上述是对UIControl控件做为第一响应者的状况的，经过定制UIControl类touchesBegan:withEvent:方法实现的，特殊处理。上面提到的私有方法_controlTouchBegan:withEvent:就是为了告诉后面响应链后面的响应者这个 touch 事件已经被前面的 UIControl 处理了，请您不要处理该事件。

那么UIResponder原始的响应流程是怎样的呢？继续调试状况二。

状况二：点击 Label 视图

流程渐渐明朗的状况下，能够先breakpoint disable终止上面的断点，而后breakpoint delete XXX删除掉hitTest:withEvent:断点，以减小打断次数。解屏蔽掉以前屏蔽的打印日志的代码，由于当断点命中 Demo 中的自定义类时，能够直接判定nextResponder的触发类。

点击界面中的 Label C。开始收集信息（省略自定义日志打印方法只保留原始方法）：

_UISystemGestureGateGestureRecognizer：（Touches-Began）
_UISystemGestureGateGestureRecognizer：（Touches-Began）
TestEventsLabel：（Touches-Began）（调用 UIResponder 的实现）
TestEventsLabel：（Next-Responder）（调用 UIView 的实现）
TestEventsView：（Touch-Began）（调用 UIResponder 的实现）
TestEventsView：（Next-Responder）（调用 UIView 的实现）
UIViewController：（Touch-Began）（调用 UIResponder 的实现）
UIViewController：（Next-Responder）（调用 UIViewController 的实现）
UIDropShadowView：（Touch-Began）（调用 UIResponder 的实现）
UIDropShadowView：（Next-Responder）（调用 UIView 的实现）
UITransitionView：（Touch-Began）（调用 UIResponder 的实现）
UITransitionView：（Next-Responder）（调用 UIView 的实现）
UIWindow：（Touch-Began）（调用 UIResponder 的实现）
UIWindow：（Next-Responder）
UIWindowScene：（Touch-Began）（调用 UIResponder 的实现）
UIWindowScene：（Next-Responder）（调用 UIScene 的实现）
UIApplication：（Touch-Began）（调用 UIResponder 的实现）
UIApplication：（Next-Responder）
AppDelegate：（Touch-Began）（调用 UIResponder 的实现）
AppDelegate：（Next-Responder）（调用 UIResponder 的实现）

至此先看一下调用栈，显然touchesBegan:withEvent:也是递归的过程：

总结上面收集的信息，UIResponder做为第一响应者和UIControl做为第一响应者的区别已经至关明显了。当UIResponder做为第一响应者时，是沿着响应链传递，通过的每一个对象都会触发touchesBegan:withEvents:方法。

步骤五：分析 touch 事件结束后的传递

Touch 事件事件结束会触发第一响应者的touchesEnded:withEvent:方法，具体传递过程和步骤四中一致。一样要区分UIControl和UIResponder的处理。

最后，不管是UIControl仍是UIResponder，在完成全部touchesEnded:withEvent:处理后，都要额外再从第一响应者开始遍历一次响应链。从调用栈能够看到是为了传递UIResponder的_completeForwardingTouches:phase:event消息。具体缘由不太清楚。

3、RunLoop与事件（TODO）

行文至此，文章篇幅已经有点长，所以在下一篇文章中在调试这部份内容。

4、总结

不管是使用UIControl的 Target-Action 方式仍是UIResponder的touchesXXX方式处理用户事件，都涉及到 Hit-Test 和响应链的内容；
UIControl使用 Target-Action 注册用户事件，当后面的控件被前面的控件覆盖时，若用户事件（UIEvent）被前面的控件拦截（不管前面的控件有没有注册 Target-Action），则后面的控件永远得不处处理事件的机会，即便前面的控件未注册 Target-Action；
UIControl使用 Target-Action 注册用户事件，指定 Target 为空时，Action 消息会沿着响应链传递，直到找到能响应 Action 的 Responder 为止，Action 一旦被其中一个 Responder 响应，响应链后面的对象就再也不处理该 Action 消息；
响应链是以 View 为起始，向 superview 延伸的一个反向树型结构，经过UIResponder的nextResponder串联而成；
当 View 做为 Controller 的根 view 时，nextResponder是 Controller；
当 Controller 是由其余 Controller present 而来，则nextResponder是其 present controller；
当 Controller 是 Window 的根 Controller，则nextResponder是 Window，注意调试中 Controller 的nextResponder是返回nil，但实际上它们确实有这层关系；
Window 的nextResponder是 Window Scene；
Window Scene 的nextResponder是 Application；
Application 的nextResponder是 AppDelegate（当 AppDelegate 是UIResponder类型时）；
Hit-Test 优先检测本身是否命中，不命中则直接忽略全部 subviews；
Hit-Test 若本身命中，则对全部子视图按同层级视图顺序从前向后的顺序依次进行碰撞检测，所以碰撞检测也是 superview 到 subview 的按视图层级从后向前递归的过程；
Hit-Test 若未命中任何子视图，本身的碰撞检测才返回 nil；
Hit-Test 命中目标后，产生UITouch事件，UITouch事件会沿着响应链传递到后面的全部响应者；
UIResponder做为第一响应者响应了 touch 事件，响应链后面的全部响应者也会触发touchesXXX系列方法；
UIControl控件做为第一响应者响应了 touch 事件，响应链后面的全部响应者均再也不处理该 touch 事件；