IOS视图继承关系和事件响应链

UIView：UIView->UIResponder->NSObject

UIViewController：UIViewController->UIResponder->NSObject

UIWindow：UIWindow->UIView

UIButton/UISwitch/UITextField：UIButton/UISwitch/UITextField->UIControl->UIView

UILabel：UILabel->UIView

CALayer：CALayer->NSObject

UIWindow算是一种特殊的View，他默认在视图最顶端，有自己的一套优先级。可以创建多个，控制显示级别。

CALayer和UIView是相互依赖的，继承于UIView的都有layer这个属性，CALayer用于渲染视图，绘制具体的像素。UIView只是提供一个容器。真正绘制内容的是CALayer。UIView的主layer以外，对它的subLayer，也就是子layer的属性进行更改，系统将自动进行动画生成。

从上面的继承关系可以看出，继承于UIResponder的才有用户点击事件。

UIControl是控件类的基类，它是一个抽象基类，我们不能直接使用UIControl类来实例化控件，它只是为控件子类定义一些通用的接口，并提供一些基础实现，以在事件发生时，预处理这些消息并将它们发送到指定目标对象上。他是将UIResponder中的复杂触摸事件封装成了简单事件。

NSObject是所有控件的基类。

UIView内部分三个树：

第一份，逻辑树，就是代码里可以操纵的，例如更改layer的属性等等就在这一份。

第二份，动画树，这是一个中间层，系统正在这一层上更改属性，进行各种渲染操作。

第三份，显示树，这棵树的内容是当前正被显示在屏幕上的内容。

这三棵树的逻辑结构都是一样的，区别只有各自的属性。

说一下事件响应链。

具体的事件响应方式就不介绍了，几种手势那种。

用户点击屏幕以后我们可以通过hitTest:withEvent:来获取点击的点和view。

在iOS中不是任何对象都能处理事件，只有继承了UIResponder的对象才能接受并处理事件，我们称之为“响应者对象”。这个上面已经讲过了。

假设现在有个页面，VC->View(两个子视图-BView,DView)->BView(子视图CView)

这时候用户点击了CView，响应链：

用户触摸->产生触摸事件->UIApplication事件队列->UIWindow->UIView->AView->DView->BView->CView

也就是说，当用户产生触摸事件以后，系统会先去查找application，然后交给window，如果接收不了会继续遍历VC中的View，这个时候是优先subView中的最后一个，也就是视图最顶端，如果找不到继续遍历View的子视图，同样的方式，优先遍历subView中最后一个。直到找到响应者。

注意：

这里有这样一个方法，- (nullable UIResponder *)nextResponder，获取当前view的下一个响应者，但是有前辈已经发现这个方法查找出来的响应链是错误的，因为他查找到的是所有response，包括VC。但是很明显VC并不应该是用户事件的响应者。如果通过这个方法来查找下一个响应视图得到的结果是错误的。

然后查阅View里面的方法，大概猜到这才应该是获取到当前响应事件的下一个响应者View。

- (nullable UIView *)hitTest:(CGPoint)point withEvent:(nullable UIEvent *)event;

- (BOOL)pointInside:(CGPoint)point withEvent:(nullable UIEvent *)event;

然后通过runtime替换着两个方法，果然获取到的响应链变了，具体的就是上面的图片所示。