一、什么是NSRunLoop
NSRunLoop是消息機(jī)制的處理模式
NSRunLoop的作用在于有事情做的時(shí)候使的當(dāng)前NSRunLoop的線程工作，沒有事情做讓當(dāng)前NSRunLoop的線程休眠
NSTimer默認(rèn)添加到當(dāng)前NSRunLoop中，也可以手動(dòng)制定添加到自己新建的NSRunLoop
NSRunLoop就是一直在循環(huán)檢測，從線程start到線程end，檢測inputsource(如點(diǎn)擊，雙擊等操作)同步事件，檢測timesource同步事件，檢測到輸入源會(huì)執(zhí)行處理函數(shù)，首先會(huì)產(chǎn)生通知，corefunction向線程添加runloop observers來監(jiān)聽事件，意在監(jiān)聽事件發(fā)生時(shí)來做處理。
在單線程的app中，不需要注意Run Loop，但不代表沒有。程序啟動(dòng)時(shí)，系統(tǒng)已經(jīng)在主線程中加入了Run Loop。它保證了我們的主線程在運(yùn)行起來后，就處于一種“等待”的狀態(tài)（而不像一些命令行程序一樣運(yùn)行一次就結(jié)束了），這個(gè)時(shí)候如果有接收到的事件（Timer的定時(shí)到了或是其他線程的消息），就會(huì)執(zhí)行任務(wù)，否則就處于休眠狀態(tài)。
runloopmode是一個(gè)集合，包括監(jiān)聽：事件源，定時(shí)器，以及需通知的runloop observers
模式包括：
default模式：幾乎包括所有輸入源(除NSConnection) NSDefaultRunLoopMode模式
mode模式：處理modal panels
connection模式：處理NSConnection事件，屬于系統(tǒng)內(nèi)部，用戶基本不用
event tracking模式：如組件拖動(dòng)輸入源 UITrackingRunLoopModes 不處理定時(shí)事件
common modes模式：NSRunLoopCommonModes 這是一組可配置的通用模式。將input sources與該模式關(guān)聯(lián)則同時(shí)也將input sources與該組中的其它模式進(jìn)行了關(guān)聯(lián)。
每次運(yùn)行一個(gè)run loop，你指定（顯式或隱式）run loop的運(yùn)行模式。當(dāng)相應(yīng)的模式傳遞給run loop時(shí)，只有與該模式對(duì)應(yīng)的input sources才被監(jiān)控并允許run loop對(duì)事件進(jìn)行處理（與此類似，也只有與該模式對(duì)應(yīng)的observers才會(huì)被通知）
例：
1).在timer與table同時(shí)執(zhí)行情況，當(dāng)拖動(dòng)table時(shí)，runloop進(jìn)入U(xiǎn)ITrackingRunLoopModes模式下，不會(huì)處理定時(shí)事件，此時(shí)timer不能處理，所以此時(shí)將timer加入到NSRunLoopCommonModes模式(addTimer forMode)
2).在scroll一個(gè)頁面時(shí)來松開，此時(shí)connection不會(huì)收到消息，由于scroll時(shí)runloop為UITrackingRunLoopModes模式，不接收輸入源，此時(shí)要修改connection的mode
[scheduleInRunLoop:[NSRunLoop currentRunLoop]forMode:NSRunLoopCommonModes];
關(guān)于-(BOOL)runMode:(NSString)mode beforeDate:(NSDate)date;方法
指定runloop模式來處理輸入源，首個(gè)輸入源或date結(jié)束退出。
暫停當(dāng)前處理的流程，轉(zhuǎn)而處理其他輸入源，當(dāng)date設(shè)置為[NSDate distantFuture]-(將來，基本不會(huì)到達(dá)的時(shí)間)，所以除非處理其他輸入源結(jié)束，否則永不退出處理暫停的當(dāng)前處理的流程。
while(A){
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
}
當(dāng)前A為YES時(shí)，當(dāng)前runloop會(huì)一直接收處理其他輸入源，當(dāng)前流程不繼續(xù)處理，出為A為NO，當(dāng)前流程繼續(xù)
performSelector關(guān)于內(nèi)存管理的執(zhí)行原理是這樣的執(zhí)行 [self performSelector:@selector(method1:) withObject:self.tableLayer afterDelay:3]; 的時(shí)候，系統(tǒng)會(huì)將tableLayer的引用計(jì)數(shù)加1，執(zhí)行完這個(gè)方法時(shí)，還會(huì)將tableLayer的引用計(jì)數(shù)減1，由于延遲這時(shí)tableLayer的引用計(jì)數(shù)沒有減少到0，也就導(dǎo)致了切換場景dealloc方法沒有被調(diào)用，出現(xiàn)了內(nèi)存泄露。
利用如下函數(shù)：
[NSObject cancelPreviousPerformRequestsWithTarget:self]
當(dāng)然你也可以一個(gè)一個(gè)得這樣用：
[NSObject cancelPreviousPerformRequestsWithTarget:self selector:@selector(method1:) object:nil]
加上了這個(gè)以后，順利地執(zhí)行了dealloc方法
在touchBegan里面
[self performSelector:@selector(longPressMethod:) withObject:nil afterDelay:longPressTime]
然后在end 或cancel里做判斷，如果時(shí)間不夠長按的時(shí)間調(diào)用：
[NSObject cancelPreviousPerformRequestsWithTarget:self selector:@selector(longPressMethod:) object:nil]
取消began里的方法
二、Run Loop和線程的關(guān)系：
主線程的run loop默認(rèn)是啟動(dòng)的，用于接收各種輸入sources
對(duì)第二線程來說，run loop默認(rèn)是沒有啟動(dòng)的，如果你需要更多的線程交互則可以手動(dòng)配置和啟動(dòng)，如果線程執(zhí)行一個(gè)長時(shí)間已確定的任務(wù)則不需要。
三、Run Loop什么情況下使用：
使用ports 或 input sources 和其他線程通信 // 不了解
在線程中使用timers // 如果不啟動(dòng)run
loop，timer的事件是不會(huì)響應(yīng)的
在Cocoa 應(yīng)用中使用performSelector…方法 // 應(yīng)該是performSelector…這種方法會(huì)啟動(dòng)一個(gè)線程并啟動(dòng)run loop吧
讓線程執(zhí)行一個(gè)周期性的任務(wù)
注：timer的創(chuàng)建和釋放必須在同一線程中。
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes]; 此方法會(huì)retain timer對(duì)象的引用計(jì)數(shù)。
1、NSTimer會(huì)是準(zhǔn)時(shí)觸發(fā)事件嗎
答案是否定的，而且有時(shí)候你會(huì)發(fā)現(xiàn)實(shí)際的觸發(fā)時(shí)間跟你想象的差距還比較大。NSTimer不是一個(gè)實(shí)時(shí)系統(tǒng)，因此不管是一次性的還是周期性的timer的實(shí)際觸發(fā)事件的時(shí)間可能都會(huì)跟我們預(yù)想的會(huì)有出入。差距的大小跟當(dāng)前我們程序的執(zhí)行情況有關(guān)系，比如可能程序是多線程的，而你的timer只是添加在某一個(gè)線程的runloop的某一種指定的runloopmode中，由于多線程通常都是分時(shí)執(zhí)行的，而且每次執(zhí)行的mode也可能隨著實(shí)際情況發(fā)生變化。
假設(shè)你添加了一個(gè)timer指定2秒后觸發(fā)某一個(gè)事件，但是簽好那個(gè)時(shí)候當(dāng)前線程在執(zhí)行一個(gè)連續(xù)運(yùn)算(例如大數(shù)據(jù)塊的處理等)，這個(gè)時(shí)候timer就會(huì)延遲到該連續(xù)運(yùn)算執(zhí)行完以后才會(huì)執(zhí)行。重復(fù)性的timer遇到這種情況，如果延遲超過了一個(gè)周期，則會(huì)和后面的觸發(fā)進(jìn)行合并，即在一個(gè)周期內(nèi)只會(huì)觸發(fā)一次。但是不管該timer的觸發(fā)時(shí)間延遲的有多離譜，他后面的timer的觸發(fā)時(shí)間總是倍數(shù)于第一次添加timer的間隙。
原文如下：
A repeating timer reschedules itself based on the scheduled firing time, not the actual firing time. For example, if a timer is scheduled to fire at a particular time and every 5 seconds after that, the scheduled firing time will always fall on the original 5 second time intervals, even if the actual firing time gets delayed. If the firing time is delayed so far that it passes one or more of the scheduled firing times, the timer is fired only once for that time period; the timer is then rescheduled, after firing, for the next scheduled firing time in the future.
下面請(qǐng)看一個(gè)簡單的例子:
- (void)applicationDidBecomeActive:(UIApplication *)application
{
SvTestObject *testObject2 = [[SvTestObject alloc] init];
[NSTimer scheduledTimerWithTimeInterval:1 target:testObject2 selector:@selector(timerAction:) userInfo:nil repeats:YES];
[testObject2 release];
NSLog(@"Simulate busy");
[self performSelector:@selector(simulateBusy) withObject:nil afterDelay:3];
}
// 模擬當(dāng)前線程正好繁忙的情況
- (void)simulateBusy
{
NSLog(@"start simulate busy!");
NSUInteger caculateCount = 0x0FFFFFFF;
CGFloat uselessValue = 0;
for (NSUInteger i = 0; i < caculateCount; ++i) {
uselessValue = i / 0.3333;
}
NSLog(@"finish simulate busy!");
}
例子中首先開啟了一個(gè)timer，這個(gè)timer每隔1秒調(diào)用一次target的timerAction方法，緊接著我們在3秒后調(diào)用了一個(gè)模擬線程繁忙的方法(其實(shí)就是一個(gè)大的循環(huán))。運(yùn)行程序后輸出結(jié)果如下:
觀察結(jié)果我們可以發(fā)現(xiàn)，當(dāng)線程空閑的時(shí)候timer的消息觸發(fā)還是比較準(zhǔn)確的，但是在36分12秒開始線程一直忙著做大量運(yùn)算，知道36分14秒該運(yùn)算才結(jié)束，這個(gè)時(shí)候timer才觸發(fā)消息，這個(gè)線程繁忙的過程超過了一個(gè)周期，但是timer并沒有連著觸發(fā)兩次消息，而只是觸發(fā)了一次。等線程忙完以后后面的消息觸發(fā)的時(shí)間仍然都是整數(shù)倍與開始我們指定的時(shí)間，這也從側(cè)面證明，timer并不會(huì)因?yàn)橛|發(fā)延遲而導(dǎo)致后面的觸發(fā)時(shí)間發(fā)生延遲。
綜上: timer不是一種實(shí)時(shí)的機(jī)制，會(huì)存在延遲，而且延遲的程度跟當(dāng)前線程的執(zhí)行情況有關(guān)。
2、NSTimer為什么要添加到RunLoop中才會(huì)有作用
前面的例子中我們使用的是一種便利方法，它其實(shí)是做了兩件事：首先創(chuàng)建一個(gè)timer，然后將該timer添加到當(dāng)前runloop的default mode中。也就是這個(gè)便利方法給我們造成了只要?jiǎng)?chuàng)建了timer就可以生效的錯(cuò)覺，我們當(dāng)然可以自己創(chuàng)建timer，然后手動(dòng)的把它添加到指定runloop的指定mode中去。
NSTimer其實(shí)也是一種資源，如果看過多線程變成指引文檔的話，我們會(huì)發(fā)現(xiàn)所有的source如果要起作用，就得加到runloop中去。同理timer這種資源要想起作用，那肯定也需要加到runloop中才會(huì)又效嘍。如果一個(gè)runloop里面不包含任何資源的話，運(yùn)行該runloop時(shí)會(huì)立馬退出。你可能會(huì)說那我們APP的主線程的runloop我們沒有往其中添加任何資源，為什么它還好好的運(yùn)行。我們不添加，不代表框架沒有添加，如果有興趣的話你可以打印一下main thread的runloop，你會(huì)發(fā)現(xiàn)有很多資源。
下面我們看一個(gè)小例子：
- (void)applicationDidBecomeActive:(UIApplication *)application
{
[self testTimerWithOutShedule];
}
- (void)testTimerWithOutShedule
{
NSLog(@"Test timer without shedult to runloop")
SvTestObject *testObject3 = [[SvTestObject alloc] init];
NSTimer *timer = [[NSTimer alloc] initWithFireDate:[NSDate dateWithTimeIntervalSinceNow:1] interval:1 target:testObject3 selector:@selector(timerAction:) userInfo:nil repeats:NO];
[testObject3 release];
NSLog(@"invoke release to testObject3");
}
- (void)applicationWillResignActive:(UIApplication *)application
{
NSLog(@"SvTimerSample Will resign Avtive!");
}
這個(gè)小例子中我們新建了一個(gè)timer，為它指定了有效的target和selector，并指出了1秒后觸發(fā)該消息，運(yùn)行結(jié)果如下:
觀察發(fā)現(xiàn)這個(gè)消息永遠(yuǎn)也不會(huì)觸發(fā)，原因很簡單，我們沒有將timer添加到runloop中。
綜上: 必須得把timer添加到runloop中，它才會(huì)生效。
3、NSTimer加到了RunLoop中但遲遲的不觸發(fā)事件
為什么明明添加了，但是就是不按照預(yù)先的邏輯觸發(fā)事件呢？？？原因主要有以下兩個(gè):
1、runloop是否運(yùn)行
每一個(gè)線程都有它自己的runloop，程序的主線程會(huì)自動(dòng)的使runloop生效，但對(duì)于我們自己新建的線程，它的runloop是不會(huì)自己運(yùn)行起來，當(dāng)我們需要使用它的runloop時(shí)，就得自己啟動(dòng)。
那么如果我們把一個(gè)timer添加到了非主線的runloop中，它還會(huì)按照預(yù)期按時(shí)觸發(fā)嗎？下面請(qǐng)看一段測試程序:
- (void)applicationDidBecomeActive:(UIApplication *)application
{
[NSThread detachNewThreadSelector:@selector(testTimerSheduleToRunloop1) toTarget:self withObject:nil];
}
// 測試把timer加到不運(yùn)行的runloop上的情況
- (void)testTimerSheduleToRunloop1
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSLog(@"Test timer shedult to a non-running runloop");
SvTestObject *testObject4 = [[SvTestObject alloc] init];
NSTimer *timer = [[NSTimer alloc] initWithFireDate:[NSDate dateWithTimeIntervalSinceNow:1] interval:1 target:testObject4 selector:@selector(timerAction:) userInfo:nil repeats:NO];
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSDefaultRunLoopMode];
// 打開下面一行輸出runloop的內(nèi)容就可以看出，timer卻是已經(jīng)被添加進(jìn)去
//NSLog(@"the thread's runloop: %@", [NSRunLoop currentRunLoop]);
// 打開下面一行, 該線程的runloop就會(huì)運(yùn)行起來，timer才會(huì)起作用
//[[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:3]];
[testObject4 release];
NSLog(@"invoke release to testObject4");
[pool release];
}
- (void)applicationWillResignActive:(UIApplication *)application
{
NSLog(@"SvTimerSample Will resign Avtive!");
}
上面的程序中，我們新創(chuàng)建了一個(gè)線程，然后創(chuàng)建一個(gè)timer，并把它添加當(dāng)該線程的runloop當(dāng)中，但是運(yùn)行結(jié)果如下：
觀察運(yùn)行結(jié)果，我們發(fā)現(xiàn)這個(gè)timer知道執(zhí)行退出也沒有觸發(fā)我們指定的方法，如果我們把上面測試程序中“//[[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:3]];”這一行的注釋去掉，則timer將會(huì)正確的掉用我們指定的方法。
2、mode是否正確
我們前面自己動(dòng)手添加runloop的時(shí)候，可以看到有一個(gè)參數(shù)runloopMode，這個(gè)參數(shù)是干嘛的呢？
前面提到了要想timer生效，我們就得把它添加到指定runloop的指定mode中去，通常是主線程的defalut mode。但有時(shí)我們這樣做了，卻仍然發(fā)現(xiàn)timer還是沒有觸發(fā)事件。這是為什么呢？
這是因?yàn)閠imer添加的時(shí)候，我們需要指定一個(gè)mode，因?yàn)橥痪€程的runloop在運(yùn)行的時(shí)候，任意時(shí)刻只能處于一種mode。所以只能當(dāng)程序處于這種mode的時(shí)候，timer才能得到觸發(fā)事件的機(jī)會(huì)。
舉個(gè)不恰當(dāng)?shù)睦樱覀冋f兄弟幾個(gè)分別代表runloop的mode，timer代表他們自己的才水桶，然后一群人去排隊(duì)打水，只有一個(gè)水龍頭，那么同一時(shí)刻，肯定只能有一個(gè)人處于接水的狀態(tài)。也就是說你雖然給了老二一個(gè)桶，但是還沒輪到它，那么你就得等，只有輪到他的時(shí)候你的水桶才能碰上用場
本文出處剛剛在線：http://www.superqq.com/blog/2016/05/05/ios-nsrunllop-nstimer/
