一些新手常常搞混的东西
bool与BOOL
- 在 64 位操作系统上，OC 的
BOOL会直接等于定义的stdbool.h里面的bool，其实就是int,但如果在 32 位操作系统上，BOOL就会被定义成是一个char,而BOOL与bool，就分别是一个byte或是四个bytes的差别。- 所以，在 64 位操作系统上，
BOOL与bool并没有区别，但我们不能确定我们写的代码只会在这种环境下执行，当然，在其他环境下应该也没什么影响。
NULLnilNilNSNullNSNotFound
- 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:`预测下一个触控事件可能出现的位置，让画面看起来即时更新。
