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替换着两个方法，果然获取到的响应链变了，具体的就是上面的图片所示。
