kkbox-ios-dev笔记(六) - 概念／Responder

一些新手常常搞混的东西

bool与BOOL

• 在 64 位操作系统上，OC 的 BOOL会直接等于定义的stdbool.h里面的bool，其实就是int,但如果在 32 位操作系统上，BOOL就会被定义成是一个char,而BOOL与bool，就分别是一个byte或是四个bytes的差别。
• 所以，在 64 位操作系统上，BOOL与bool并没有区别，但我们不能确定我们写的代码只会在这种环境下执行，当然，在其他环境下应该也没什么影响。

NULL nil Nil NSNull NSNotFound

• NULL
• NULL其实并不算是 OC 的东西，而是属于 C 语言。NULL就是 C 语言当中的空指针，是指向 0 的指针。nil、Nil与NULL可以代替使用，但在语意上，当某个 API 想要传入某个指针(void *)时，而不是 id 类型时，虽然你可以在这种状态下也可以传入 OC 对象指针nil，但是传入 NULL意义会比较清楚。
• 总结：id用nil，(void *)用NULL。

• ---

• nil
• 是空的 OC 对象指针，也一样是指向 0.如果我们创建了一个 OC 对象的变量，当我们不想要使用这个对象的时候，便可以将这个变量指向 nil；我们可以对nil调用任何的 OC 对象，都不会产生问题。
• 在NSArray和NSDictionary中使用nil，会被当成是最后一个参数，出现在nil之后的参数都会被忽略。另外在对字典和数组插入nil的时候，程序会崩溃。

• ---

• Nil
• nil是空的实例，而开头大写的Nil则是指空的类。当我们要判断某个类是不是空的，语意上应该用Nil而不是nil。
• 比较可能的应用场合，就是判断在新的 iOS 系统上出现的新类，如果无法向下兼容，则执行其他代码。

Class cls = NSClassFromString(@"Abcdefg");

if (cls != Nil) {
// Do something.
}

• ---

• NSNull
• NSNull是 OC 对象，在数组和字典中不可以插入nil，但可以通过插入NSNull对象表示没有东西。
• 在 JSON 文件里，转换成 OC 对象时，JSON 里面的 null则会转变成 NSNull对象。

• ---

• NSNotFound
• NSNotFound所代表的是找不到这个东西的index。NSNotFound是整数的最大值，通常不会建立这么大的数组。在 64 位操作系统和 32 位操作系统上整数的最大值是不一样的。如下面这段代码，在 64 位操作系统下是有问题的：

int x = [@[@1, @2, @3] indexOfObject:@4];

if (x != NSNotFound) {
NSLog(@"Found!");
}

* 该代码中，`NSNotFound`在 64 位操作系统上整数的最大值，但 `x` 被转变成 32 位整数的最大值，所以`x`就无法等于`NSNotFound`了。

Responder(响应者)

事件的传递

• 传递过程：
• 硬件把事件传到我们的 App 中，交由UIApplication对象分配事件
• UIApplication把事件传送到key Window中，接着由key Window负责分派事件
• key Window开始寻找在视图层次中最上面的控制器与视图，然后发现在上面的视图是我们的按钮
• 触发按钮的点击事件。(如果没有事件处理，事件又会回到application上)

• 从application到window到view，每一层中可以处理事件的对象，都叫做响应者。最终处理事件的对象，叫做第一响应者，而这种事件一层层传递的寻找处理事件的锁链，叫做响应者链条。

Run loop

• main.m文件里面的做法：
  • 建立auto-release pool
  • 调用UIApplicationMain，创建UIApplication单利对象
  • 执行run loop
  • 调用UIApplication代理方法

Application

• 硬件事件会被传递到window上，而其他系统事件，包括软件的开启和关闭，前台和后台等，都有转发给application的代理方法中。
• 由于application位于相应者链条的最底层，每个视图与window都不处理的时候，才会对给application处理，所以如果我们希望处理一些会影响整个App行为的事情时，就会由application这一层处理。
• 通过蓝牙耳机或数据线上的按钮切换歌曲，在 iOS7.1 之前，是通过在application代理方法中实现remoteControlReceivedWithEvent:方法，

- (void)remoteControlReceivedWithEvent:(UIEvent *)theEvent

{
if (theEvent.type == UIEventTypeRemoteControl) {
switch(theEvent.subtype) {
case UIEventSubtypeRemoteControlPlay:
break;
case UIEventSubtypeRemoteControlPause:
break;
case UIEventSubtypeRemoteControlStop:
break;
case UIEventSubtypeRemoteControlTogglePlayPause:
break;
case UIEventSubtypeRemoteControlNextTrack:
break;
case UIEventSubtypeRemoteControlPreviousTrack:
break;
... default:
return;
}
}
}
@end

* 当然，如果想要开始接收来自耳机的事件，还要对`application`单利对象调用`beginReceivingRemoteControlEvents`方法。
* 在 iOS7.1以后，推出来`MPRemoteCommandCenter`这个类。之前想要开始播放，会在`remoteControlReceivedWithEvent:`里面处理`UIEventSubtypeRemoteControlPlay`的状态。现在会改成向`MPRemoteCommandCenter`要求`playCommand`,然后指定`target/action`，如下：

```swift
[[MPRemoteCommandCenter sharedCommandCenter].playCommand addTarg

et:self action:@selector(play:)];

####Window
* `application`在收到触控等硬件事件之后，会把事件转发给`key window`。
* 自己创建一个`window`对象，调用`makeKeyAndOrderFront`方法，显示该`window`，`makeKeyAndOrderFront`方法不但会让这个`window`显现，同时也会使该对象成为`key window`,所有的事件都会往这个`window`送，所以，如果该`wondow`使用完毕，必须对原来的`key window`再调用一次`makeKeyAndOrderFront`，把事件处理的权限交还回去。

####View
* `application`通过`sendEvent:`将事件送到`window`，`window`也一样通过`sendEvent:`将事件送到`view`上，而`view`里面，则是通过`hitTest:withEvent:`方法，在一层又一层的子视图中查找应该处理事件的子视图。

####View Controller
`view Controller`本身也是个相应者，因此也实现了`UIResponder`协议。当触控事件发生的时候，如果某个控制器的视图都不处理传来的事件，那么就会转向询问这个视图的控制器本身是否处理这个事件。

####UITouch
* 起初是个非常单纯的对象，顶多只会使用`locationInView:`判断触控事件发生在视图的哪个位置上，用`tapCount`知道触屏了几下，用`timestamp`知道触摸的时间。
* iOS9添加了一些新的接口`coalescedTouchesForTouch`，获取比往常一轮`run loop`收到一次`touch`对象更快的刷新频率的触控事件对象，使反应更灵敏。
* `predictedTouchesForTouch:`预测下一个触控事件可能出现的位置，让画面看起来即时更新。