全面解析AFNetWorking

AFNetworking核心内容

AFURLSessionManager中的知识点

Method Swizle交换sessionTask本身的resume与suspend

目的是手动触发自定义的resume与suspend通知

主类中用readOnly拓展readwrite

用锁来获取sessionManager代理

使用信号量为0来解决2个线程间的协调冲突， Passing zero for the value is useful for when two threads need to reconcile the completion of a particular event.

4个static函数

归档解裆，针对URLSessionConfiguration，没有保证其他信息的一致性

Copy协议也是针对URLSessionConfiguration，没有保证

AFNetWorking创建任务，其中create_task_safely是保证block，也就是创建task能够安全，这是AFNetWorking本身的bug，需要版本控制（猜测是之前的Foundation要求同步创建task）、

AFURLSessionManager

AFSessionManager的出现是为了简化对Session的管理，主要是Session的生成，内容的访问：taks/dataTasks/uploadTasks/downlaodTasks以及Delegate的设置，sessionManager本身其实负责的是Session，SecureCoding，Copying里面有个内部类sessionManamgerDelegate，此类负责sessionTask,sessionData,SessionDownlad。

AFHTTPSessionManager

AFHTTPSessionManager继承自AFSessionManager

Notification在哪个线程中被转发就在哪个线程，不一定在注册观察者的那个线程。

NSStringFromSelector(_cmd) _cmd是隐藏参数，代表当前方法的selector

dynamic responseSerializer：其实它本身实现了对应的set方法，并且默认是JSON的responseSerializer，据文档说它会在得到服务器响应之后自动调用来解析从服务器获取的内容。

归档

解档：

CopyWithZone

补充知识点：

URL加载系统

NSURLProtocol或许是 URL 加载系统中最功能强大但同时也是最晦涩的部分了。它是一个抽象类，你可以通过子类化来定义新的或已经存在的 URL 加载行为。

听了我说了这些乱七八糟的如果你还没有抓狂，这里有一些关于 _ 希望加载请求时不用改变其他部分代码 _ 的例子，供你参考：

拦截图片加载请求，转为从本地文件加载

为了测试对 HTTP 返回内容进行 mock 和 stub

对发出请求的 header 进行格式化

对发出的媒体请求进行签名

创建本地代理服务，用于数据变化时对 URL 请求的更改

故意制造畸形或非法返回数据来测试程序的鲁棒性

过滤请求和返回中的敏感信息

在既有协议基础上完成对 NSURLConnection 的实现且与原逻辑不产生矛盾

再次强调 NSURLProtocol 核心思想最重要的一点：用了它，你不必改动应用在网络调用上的其他部分，就可以改变 URL 加载行为的全部细节。

或者这么说吧： NSURLProtocol 就是一个苹果允许的中间人攻击。

 

这部分逻辑定义在 +canInitWithRequest: 中，如果返回 YES ，该请求就会被其控制。返回 NO 则直接跳入下一 Protocol 。

NSURLProtocol提供方法允许你来添加、获取、删除一个 request 对象的任意 metadata ，而且不需要私有扩展或者方法欺骗 (swizzle) ：

 

 

在操作 protocol 时对尚未赋予特定信息的 NSURLRequest 进行操作时，上述方法都是特别重要的。这些对于和其他方法之间的状态传递也非常有用。

。

向 URL 加载系统注册子类

最后，为了使用  NSURLProtocol  子类，需要向 URL 加载系统进行注册。

当请求被加载时，系统会向每一个注册过的 protocol 询问：“ Hey 你能控制这个请求吗？”第一个通过 +canInitWithRequest: 回答为 YES 的 protocol 就会控制该请求。 URL protocol 会被以注册顺序的反序访问，所以当在 -application:didFinishLoadingWithOptions: 方法中调用 [NSURLProtocol registerClass:[MyURLProtocol class]]; 时，你自己写的 protocol 比其他内建的 protocol 拥有更高的优先级。

 

 

 

NSURLCache  为您的应用的 URL 请求提供了内存中以及磁盘上的综合缓存机制。 作为基础类库 URL 加载系统 的一部分，任何通过 NSURLConnection 加载的请求都将被 NSURLCache  处理。

网络缓存减少了需要向服务器发送请求的次数，同时也提升了离线或在低速网络中使用应用的体验。

当一个请求完成下载来自服务器的回应，一个缓存的回应将在本地保存。下一次同一个请求再发起时，本地保存的回应就会马上返回，不需要连接服务器。 NSURLCache 会 自动 且 透明 地返回回应

 

NSURLRequestCachePolicy，以下才是你 实际  需要了解的东西：

UseProtocolCachePolicy 默认行为

ReloadIgnoringLocalCacheData 不使用缓存

ReloadIgnoringLocalAndRemoteCacheData 我是认真地，不使用任何缓存

ReturnCacheDataElseLoad 使用缓存（不管它是否过期），如果缓存中没有，那从网络加载吧

ReturnCacheDataDontLoad 离线模式：使用缓存（不管它是否过期），但是不从网络加载

ReloadRevalidatingCacheData 在使用前去服务器验证

 

 

-connection:willCacheResponse: 中， cachedResponse  对象会根据 URL 连接返回的结果自动创建。因为 NSCachedURLResponse 没有可变部分，为了改变 cachedResponse  中的值必须构造一个新的对象，把改变过的值传入 –initWithResponse:data:userInfo:storagePolicy:

 

如果不实现此方法， NSURLConnection 就简单地使用本来要传入 -connection:willCacheResponse: 的那个缓存对象，所以除非你需要改变一些值或者阻止缓存，否则这个代理方法不必实现。