制作UIViewController子类的目的是UIResponder什么？仅仅是为了通过轮换事件吗？
我在文档中找不到任何明确的信息。
我知道，如果某些东西被做成 a UIResponder，那么这个东西应该被包含在响应者链和处理事件中。但我有两个令人痛心的疑虑。
UIViewController在它的view. 为什么我们在响应者链中需要一个视图控制器？它view已经存在了，那么为什么我们不让视图处理其子视图未处理的事件呢？I think your problem may simply be a failure of object oriented thinking.
Per the docs:
The responder chain is a linked series of responder objects to which an event or action message is applied.
In UIKit the view controller sits in the responder chain between its view and the view to which the controller was pushed. So it is offered any event or action that its views don't handle.
The topmost view controller's next responder is the window, the window's next responder is the application, the application's next responder is the application delegate and the application delegate is where the buck stops.
Your question "Was it done solely to pass the rotation events?" applies the incorrect test; it implies that at some point the responder chain had otherwise been fully engineered and somebody thought 'oh, wait, what about rotation? Better chuck the view controllers into the chain'.
The original question will have been: is it helpful if events or actions can be handled by the view controller if none of the views handle them? The answer should obviously be 'yes' as — even on a touch-screen device — there will be events or actions that aren't inherently related to a view.
The most obvious examples are those related to physical inputs other than the screen. So device rotation is one. Key presses on a bluetooth keyboard are another. Remote controls are a third. The accelerometer is a fourth.
The next most obvious example is any system-generated events or actions that should go to the single most local actor rather than to everyone. In iOS that's generally requests for a more specific actor, like the most local undo manager or the identity of the input view to show if focus comes to you.
A slightly less obvious example is that exemplified by UIMenuController — a pop-up view that posts a user-input event that may need to traverse several view controllers to get to the one that should act on it. iOS 5's child view controllers increase the number of possibilities here enormously; quite often you're going to have one parent view controller with the logic to do a bunch of things and children that want to pass messages up to whomever knows how to handle them, without hard coding the hierarchy.
So, no, view controllers weren't added to to the responder chain just to handle rotation events. They were added because logically they belong to be there based on the initial definition of the responder chain.
这听起来像是一个油嘴滑舌的答案，但实际上并非如此。UIViewController是UIResponderso that 的子类，可以响应用户动作（例如触摸、动作等）。
如果视图没有响应事件，它会向上传递到响应者链，从而为更高级别的对象提供处理它的机会。因此，视图控制器和应用程序类都是UIResponder
您可以在 Apple 开发者网站上的Cocoa Application Competencies for iOS: Responder Object中找到有关响应者链的更多详细信息。
UIViewController 在响应者链中允许它处理任何事件。除了您想到的（触摸）事件之外，还有更多通过此链的事件。运动事件通过链传递，特定视图无法处理的触摸事件，您还可以使用[UIApplication sendEvent:...]nil 目标强制通过响应链。
您可能注意到的另一件事是 UIApplication 也是 UIResponder 的子类。所有未处理的事件都将在那里结束。
In MVC conception handling of event occurred in view should perform controller.
There is a feature, to set "nil" to "target" parameter of -[UIControl addTarget:action:forControlEvents:] in with case the responder chain is searched for an object willing to respond to the action.
That is, because of search option, UIViewController is subclass of UIResponder.
So, you can send your custom control events in same manner to get benefits of "search" option.