iOS程序之事件处理流程

因为交互的要求,跑在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,但也不绝对。正如旋转的这个例子一样。