A variety of operational events are encountered in iOS development and can be responded to by programs.
First, when an event response occurs, you must know who is responding to the event. In iOS, the responder chain responds to events, all event-response classes are uiresponder subclasses, and the responder chain is a hierarchy of different objects, each of which gets an opportunity to respond to event messages in turn. When an event occurs, the event is first sent to the first responder, and the first responder is often the view of the event, which is where the user touches the screen. Events are passed along the responder chain until they are accepted and processed. In general, the first responder is a view object or its subclass object, and when it is touched the event is handled by it, and if it is not handled, the event is passed to its View controller object Viewcontroller (if present), Then it's the parent view (Superview) object (if it exists), and so on, until the top-level view. The next step is to follow the top view to the window (UIWindow object) and then to the program (the UIApplication object). If the entire process does not respond to this event, the event is discarded. In general, the event stops passing in the responder chain as long as the object handles the event.
A typical corresponding road map is as follows:
Responser--> The Window-->the application--> App Delegate
A normal responder chain process is often interrupted by a delegate (delegation), and an object (usually a view) may delegate response work to another object (usually the view controller Viewcontroller), This is why an event response must be implemented in Viewcontroller to implement an event delegate. In iOS, there is a Uiresponder class that defines all the methods of the responder object. Classes such as UIApplication and UIView inherit the Uiresponder class, and the controls in UIWindow and Uikit inherit UIView classes indirectly, so that instances of those classes can be used as responders.