在讨论 runloop 相关的文章，以及分析 AFNetworking(2.x) 源码的文章中，我们经常会看到关于利用 runloop 进行线程保活的分析，但如果不求甚解的话，极有可能因此学会了一个错误的用法，本文就来分析一下其中常见的误区。
我提供了一个 Demo，可以在我的Github上下载并运行一遍，文章中只提供了部分代码。
AFN 中的实现
首先我们知道在旧版本的AFN中使用了 NSURLConnection 来发起并处理网络连接。AFN 的做法是把网络请求的发起和解析都放在同一个子线程中进行，但由于子线程默认不开启 runloop，它会向一个 C语言程序那样在运行完所有代码后退出线程。而网络请求是异步的，这会导致获取到请求数据时，线程已经退出，代理方法没有机会执行。因此，AFN 的做法是使用一个 runloop 来保证线程不死，也就是下面这段被讲烂了的代码:
+ (void)networkRequestThreadEntryPoint:(id)__unused object {@autoreleasepool{ [[NSThreadcurrentThread] setName:@"AFNetworking"];NSRunLoop*runLoop = [NSRunLoopcurrentRunLoop]; [runLoop addPort:[NSMachPortport] forMode:NSDefaultRunLoopMode]; [runLoop run]; }}
当然，单独看这一个方法意义不大，我们稍微结合一下上下文，看看这个方法在哪里被调用:
+ (NSThread*)networkRequestThread {staticNSThread*_networkRequestThread =nil;staticdispatch_once_toncePredicate;dispatch_once(&oncePredicate, ^{ _networkRequestThread = [[NSThreadalloc] initWithTarget:selfselector:@selector(networkRequestThreadEntryPoint:) object:nil]; [_networkRequestThread start]; });return_networkRequestThread;}
似乎这种写法提供了一种思路:“如果需要在子线程中异步执行操作，可以利用 runloop 进行线程保活”。但准确的来说，AFN 的这种写法并不能实现我们的需求，它只是在 AFN 这个特殊场景下可以工作。
不信你可以尝试阅读一下第二段代码，看看它和平时使用NSThread时有什么区别，如果没看出来也无妨，先记住这段代码，我们稍后分析。
NSThread 与内存泄漏
这种写法的第一个问题就是存在内存泄漏。我们构造以下用例，其实就是把 AFN 的线程创建放在一个循环里:
- (void)memoryTest {for(inti =0; i <100000; ++i) {NSThread*thread = [[NSThreadalloc] initWithTarget:selfselector:@selector(run) object:nil]; [thread start]; }}- (void)run {@autoreleasepool{NSLog(@"current thread = %@", [NSThreadcurrentThread]);NSRunLoop*runLoop = [NSRunLoopcurrentRunLoop];if(!self.emptyPort) {self.emptyPort= [NSMachPortport]; } [runLoop addPort:self.emptyPortforMode:NSDefaultRunLoopMode]; [runLoop run]; }}
奇怪的事情出现了，尽管是在 ARC 环境下，内存依然不停的上涨。如果我们把run方法中和 runloop 相关的代码删除则不会出现上述问题，显然，开启 runloop 导致了内存泄漏，也就是thread对象无法释放。
这里的 emptyPort 用来维持 runloop 的运行，根据官方文档的描述，如果 runloop 中没有任何
modeItem，就不会启动，而是立刻退出。之所以选择作为属性而不是临时变量，是因为我发现每次调用 [NSMachPort port]
方法都会占用内存，原因暂时不清楚。
我们可以尝试手动结束 runloop 并关闭线程:
- (void)memoryTest {for(inti =0; i <100000; ++i) {NSThread*thread = [[NSThreadalloc] initWithTarget:selfselector:@selector(run) object:nil]; [thread start]; [selfperformSelector:@selector(stopThread) onThread:thread withObject:nilwaitUntilDone:YES]; }}- (void)stopThread {CFRunLoopStop(CFRunLoopGetCurrent());NSThread*thread = [NSThreadcurrentThread]; [thread cancel];}
很遗憾，这依然没有任何效果。而且不难猜测是我们没有能正确的结束 runloop 的运行。
Runloop 的启动与退出
考验英文水平的时候到了，首先来看一段官方文档对于如何启动 runloop 的介绍，它的启动方式一共有三种:
Unconditionally
With a set time limit
In a particular mode
这三种进入方式分别对应了三种方法，其中第一种就是我们目前使用的:
run
runUntilDate
runMode:beforeDate:
接下来分别是对三种方式的介绍，文字比较啰嗦，这里我简单总结一下，有兴趣的读者可以直接看原文。
无条件进入是最简单的做法，但也最不推荐。这会使线程进入死循环，从而不利于控制 runloop，结束 runloop 的唯一方式是 kill 它。
如果我们设置了超时时间，那么 runloop 会在处理完事件或超时后结束，此时我们可以选择重新开启 runloop。这种方式要优于前一种
这是相对来说最优秀的方式，相比于第二种启动方式，我们可以指定 runloop 以哪种模式运行。
查看run方法的文档还可以知道，它的本质就是无限调用runMode:beforeDate:方法，同样地，runUntilDate:也会重复调用runMode:beforeDate:，区别在于它超时后就不会再调用。
总结来说，runMode:beforeDate:表示的是 runloop 的单次调用，另外两者则是循环调用。
相比于 runloop 的启动，它的退出就比较简单了，只有两种方法:
设置超时时间
手动结束
如果你使用方法二或三来启动 runloop，那么在启动的时候就可以设置超时时间。然而考虑到目标是:“利用 runloop 进行线程保活”，所以我们希望对线程和它的 runloop 有最精确的控制，比如在完成任务后立刻结束，而不是依赖于超时机制。
好在根据文档的描述，我们还可以使用CFRunLoopStop()方法来手动结束一个 runloop。注意文档中在介绍利用CFRunLoopStop()手动退出时有下面这句话:
The difference is that you can use this technique on run loops you started unconditionally.
这里的解释非常容易产生误会，如果在阅读时没有注意到exit和terminate的微小差异就很容易掉进坑里，因为在run方法的文档中还有这句话:
If you want the run loop to terminate, you shouldn't use this method
总的来说，如果你还想从 runloop 里面退出来，就不能用run方法。根据实践结果和文档，另外两种启动方法也无法手动退出。
正确的做法
难道子线程中开启了 runloop 就无法结束并释放了么？这显然是一个不合理的结论，经过一番查找，终于在这篇文章里找到了答案，它给出了使用CFRunLoopStop()无效的原因:
CFRunLoopStop() 方法只会结束当前的 runMode:beforeDate: 调用，而不会结束后续的调用。
这也就是为什么 Runloop 的文档中说CFRunLoopStop()可以exit(退出)一个 runloop，而在run等方法的文档中又说这样会导致 runloop 无法terminate(终结)。
文章中给出的方案是使用CFRunLoopRun()启动 runloop，这样就可以通过CFRunLoopStop()方法结束。而文档则推荐了另一种方法:
BOOLshouldKeepRunning =YES;// globalNSRunLoop*theRL = [NSRunLoopcurrentRunLoop];while(shouldKeepRunning && [theRL runMode:NSDefaultRunLoopModebeforeDate:[NSDatedistantFuture]]);
我尝试了文档提供的方法，确实不会导致内存泄漏，但不方便验证 runloop 是否真的开启，然后又被终止。所以我实际采用的是第一种方案:
- (void)memoryTest {for(inti =0; i <100000; ++i) {NSThread*thread = [[NSThreadalloc] initWithTarget:selfselector:@selector(run) object:nil]; [thread start]; [selfperformSelector:@selector(stopThread) onThread:thread withObject:nilwaitUntilDone:YES]; }}- (void)stopThread {CFRunLoopStop(CFRunLoopGetCurrent());NSThread*thread = [NSThreadcurrentThread]; [thread cancel];}- (void)run {@autoreleasepool{NSLog(@"current thread = %@", [NSThreadcurrentThread]);NSRunLoop*runLoop = [NSRunLoopcurrentRunLoop];if(!self.emptyPort) {self.emptyPort= [NSMachPortport]; } [runLoop addPort:self.emptyPortforMode:NSDefaultRunLoopMode]; [runLoop runMode:NSRunLoopCommonModesbeforeDate:[NSDatedistantFuture]]; }}
验证
采用上述方案后，确实可以观察到不会再出现内存泄漏问题，但这并不是终点。因为我们还需要验证 runloop 确实在启动后被关闭。
为了证明 runloop 确实启动，我设计了如下方法:
- (void)printSomething {NSLog(@"current thread = %@", [NSThreadcurrentThread]); [selfperformSelector:@selector(printSomething) withObject:nilafterDelay:1];}
我们知道performSelector:withObject:afterDelay依赖于线程的 runloop，因为它本质上是由一个定时器负责定期加入到 runloop 中执行。所以如果这个方法可以成功执行，说明当前线程的 runloop 已经开启，否则则说明没有启动。
为了证明 runloop 可以被终止，我创建了一个按钮，在点击按钮时执行以下方法:
- (void)stopButtonDidClicked:(id)sender { [selfperformSelector:@selector(stopRunloop) onThread:self.threadwithObject:nilwaitUntilDone:YES];}- (void)stopRunloop {CFRunLoopStop(CFRunLoopGetCurrent());}
成功的观察到点击按钮后，控制台不再有日志输出，因此证明 runloop 确实已经停止。
总结
啰嗦了这么多，其实是为了研究如何利用 runloop 实现线程保活。要注意的地方主要有以下点:
了解 runloop 实现线程保活的原理，注意添加的那个空 port
了解 runloop 导致的线程对象内存泄漏问题
了解 runloop 的几种启动方式以及彼此之间的关联
了解 runloop 的释放方式和原理
由于相关资料的匮乏以及个人水平有限，虽然竭力研究但仍不保证绝对的正确性，欢迎交流指正。
最后，文章开头对 AFN 的分析留作一个简单的思考题，为什么 AFN 中的用法不会有问题？
参考资料
