iOS事件传递和响应
背景
对于身处中小公司且业务不怎么复杂的程序员来说，很多技术不常用，你可能看过很多遍也都大致了解，但是实际让你讲，不一定讲的清楚。你可能说，我以独当一面，应对自如了，但是技术的知识甚多，我们常用的只是十之一二，甚至更少。这么多知识，怎么更好的理解和学习？如果实操的场景少，推荐通过AI对话，不断的提问，然后对他的回答进行反复的验证校准，加深理解。
今天就住要讲一下iOS的事件传递和响应
事件传递和响应
1、概述
事件传递过程：从application传递到最上层view，如下图
事件响应处理过程：从最上层view开始向下传递，与事件传递方向相反（响应链）
2、事件传递细节
当用户点击页面的某个位置时，application将触发事件传递
- 从application到window，到ViewController，到view、subview
- 如果某个view可以处理这个事件，则继续查找其子view，查找子view的时候从最后添加的开始检查，一旦某个子view可以处理这个事件则停止遍历，子view重复此过程。如果子view都不可处理事件则返回自己，事件查找结束。
什么条件算是“可以处理这个事件”，需要同时满足以下条件
-
view没有隐藏，hidden ＝ NO
-
允许交互，userInteractionEnabled = YES
-
透明度alpha > 0.01，注意等于0.01的时候就已经无法响应事件了
-
pointInside: withEvent:返回YES，也就是说view覆盖区域包含点击位置。也可以重写函数，指定一定范围内的点击都算到自己身上（常用于扩大按钮的点击范围）。
事件传递结束后，这个事件的响应链就定下来了，响应链之外的view就没有机会处理事件了，即使他可以处理也不行。这里解释一下，根据前面提到的传递规则，对于同一个view的子view，最后添加的拥有绝对的优先权，如果他能处理这个事件，则即时他不处理这个事件，他的兄弟view也么有机会处理。
3、事件响应
事件传递结束，响应链被确认，则进行事件响应阶段
从最后的view开始确认是否处理了事件，如果处理了，则停止向下传递，过程结束
首先，根据处理方式的不同，可分为3种：
- UIControl，如按钮通过 target-action 机制直接将事件传递给控件
- 手势识别器，给view添加gestureRecognizer系列识别，绑定事件回调
- 触摸事件链，通过view的
touchesBegan、touchesEnded来拦截处理的自带事件
每种处理方式有各自的传递链条，不会串行，其中
- UIControl，如果在最上层且“可以处理这个事件”，则父视图的其他方式（touche\gesture）会被阻断。应该他的内部实现上，将touche和gesture都阻断了。
- 手势识别器（gestureRecognizer），如果子view添加了手势，则点击子view的时候，父view还会收到
touchesBegan、touchesEnded的回调，也就是说touche和gesture会同时触发。如果父子view同时设置了手势（比如都是tapGesture）,则子view会阻断手势事件的传递，父view不会收到点击事件。 - 触摸事件链，如果想中断，则在
touchesBegan中不调用super即可中断。如果不想中断，则实现touchesBegan处理事件的同时，可继续调用super，响应链的其他元素就还有机会收到事件和处理事件。
以上就是我对事件传递和响应的理解，其重点就是明白传递过程，传递的条件，响应链
那些容易让误解的词语
1、很多文章提到传递方向“从上到下”、“从下到上”，这样子讲，并不知道到底从哪到哪传递。本文结合了图片层级做了说明，希望大家能够明白。
2、查找响应者的过程，很多文章提到“如果view不能处理事件”则...，这种说法我是不赞同的，如果view不能处理事件，那根本就不会传给他，更别提进入响应链了。这里适合的词应该是“不处理”，或者更恰当点理解是“不拦截”。我们都知道，通过touchesBegan处理事件的时候，如果你调用了super方法，事件还会继续传递，这时候就可以有多个view同时响应事件