NSURLConnection 工作原理

AFNetworking知识小记

本文观点来自于 AFNetworking3.0后为什么不再需要常驻线程？

1.关于NSURLConnection 的工作过程

摘至 深入理解RunLoop 

当开始网络传输时，我们可以看到 NSURLConnection 创建了两个新线程：com.apple.NSURLConnectionLoader 和 com.apple.CFSocket.private。其中 CFSocket 线程是处理底层 socket 连接的。NSURLConnectionLoader 这个线程内部会使用 RunLoop 来接收底层 socket 的事件，并通过之前添加的 Source0 通知到上层的 Delegate。

工作图

2.AFNetworking2.0为什么需要一个常驻线程？

主线程runloop 的默认的RunloopMode 是 NSDefaultRunLoopMode。当用户滑动 scrollview 时，RunloopMode会切换到 NSEventTrackingRunLoopMode 模式，这个时候回调函数就不会执行了，直到用户停止滑动。

就算加入到 主runloop 的时候，将model 改为NSRunLoopCommonModes也不行（原因是 如果将解析等工作让主线程执行，是会很耗性能的，主线程最好是只拿到解析后的值进行UI刷新）

小结一下为什么AF2.x需要一条常驻线程：

首先需要在子线程去start connection，请求发送后，所在的子线程需要保活以保证正常接收到 NSURLConnectionDelegate 回调方法。如果每来一个请求就开一条线程，并且保活线程，这样开销太大了。所以只需要保活一条固定的线程，在这个线程里发起请求、接收回调。

3.AF3.x为什么不再需要常驻线程？

self.operationQueue = [[NSOperationQueuealloc] init];self.operationQueue.maxConcurrentOperationCount =1;self.session = [NSURLSessionsessionWithConfiguration:self.sessionConfiguration delegate:selfdelegateQueue:self.operationQueue];

从上面的代码可以看出，NSURLSession发起的请求，不再需要在当前线程进行代理方法的回调！可以指定回调的delegateQueue，这样我们就不用为了等待代理回调方法而苦苦保活线程了。

这里指定的用于接收回调的Queue的maxConcurrentOperationCount设为了1，这里目的是想要让并发的请求串行的进行回调

好记性不如烂笔头，不知道怎么写技术文章，这里只能将一些观点罗列至此，日后方便自己查看，也希望能帮助到有需要的同学吧

参考资料

AFNetworking3.0后为什么不再需要常驻线程？

深入理解RunLoop