开局一张图剩下全靠编
目录结构
AFNetWorking基本上是所有iOS项目的标配。现在升级带最新版的3.X了。得益于苹果从NSURLConnection升级到NSURLSession,AFN也实现了api的简化,同时功能却一点没少。我们来看一下AFN3.X的目录结构:
1、AFNetWorking 这个文件是一个头文件。啥也没做,就是引入了其他文件方便使用。
2、AFURLSessionManager 这个文件是核心类,基本上通过它来实现了大部分核心功能。负责请求的建立、管理、销毁、安全、请求重定向、请求重启等各种功能。他主要实现了NSURLSession和NSRULSessionTask的封装。
3、AFHTTPSessionManager 这个文件是AFURLSessionManager的子类。主要实现了对HTTP请求的优化。
4、AFURLRequestSerialization 这个主要用于请求头的编码解码、序列化、优化处理、简化请求拼接过程等。
5、AFURLResponseSerialization 这个主要用于网络返回数据的序列化、编码解码、序列化、数据处理等。
6、AFSecurityPolicy 这个主要用于请求的认证功能。比如https的认证模式等。
7、AFNetworkReachabilityManager 这个主要用于监听网络请求状态变化功能。
AFNetwork2.0
底层是通过封装NSURLConnection来实现的
2.0特点
-常驻线程,用来并发请求,和处理数据回调;避免多个网络请求的线程开销(不用开辟一个线程,就保活一条线程);
底层是通过封装NSURLSession来实现的
3.0特点
-NSURLSession可以指定回调的delegateQueue,不用常驻线程。
-不用每次都三次握手
3.0为什么不需要常驻线程?
因为NSURLSession可以指定回调delegateQueue,NSURLConnection而不行;
NSURLConnection的一大痛点就是:发起请求后,而需要一直处于等待回调的状态。而3.0后NSURLSession解决的这个问题;NSURLSession发起的请求,不再需要在当前线程进行回调,可以指定回调的delegateQueue,这样就不用为了等待代理回调方法而保活线程了。
最大并发数:
3.0需要设置最大并发数为1 self.operationQueue.maxConcurrentOperationCount = 1?
- 串行:让并发的请求,串行的进行回调;
- 锁:且为了防止多线程资源竞争加了锁(对 self.mutableTaskDelegatesKeyedByTaskIdentifier(多任务代理) 的访问进行了加锁),本来就需要等待,如果多线程并发反而造成资源浪费;
2.0为什么不需要?
- 功能不一样:AF3.0的operationQueue是用来接收NSURLSessionDelegate回调的,鉴于一些多线程数据访问的安全性考虑,设置了maxConcurrentOperationCount = 1来达到串行回调的效果。
- 而AF2.0的operationQueue是用来添加operation并进行并发请求的,所以不要设置为1
总结:
AFN2.0
1 、保活常驻线程原因:可以避免多个网络请求,就要保活多个线程;
2 、常驻线程特点:并发请求,和代理回调都在同一线程(常驻线程);所以线程等待回调;
3 、并发请求:系统根据情况控制最大并发数;
4、2.0的operationQueue是用于并发请求的;
AFN3.0
1 、无需常驻线程原因:因为NSURLSession可以指定回调的delegateQueue,NSURLConnection而不行;
2 、最大并发数设置:3.0的operationQueue是用于接收NSURLSessionDelegate回调的;
self.operationQueue.maxConcurrentOperationCount = 1,是为了达到串行回调的效果,况且加了锁;