Responder、run loop、Application、window

事件的传递

流程图

所谓responder ,就是 可以响应(处理)事件的物件。
在一堆可以处理事件的物件中，最后被分派到，把事件处理掉的物件，叫做 first responder，而这种一环一环寻找responder处理事件的锁链，叫做 Responder Chain。这个流程会在runloop中不断循环。

Run loop

• 在iOS与Mac OX S平台，在一个GUI程序开始执行之后，就会执行一个loop，直到用户关闭这个程序的时候，才会关闭这个loop；这个loop所做的，就是 收取与分派事件。

• 每一轮runloop的时间并不固定，与这一轮runloop里做了多少事情相关。

• Timer 也是依靠run loop运作的。当我们建立一个Timer后，下一步就是把timer物件注册到run loop中。在每一轮runloop里，会检查是否已经到了某个timer指定是时间，如果到了就执行timer指定的selector。

  • 由于每一轮runloop的时间不一定，timer不会精确执行。
  • 我们不能建立比 run loop 频率更频繁的 timer。

• runloop 会管理auto-release物件，如果有些对象只有在这一轮run loop中有用，之后就应该释放，我们可以把对象添加到 auto-release pool中。

• 除了mainthread会执行最主要的run loop，每个thread/operation都有属于自己的runloop。

程序的进入点在哪？

int main(int argc, char * argv[]) {
    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
    }
}```
在进入`-application: application didFinishLaunchingWithOptions: ` 之前会：
1. 建立 `auto-release pool`
2. 呼叫 `UIApplicationMain`
3. 建立 `UIApplication` 这个singleton 对象
4. 开始执行 run loop之外，每个thread/opration里面，会有有属于各自的run loop。
5. 这些步骤完毕后，表示app已经开始执行，所以
6. 对 UIApplication 的 delegate 呼叫`-application: application didFinishLaunchingWithOptions: ` 

#### Application
由于 application 位于 `Responder Chain` 的最底层，每一个view、windows都不处理的时候，就会交给application处理，所以一些会影响整个app行为的事件适合由applicartion这一层处理。

#### Window
Application 在收到触控等硬件时间之后，会把事件转发给 key window。用来接收键盘以及非触摸类的消息事件的UIWindow，而且程序中每个时刻只能有一个UIWindow是keyWindow。

#### View
window将事件传到view上，view通过 `-hitTest: withEvent: `(图一)，找到该处理事件的subview。
`-hitTest: withEvent: ` 不仅会问触控事件的坐标是否在某个 subview 里，也会问这个这个subview是否会处理事件。
可以改写 `-hitTest: withEvent: ` 回传你想要 **做出反应** 的view。

#### ViewController
View Controller 本事也是个 Responder，因此也实现了 UIResponder Protocol。如果发生触控事件，view controller 的 view 不处理，那么就要view controller本身来处理。