Runloop是怎樣進(jìn)行線程?；?/h1>

大?。?/span>0.3 MB 人氣： 2017-09-26 需要積分：1

推薦 + 挑錯 + 收藏(0) + 用戶評論（0）

前往下載地址

分享到:

分享此文章到新浪微博 分享此文章到開心網(wǎng) 分享此文章到人人網(wǎng) 分享此文章到豆瓣網(wǎng) 分享此文章到騰訊微博

標(biāo)簽：線程(19385)runloop(2539)

　　AFN 中的實(shí)現(xiàn)

　　在舊版本的AFN 中使用了 NSURLConnection 來發(fā)起并處理網(wǎng)絡(luò)連接。

　　AFN 的做法是把網(wǎng)絡(luò)請求的發(fā)起和解析都放在同一個子線程中進(jìn)行，子線程默認(rèn)不開啟 runloop，它會向一個 C語言程序那樣在運(yùn)行完所有代碼后退出線程。

　　而網(wǎng)絡(luò)請求是異步的，這導(dǎo)致獲取到請求數(shù)據(jù)時，線程已經(jīng)退出，代理方法沒有機(jī)會執(zhí)行。

　　因此，AFN 的做法是使用一個 runloop 來保證線程不死，也就是下面這段被講爛了的代碼：

　　+ （void）networkRequestThreadEntryPoint：（id）__unused object {

　　@autoreleasepool {

　?。郏跱SThread currentThread］ setName：@“AFNetworking”］;

　　NSRunLoop *runLoop = ［NSRunLoop currentRunLoop］;

　?。踨unLoop addPort：［NSMachPort port］ forMode:NSDefaultRunLoopMode］;

　?。踨unLoop run］;

　　}

　　}

　　稍微結(jié)合一下上下文，看看這個方法在哪里被調(diào)用：

　　+ （NSThread *）networkRequestThread {

　　static NSThread *_networkRequestThread = nil;

　　static dispatch_once_t oncePredicate;

　　dispatch_once（&oncePredicate， ^{

　　_networkRequestThread = ［［NSThread alloc］ initWithTarget:self selector：@selector（networkRequestThreadEntryPoint：） object:nil］;

　　［_networkRequestThread start］;

　　}）;

　　return _networkRequestThread;

　　}

　　似乎這種寫法提供了一種思路：“如果需要在子線程中異步執(zhí)行操作，可以利用 runloop 進(jìn)行線程?；睢?。但準(zhǔn)確的來說，AFN 的這種寫法并不能實(shí)現(xiàn)我們的需求，它只是在 AFN 這個特殊場景下可以工作。

　　NSThread 與內(nèi)存泄漏

　　這種寫法的第一個問題就是存在內(nèi)存泄漏。我們構(gòu)造以下用例，把 AFN 的線程創(chuàng)建放在一個循環(huán)里：

　　- （void）memoryTest {

　　for （int i = 0; i 《 100000; ++i） {

　　NSThread *thread = ［［NSThread alloc］ initWithTarget:self selector：@selector（run） object:nil］;

　　［thread start］;

　　}

　　}

　　- （void）run {

　　@autoreleasepool {

　　NSLog（@“current thread = %@”， ［NSThread currentThread］）;

　　NSRunLoop *runLoop = ［NSRunLoop currentRunLoop］;

　　if （！self.emptyPort） {

　　self.emptyPort = ［NSMachPort port］;

　　}

　?。踨unLoop addPort:self.emptyPort forMode:NSDefaultRunLoopMode］;

　?。踨unLoop run］;

　　}

　　}

　　奇怪的事情出現(xiàn)了，盡管是在 ARC 環(huán)境下，內(nèi)存依然不停的上漲。如果我們把 run 方法中和 runloop 相關(guān)的代碼刪除則不會出現(xiàn)上述問題，顯然，開啟 runloop 導(dǎo)致了內(nèi)存泄漏，也就是 thread 對象無法釋放。