iOS 程序之事件处理流程

26 Sep 2011

因为交互的要求，跑在 ipad 上的程序必须以横版且仅以横版的模式运行。按说这应该是比较简单的事情：在 plist 或者工程设置中设一下程序起始方向和所支持的方向(Landscape)。但是却出了如下的问题：

在 UIWindow 中添加了两个 ViewController，并显示后一个 ViewController 的视图，结果视图并没有被旋转成横版，仍旧按照竖版来显示。Google 和 StackOverFlow 了一把，发现很多人都碰到过类似的问题，比如 这个 和这个 。当然也有人给出了解决方案：给 UIWindow 设置一个 rootViewController，尔后添加的所有 ViewController 都以 rootViewController 的 subview 形式添加。就连苹果官方的的 Q&A 也推荐这种做法： 《Why won’t my UIViewController rotate with the device?》至于原因，官方的 Q&A 讲的很简单：如果往一个 UIWindow 里面添加了两个以上的 view，那么后面添加的 view 就会收不到旋转的事件，于是无法正常调整视图的方向 —– 只有第一个加入到 UIWindow 的 view 才会进行旋转。

按说问题到这里就解决了，将后面的 view 以 rootViewController 的 subview 形式进行添加就可以了。但是 Why？为什么第一个添加的 ViewController 这么特殊，它可以收到旋转消息而后面的都不会呢。在苹果官方文档搜了一遍，终于在 事件处理流程的文档 中找到了原因。(吐槽下：苹果的文档比 MSDN 要详尽多了，各种细节都包含在内，同样是封闭系统，差距怎么这么大呢…)

事件类型

在 iOS 系统中，一共有三种形式的事件：触摸事件 (Touch Event)，运动事件(Motion Event) 和远端控制事件(Remote-control Event)。顾名思义，触摸事件就是当用户触摸屏幕时发生的事件，而运动事件是用户移动设备时发生的事件：加速计，重力感应。远端控制事件可能比较陌生：如通过耳机进行控制 iOS 设备声音等都属于远端控制事件—- 下面不展开说，因为和主题无关，详细的内容可以参考： 《Remote Control of Multimedia》 。

事件分发

在 iOS 系统中有个很重要的概念：Responder。基本上所有的 UI 相关的控件，view 和 viewcontroller 都是继承自 UIResponder。事件的分发正是通过由控件树所构成的 responder chain(响应链)所进行的。一个典型的 iOS 响应链如下：

当用户发起一个事件，比如触摸屏幕或者晃动设备，系统产生一个事件，同时投递给 UIApplication，而 UIApplication 则将这个事件传递给特定的 UIWindow 进行处理 (正常情况都一个程序都只有一个 UIWindow)，然后由 UIWindow 将这个事件传递给特定的对象(即 first responder) 并通过响应链进行处理。虽然都是通过响应链对事件进行处理，但是触摸事件和运动事件在处理上有着明显的不同(主要体现在确定哪个对象才是他们的 first responder)：

触摸事件是通过 HitTest 来确定 first responder(整个过程和 Windows 中对消息的处理基本是一样的)：当一个事件发生时，UIWindow 将这个事件传递给当前可见的最顶端的 view 进行 hitTest，并在这个 hitTest 里面进行递归查找，直到找到能够响应 hitTest 的最底层的那个 Responder，确定为 first responder。然后从这个 responder 开始进行处理这个事件，如果不能处理，则往上冒泡直到有一个 Responder 可以对这个事件进行处理为止。但是运动事件却不太一样，它并不用进行 HitTest，而是直接以响应链中被指定为 first responder 的对象为起点，通过响应链进行事件的分发和处理。第一个加入到 UIWindow 中的 ViewController 即是运动事件的 first responder。这也就解释了为啥后加入的 view 不会被正常的旋转：虽然都是通过 first responder 开始分发事件，但是一个有进行 hittest，一个没有，虽然大多数情况下 hittest view 和 first responder 是同一个 view，但也不绝对。正如旋转的这个例子一样。