ios学习之UIKit框架（1）－－UIResponder

转载自  http://www.tuicool.com/articles/E3UBJj3

咱们的App与用户进行交互，基本上是依赖于各类各样的事件。例如，用户点击界面上的按钮，咱们须要触发一个按钮点击事件，并进行相应的处理，以给用户一个响应。UIView的三大职责之一就是处理事件，一个视图是一个事件响应者，能够处理点击等事件，而这些事件就是在UIResponder类中定义的。

一个UIResponder类为那些须要响应并处理事件的对象定义了一组接口。这些事件主要分为两类：触摸事件(touch events)和运动事件(motion events)。UIResponder类为每两类事件都定义了一组接口，这个咱们将在下面详细描述。

在UIKit中，UIApplication、UIView、UIViewController这几个类都是直接继承自UIResponder类。另外SpriteKit中的SKNode也是继承自UIResponder类。所以UIKit中的视图、控件、视图控制器，以及咱们自定义的视图及视图控制器都有响应事件的能力。这些对象一般被称为响应对象，或者是响应者(如下咱们统一使用响应者)。

本文将详细介绍一个UIResponder类提供的基本功能。不过在此以前，咱们先来了解一下事件响应链机制。

响应链

大多数事件的分发都是依赖响应链的。响应链是由一系列连接在一块儿的响应者组成的。通常状况下，一条响应链开始于第一响应者，结束于application对象。若是一个响应者不能处理事件，则会将事件沿着响应链传到下一响应者。

那这里就会有三个问题：

1. 响应链是什么时候构建的

2. 系统是如何肯定第一响应者的

3. 肯定第一响应者后，系统又是按照什么样的顺序来传递事件的

构建响应链

咱们都知道在一个App中，全部视图是按必定的结构组织起来的，即树状层次结构。除了根视图外，每一个视图都有一个父视图；而每一个视图均可以有0个或多个子视图。而在这个树状结构构建的同时，也构建了一条条的事件响应链。

肯定第一响应者

当用户触发某一事件(触摸事件或运动事件)后，UIKit会建立一个事件对象(UIEvent)，该对象包含一些处理事件所须要的信息。而后事件对象被放到一个事件队列中。这些事件按照先进先出的顺序来处理。当处理事件时，程序的UIApplication对象会从队列头部取出一个事件对象，将其分发出去。一般首先是将事件分发给程序的主window对象，对于触摸事件来说，window对象会首先尝试将事件分发给触摸事件发生的那个视图上。这一视图一般被称为hit-test视图，而查找这一视图的过程就叫作hit-testing。

系统使用hit-testing来找到触摸下的视图，它检测一个触摸事件是否发生在相应视图对象的边界以内(即视图的frame属性，这也是为何子视图若是在父视图的frame以外时，是没法响应事件的)。若是在，则会递归检测其全部的子视图。包含触摸点的视图层次架构中最底层的视图就是hit-test视图。在检测出hit-test视图后，系统就将事件发送给这个视图来进行处理。

咱们经过一个示例来演示hit-testing的过程。图1是一个视图层次结构，

假设用户点击了视图E，系统按照如下顺序来查找hit-test视图：

1. 点击事件发生在视图A的边界内，因此检测子视图B和C；

2. 点击事件不在视图B的边界内，但在视图C的边界范围内，因此检测子图片D和E；

3. 点击事件不在视图D的边界内，但在视图E的边界范围内；

视图E是包含触摸点的视图层次架构中最底层的视图(倒树结构)，因此它就是hit-test视图。

hit-test视图能够最早去处理触摸事件，若是hit-test视图不能处理事件，则事件会沿着响应链往上传递，直到找到能处理它的视图。

事件传递

最有机会处理事件的对象是hit-test视图或第一响应者。若是这二者都不能处理事件，UIKit就会将事件传递到响应链中的下一个响应者。每个响应者肯定其是否要处理事件或者是经过nextResponder方法将其传递给下一个响应者。这一过程一直持续到找到能处理事件的响应者对象或者最终没有找到响应者。

图2演示了这样一个事件传递的流程，

当系统检测到一个事件时，将其传递给初始对象，这个对象一般是一个视图。而后，会按如下路径来处理事件(咱们以左图为例)：

1. 初始视图(initial view)尝试处理事件。若是它不能处理事件，则将事件传递给其父视图。

2. 初始视图的父视图(superview)尝试处理事件。若是这个父视图还不能处理事件，则继续将视图传递给上层视图。

3. 上层视图(topmost view)会尝试处理事件。若是这个上层视图仍是不能处理事件，则将事件传递给视图所在的视图控制器。

4. 视图控制器会尝试处理事件。若是这个视图控制器不能处理事件，则将事件传递给窗口(window)对象。

5. 窗口(window)对象尝试处理事件。若是不能处理，则将事件传递给单例app对象。

6. 若是app对象不能处理事件，则丢弃这个事件。

从上面能够看到，视图、视图控制器、窗口对象和app对象都能处理事件。另外须要注意的是，手势也会影响到事件的传递。

以上即是响应链的一些基本知识。有了这些知识，咱们即可以来看看UIResponder提供给咱们的一些方法了。

管理响应链

UIResponder提供了几个方法来管理响应链，包括让响应对象成为第一响应者、放弃第一响应者、检测是不是第一响应者以及传递事件到下一响应者的方法，咱们分别来介绍一下。

上面提到在响应链中负责传递事件的方法是nextResponder，其声明以下：

- (UIResponder *)nextResponder

UIResponder类并不自动保存或设置下一个响应者，该方法的默认实现是返回nil。子类的实现必须重写这个方法来设置下一响应者。UIView的实现是返回管理它的UIViewController对象(若是它有)或者其父视图。而UIViewController的实现是返回它的视图的父视图；UIWindow的实现是返回app对象；而UIApplication的实现是返回nil。因此，响应链是在构建视图层次结构时生成的。

一个响应对象能够成为第一响应者，也能够放弃第一响应者。为此，UIResponder提供了一系列方法，咱们分别来介绍一下。

若是想断定一个响应对象是不是第一响应者，则可使用如下方法：

- (BOOL)isFirstResponder

若是咱们但愿将一个响应对象做为第一响应者，则可使用如下方法：

- (BOOL)becomeFirstResponder

若是对象成为第一响应者，则返回YES；不然返回NO。默认实现是返回YES。子类能够重写这个方法来更新状态，或者来执行一些其它的行为。

一个响应对象只有在当前响应者能放弃第一响应者状态(canResignFirstResponder)且自身能成为第一响应者(canBecomeFirstResponder)时才会成为第一响应者。

这个方法相信你们用得比较多，特别是在但愿UITextField获取焦点时。另外须要注意的是只有当视图是视图层次结构的一部分时才调用这个方法。若是视图的window属性不为空时，视图才在一个视图层次结构中；若是该属性为nil，则视图不在任何层次结构中。

上面提到一个响应对象成为第一响应者的一个前提是它能够成为第一响应者，咱们可使用canBecomeFirstResponder方法来检测，

- (BOOL)canBecomeFirstResponder

须要注意的是咱们不能向一个不在视图层次结构中的视图发送这个消息，其结果是未定义的。

与上面两个方法相对应的是响应者放弃第一响应者的方法，其定义以下：

- (BOOL)resignFirstResponder- (BOOL)canResignFirstResponder

resignFirstResponder默认也是返回YES。须要注意的是，若是子类要重写这个方法，则在咱们的代码中必须调用super的实现。

canResignFirstResponder默认也是返回YES。不过有些状况下可能须要返回NO，如一个输入框在输入过程当中可能须要让这个方法返回NO，以确保在编辑过程当中能始终保证是第一响应者。

管理输入视图

所谓的输入视图，是指当对象为第一响应者时，显示另一个视图用来处理当前对象的信息输入，如UITextView和UITextField两个对象，在其成为第一响应者是，会显示一个系统键盘，用来输入信息。这个系统键盘就是输入视图。输入视图有两种，一个是inputView，另外一个是inputAccessoryView。这二者如图3所示：

与inputView相关的属性有以下两个，

@property(nonatomic, readonly, retain) UIView *inputView@property(nonatomic, readonly, retain) UIInputViewController *inputViewController

这两个属性提供一个视图(或视图控制器)用于替代为UITextField和UITextView弹出的系统键盘。咱们能够在子类中将这两个属性从新定义为读写属性来设置这个属性。若是咱们须要本身写一个键盘的，如为输入框定义一个用于输入***的键盘(只包含0-9和X)，则可使用这两个属性来获取这个键盘。

与inputView相似，inputAccessoryView也有两个相关的属性：

@property(nonatomic, readonly, retain) UIView *inputAccessoryView@property(nonatomic, readonly, retain) UIInputViewController *inputAccessoryViewController

设置方法与前面相同，都是在子类中从新定义为可读写属性，以设置这个属性。

另外，UIResponder还提供了如下方法，在对象是第一响应者时更新输入和访问视图，

- (void)reloadInputViews

调用这个方法时，视图会当即被替换，即不会有动画之类的过渡。若是当前对象不是第一响应者，则该方法是无效的。

响应触摸事件

UIResponder提供了以下四个你们都很是熟悉的方法来响应触摸事件：

// 当一个或多个手指触摸到一个视图或窗口- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event// 当与事件相关的一个或多个手指在视图或窗口上移动时- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event// 当一个或多个手指从视图或窗口上抬起时- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event// 当一个系统事件取消一个触摸事件时- (void)touchesCancelled:(NSSet *)touches withEvent:(UIEvent *)event

这四个方法默认都是什么都不作。不过，UIKit中UIResponder的子类，尤为是UIView，这几个方法的实现都会把消息传递到响应链上。所以，为了避免阻断响应链，咱们的子类在重写时须要调用父类的相应方法；而不要将消息直接发送给下一响应者。

默认状况下，多点触摸是被禁用的。为了接受多点触摸事件，咱们须要设置响应视图的multipleTouchEnabled属性为YES。

响应移动事件

与触摸事件相似，UIResponder也提供了几个方法来响应移动事件：

// 移动事件开始- (void)motionBegan:(UIEventSubtype)motion withEvent:(UIEvent *)event// 移动事件结束- (void)motionEnded:(UIEventSubtype)motion withEvent:(UIEvent *)event// 取消移动事件- (void)motionCancelled:(UIEventSubtype)motion withEvent:(UIEvent *)event

与触摸事件不一样的是，运动事件只有开始与结束操做；它不会报告相似于晃动这样的事件。这几个方法的默认操做也是什么都不作。不过，UIKit中UIResponder的子类，尤为是UIView，这几个方法的实现都会把消息传递到响应链上。

响应远程控制事件

远程控制事件来源于一些外部的配件，如耳机等。用户能够经过耳机来控制视频或音频的播放。接收响应者对象须要检查事件的子类型来肯定命令(如播放，子类型为UIEventSubtypeRemoteControlPlay)，而后进行相应处理。

为了响应远程控制事件，UIResponder提供了如下方法，

- (void)remoteControlReceivedWithEvent:(UIEvent *)event

咱们能够在子类中实现该方法，来处理远程控制事件。不过，为了容许分发远程控制事件，咱们必须调用UIApplication的beginReceivingRemoteControlEvents方法；而若是要关闭远程控制事件的分发，则调用endReceivingRemoteControlEvents方法。

获取Undo管理器

默认状况下，程序的每个window都有一个undo管理器，它是一个用于管理undo和redo操做的共享对象。然而，响应链上的任何对象的类均可以有自定义undo管理器。例如，UITextField的实例的自定义管理器在文件输入框放弃第一响应者状态时会被清理掉。当须要一个undo管理器时，请求会沿着响应链传递，而后UIWindow对象会返回一个可用的实例。

UIResponder提供了一个只读方法来获取响应链中共享的undo管理器，

@property(nonatomic, readonly) NSUndoManager *undoManager

咱们能够在本身的视图控制器中添加undo管理器来执行其对应的视图的undo和redo操做。

验证命令

在咱们的应用中，常常会处理各类菜单命令，如文本输入框的”复制”、”粘贴”等。UIResponder为此提供了两个方法来支持此类操做。首先使用如下方法能够启动或禁用指定的命令：

- (BOOL)canPerformAction:(SEL)action withSender:(id)sender

该方法默认返回YES，咱们的类能够经过某种途径处理这个命令，包括类自己或者其下一个响应者。子类能够重写这个方法来开启菜单命令。例如，若是咱们但愿菜单支持”Copy”而不支持”Paser”，则在咱们的子类中实现该方法。须要注意的是，即便在子类中禁用某个命令，在响应链上的其它响应者也可能会处理这些命令。

另外，咱们可使用如下方法来获取能够响应某一行为的接收者：

- (id)targetForAction:(SEL)action withSender:(id)sender

在对象须要调用一个action操做时调用该方法。默认的实现是调用canPerformAction:withSender:方法来肯定对象是否能够调用action操做。若是能够，则返回对象自己，不然将请求传递到响应链上。若是咱们想要重写目标的选择方式，则应该重写这个方法。下面这段代码演示了一个文本输入域禁用拷贝/粘贴操做：

- (id)targetForAction:(SEL)action withSender:(id)sender
{  UIMenuController *menuController = [UIMenuController sharedMenuController];  if (action == @selector(selectAll:) || action == @selector(paste:) ||action == @selector(copy:) || action == @selector(cut:)) {    if (menuController) {      [UIMenuController sharedMenuController].menuVisible = NO;    }    return nil;  }  return [super targetForAction:action withSender:sender];
}

访问快捷键命令

咱们的应用能够支持外部设备，包括外部键盘。在使用外部键盘时，使用快捷键能够大大提升咱们的输入效率。所以从iOS7后，UIResponder类新增了一个只读属性keyCommands，来定义一个响应者支持的快捷键，其声明以下：

@property(nonatomic, readonly) NSArray *keyCommands

一个支持硬件键盘命令的响应者对象能够从新定义这个方法并使用它来返回一个其所支持快捷键对象(UIKeyCommand)的数组。每个快捷键命令表示识别的键盘序列及响应者的操做方法。

咱们用这个方法返回的快捷键命令数组被用于整个响应链。当与快捷键命令对象匹配的快捷键被按下时，UIKit会沿着响应链查找实现了响应行为方法的对象。它调用找到的第一个对象的方法并中止事件的处理。

管理文本输入模式

文本输入模式标识当响应者激活时的语言及显示的键盘。UIResponder为此定义了一个属性来返回响应者对象的文本输入模式：

@property(nonatomic, readonly, retain) UITextInputMode *textInputMode

对于响应者而言，系统一般显示一个基于用户语言设置的键盘。咱们能够从新定义这个属性，并让它返回一个不一样的文本输入模式，以让咱们的响应者使用一个特定的键盘。用户在响应者被激活时仍然能够改变键盘，在切换到另外一个响应者时，能够再恢复到指定的键盘。

若是咱们想让UIKit来跟踪这个响应者的文本输入模式，咱们能够经过textInputContextIdentifier属性来设置一个标识，该属性的声明以下：

@property(nonatomic, readonly, retain) NSString *textInputContextIdentifier

该标识指明响应者应保留文本输入模式的信息。在跟踪模式下，任何对文本输入模式的修改都会记录下来，当响应者激活时再用于恢复处理。

为了从程序的user default中清理输入模式信息，UIResponder定义了一个类方法，其声明以下：

+ (void)clearTextInputContextIdentifier:(NSString *)identifier

调用这个方法能够从程序的user default中移除与指定标识相关的全部文本输入模式。移除这些信息会让响应者从新使用默认的文本输入模式。

支持User Activities

从iOS 8起，苹果为咱们提供了一个很是棒的功能，即Handoff。使用这一功能，咱们能够在一部iOS设备的某个应用上开始作一件事，而后在另外一台iOS设备上继续作这件事。Handoff的基本思想是用户在一个应用里所作的任何操做均可以看做是一个Activity，一个Activity能够和一个特定iCloud用户的多台设备关联起来。在编写一个支持Handoff的应用时，会有如下三个交互事件：

1. 为将在另外一台设备上继续作的事建立一个新的User Activity；

2. 当须要时，用新的数据更新已有的User Activity；

3. 把一个User Activity传递到另外一台设备上。

为了支持这些交互事件，在iOS 8后，UIResponder类新增了几个方法，咱们在此不讨论这几个方法的实际使用，想了解更多的话，能够参考 iOS 8 Handoff 开发指南 。咱们在此只是简单描述一下这几个方法。 

在UIResponder中，已经为咱们提供了一个userActivity属性，它是一个NSUserActivity对象。所以咱们在UIResponder的子类中不须要再去声明一个userActivity属性，直接使用它就行。其声明以下：

@property(nonatomic, retain) NSUserActivity *userActivity

由UIKit管理的User Activities会在适当的时间自动保存。通常状况下，咱们能够重写UIResponder类的updateUserActivityState:方法来延迟添加表示User Activity的状态数据。当咱们再也不须要一个User Activity时，咱们能够设置userActivity属性为nil。任何由UIKit管理的NSUserActivity对象，若是它没有相关的响应者，则会自动失效。

另外，多个响应者能够共享一个NSUserActivity实例。

上面提到的updateUserActivityState:是用于更新给定的User Activity的状态。其定义以下：

- (void)updateUserActivityState:(NSUserActivity *)activity

子类能够重写这个方法来按照咱们的须要更新给定的User Activity。咱们须要使用NSUserActivity对象的addUserInfoEntriesFromDictionary:方法来添加表示用户Activity的状态。

在咱们修改了User Activity的状态后，若是想将其恢复到某个状态，则可使用如下方法：

- (void)restoreUserActivityState:(NSUserActivity *)activity

子类能够重写这个方法来使用给定User Activity的恢复响应者的状态。系统会在接收到数据时，将数据传递给application:continueUserActivity:restorationHandler:以作处理。咱们重写时应该使用存储在user activity的userInfo字典中的状态数据来恢复对象。固然，咱们也能够直接调用这个方法。