一些新手常常搞混的東西
bool與BOOL
- 在 64 位操作系統(tǒng)上，OC 的
BOOL會(huì)直接等于定義的stdbool.h里面的bool，其實(shí)就是int,但如果在 32 位操作系統(tǒng)上，BOOL就會(huì)被定義成是一個(gè)char,而BOOL與bool，就分別是一個(gè)byte或是四個(gè)bytes的差別。- 所以，在 64 位操作系統(tǒng)上，
BOOL與bool并沒有區(qū)別，但我們不能確定我們寫的代碼只會(huì)在這種環(huán)境下執(zhí)行，當(dāng)然，在其他環(huán)境下應(yīng)該也沒什么影響。
NULLnilNilNSNullNSNotFound
- NULL
NULL其實(shí)并不算是 OC 的東西，而是屬于 C 語言。NULL就是 C 語言當(dāng)中的空指針，是指向 0 的指針。nil、Nil與NULL可以代替使用，但在語意上，當(dāng)某個(gè) API 想要傳入某個(gè)指針(void *)時(shí)，而不是id類型時(shí)，雖然你可以在這種狀態(tài)下也可以傳入 OC 對(duì)象指針nil，但是傳入NULL意義會(huì)比較清楚。- 總結(jié)：
id用nil，(void *)用NULL。
- nil
- 是空的 OC 對(duì)象指針，也一樣是指向 0.如果我們創(chuàng)建了一個(gè) OC 對(duì)象的變量，當(dāng)我們不想要使用這個(gè)對(duì)象的時(shí)候，便可以將這個(gè)變量指向
nil；我們可以對(duì)nil調(diào)用任何的 OC 對(duì)象，都不會(huì)產(chǎn)生問題。- 在
NSArray和NSDictionary中使用nil，會(huì)被當(dāng)成是最后一個(gè)參數(shù)，出現(xiàn)在nil之后的參數(shù)都會(huì)被忽略。另外在對(duì)字典和數(shù)組插入nil的時(shí)候，程序會(huì)崩潰。
- Nil
nil是空的實(shí)例，而開頭大寫的Nil則是指空的類。當(dāng)我們要判斷某個(gè)類是不是空的，語意上應(yīng)該用Nil而不是nil。- 比較可能的應(yīng)用場(chǎng)合，就是判斷在新的 iOS 系統(tǒng)上出現(xiàn)的新類，如果無法向下兼容，則執(zhí)行其他代碼。
Class cls = NSClassFromString(@"Abcdefg");
if (cls != Nil) {
// Do something.
}
- NSNull
NSNull是 OC 對(duì)象，在數(shù)組和字典中不可以插入nil，但可以通過插入NSNull對(duì)象表示沒有東西。- 在 JSON 文件里，轉(zhuǎn)換成 OC 對(duì)象時(shí)，JSON 里面的
null則會(huì)轉(zhuǎn)變成NSNull對(duì)象。
- NSNotFound
NSNotFound所代表的是找不到這個(gè)東西的index。NSNotFound是整數(shù)的最大值，通常不會(huì)建立這么大的數(shù)組。在 64 位操作系統(tǒng)和 32 位操作系統(tǒng)上整數(shù)的最大值是不一樣的。如下面這段代碼，在 64 位操作系統(tǒng)下是有問題的：int x = [@[@1, @2, @3] indexOfObject:@4];
if (x != NSNotFound) {
NSLog(@"Found!");
}
* 該代碼中，`NSNotFound`在 64 位操作系統(tǒng)上整數(shù)的最大值，但 `x` 被轉(zhuǎn)變成 32 位整數(shù)的最大值，所以`x`就無法等于`NSNotFound`了。
Responder(響應(yīng)者)
事件的傳遞
- 傳遞過程：
- 硬件把事件傳到我們的 App 中，交由
UIApplication對(duì)象分配事件UIApplication把事件傳送到key Window中，接著由key Window負(fù)責(zé)分派事件key Window開始尋找在視圖層次中最上面的控制器與視圖，然后發(fā)現(xiàn)在上面的視圖是我們的按鈕- 觸發(fā)按鈕的點(diǎn)擊事件。(如果沒有事件處理，事件又會(huì)回到
application上)
- 從
application到window到view，每一層中可以處理事件的對(duì)象，都叫做響應(yīng)者。最終處理事件的對(duì)象，叫做第一響應(yīng)者，而這種事件一層層傳遞的尋找處理事件的鎖鏈，叫做響應(yīng)者鏈條。Run loop
main.m文件里面的做法：
- 建立
auto-release pool- 調(diào)用
UIApplicationMain，創(chuàng)建UIApplication單利對(duì)象- 執(zhí)行
run loop- 調(diào)用
UIApplication代理方法Application
- 硬件事件會(huì)被傳遞到
window上，而其他系統(tǒng)事件，包括軟件的開啟和關(guān)閉，前臺(tái)和后臺(tái)等，都有轉(zhuǎn)發(fā)給application的代理方法中。- 由于
application位于相應(yīng)者鏈條的最底層，每個(gè)視圖與window都不處理的時(shí)候，才會(huì)對(duì)給application處理，所以如果我們希望處理一些會(huì)影響整個(gè)App行為的事情時(shí)，就會(huì)由application這一層處理。- 通過藍(lán)牙耳機(jī)或數(shù)據(jù)線上的按鈕切換歌曲，在 iOS7.1 之前，是通過在
application代理方法中實(shí)現(xiàn)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
* 當(dāng)然，如果想要開始接收來自耳機(jī)的事件，還要對(duì)`application`單利對(duì)象調(diào)用`beginReceivingRemoteControlEvents`方法。 * 在 iOS7.1以后，推出來`MPRemoteCommandCenter`這個(gè)類。之前想要開始播放，會(huì)在`remoteControlReceivedWithEvent:`里面處理`UIEventSubtypeRemoteControlPlay`的狀態(tài)?，F(xiàn)在會(huì)改成向`MPRemoteCommandCenter`要求`playCommand`,然后指定`target/action`，如下： ```swift [[MPRemoteCommandCenter sharedCommandCenter].playCommand addTarg
et:self action:@selector(play:)];
####Window * `application`在收到觸控等硬件事件之后，會(huì)把事件轉(zhuǎn)發(fā)給`key window`。 * 自己創(chuàng)建一個(gè)`window`對(duì)象，調(diào)用`makeKeyAndOrderFront`方法，顯示該`window`，`makeKeyAndOrderFront`方法不但會(huì)讓這個(gè)`window`顯現(xiàn)，同時(shí)也會(huì)使該對(duì)象成為`key window`,所有的事件都會(huì)往這個(gè)`window`送，所以，如果該`wondow`使用完畢，必須對(duì)原來的`key window`再調(diào)用一次`makeKeyAndOrderFront`，把事件處理的權(quán)限交還回去。 ####View * `application`通過`sendEvent:`將事件送到`window`，`window`也一樣通過`sendEvent:`將事件送到`view`上，而`view`里面，則是通過`hitTest:withEvent:`方法，在一層又一層的子視圖中查找應(yīng)該處理事件的子視圖。 ####View Controller `view Controller`本身也是個(gè)相應(yīng)者，因此也實(shí)現(xiàn)了`UIResponder`協(xié)議。當(dāng)觸控事件發(fā)生的時(shí)候，如果某個(gè)控制器的視圖都不處理傳來的事件，那么就會(huì)轉(zhuǎn)向詢問這個(gè)視圖的控制器本身是否處理這個(gè)事件。 ####UITouch * 起初是個(gè)非常單純的對(duì)象，頂多只會(huì)使用`locationInView:`判斷觸控事件發(fā)生在視圖的哪個(gè)位置上，用`tapCount`知道觸屏了幾下，用`timestamp`知道觸摸的時(shí)間。 * iOS9添加了一些新的接口`coalescedTouchesForTouch`，獲取比往常一輪`run loop`收到一次`touch`對(duì)象更快的刷新頻率的觸控事件對(duì)象，使反應(yīng)更靈敏。 * `predictedTouchesForTouch:`預(yù)測(cè)下一個(gè)觸控事件可能出現(xiàn)的位置，讓畫面看起來即時(shí)更新。
