首先网络层的基础组件应该是AFNetworking 大部分开发人员都是基于AFNetworking的二次封装，比较知名的就是CTNetWork和YTKNetwork，阅读完源码，我认为和我们的实际业务需求不符合，我认为一个好的网络层，应该还有以下特点
- 简单，易懂的代码
- 日志输出
- 缓存应该采用lru算法，因为一个开发人员不清楚用户具体喜欢哪些内容，只能做重要界面的所有的缓冲，然而用户可能某时间基于好奇心会点击APP内大部分界面和造成大量缓冲，这种资源浪费是没必要，所以个人感觉要清除命中率不高的缓存
- 取消网络请求
下面谈一下比较知名的CTNetworking和YTKNetwork
在 Casa Taloyum大神 iOS应用架构谈 网络层设计方案 的内容文章里面，谈论的两大问题就是block和代理 集约型和离散型的技术点讨论
Casa Taloyum讨论了block的在网络层使用的时候缺点
block很难追踪，难以维护
block会延长相关对象的生命周期
block在离散型场景下不符合使用的规范
集约型存在的问题
原因1：当前请求正在外面飞着的时候，根据不同的业务需求存在两种不同的请求起飞策略：一个是取消新发起的请求，等待外面飞着的请求着陆。另一个是取消外面飞着的请求，让新发起的请求起飞。集约化的API调用方式如果要满足这样的需求，那么每次要调用的时候都要多写一部分判断和取消的代码，手段就做不到很干净。
原因2：便于针对某个API请求来进行AOP。在集约型的API调用方式下，如果要针对某个API请求的起飞和着陆过程进行AOP，这代码得写成什么样。。。噢，尼玛这画面太美别说看了，我都不敢想。
离散型的优点
原因3：当API请求的着陆点消失时，离散型的API调用方式能够更加透明地处理这种情况。
原因4：离散型的API调用方式能够最大程度地给业务方提供灵活性，比如reformer机制就是基于离散型的API调用方式的。另外，如果是针对提供翻页机制的API，APIManager就能简单地提供
loadNextPage方法去加载下一页，页码的管理就不用业务方去管理了。还有就是，如果要针对业务请求参数进行验证，比如用户填写注册信息，在离散型的APIManager里面实现就会非常轻松。
笔者认为“尺有所短寸有所长”每个事物都有他的优点和缺点，可能在某一类环境下A的优点多，某一类环境下B的有点多了，这个问题只是相对的，例如在计算机当中，要么用空间换时间，要么时间换空间，鱼和熊掌不可兼的。
block优点：
省去了写代理的很多代码
2.block 更轻型，使用更简单，能够直接访问上下文，这样类中不需要存储临时数据，使用 block 的代码通常会在同一个地方，这样能连贯读代码
block缺点：
1.block不够安全，使用 block 时稍微不注意就形成循环引用，导致对象释放不了。这种循环引用，一旦出现就比较难检查出来。
2.block效率低，block出栈需要将使用的数据从栈内存拷贝到堆内存 3.在多个通信事件的时候，block显得不够直观也不易维护。
delegate优点：
1.delegate更安全， delegate 的方法是分离开的，不会引用上下文，不容易循环引用
2.delegate效率高，delegate只是保存了一个对象指针
3.在多个通信事件的时候，delegate显得直观也易维护。
delegate缺点：
1.因方法的声明和实现分离开来，代码的连贯性不是很好，没有 block 好读
2.很多时候需要存储一些临时数据 ------------
笔者崇尚于更轻型，更简单，更连贯的代码，所以笔者在封装SJNetwork的时候采用的是Block，佛家云：有所舍，才能有所得。
indulge_in 大神 认为CTNetworking 不足：
使用 IOP 方式建立模块，化继承为组合。独立
<CTServiceProtocol>和<CTAPIManagerInterceptor>等协议作为集约管理部分，若个别接口需要修改这些公共配置，只能在集约管理模块来判断，显得有一点繁琐。记录了一个 request 实例的所有 task，在 dealloc 中自动取消掉还未降落的网络请求，但是实际上网络请求任务会持有 request，所以自动取消策略不成立了。
YTKNetwork 不足：
基于多态的设计思路，提供了很多供重载的方法，从设计来看，框架是可以实例化
YTKBaseRequest子类 直接使用的，那么直接使用时无法重载这些方法专门定制（个人看来有些地方使用属性更灵活）；并且，当一个 reqeust 多次start发起请求就会调用多次这些重载方法，可能造成多余计算；缓存策略使用一个
YTKBaseRequest的子类YTKRequest来做，虽然这样看起来比较优雅，父类和子类各司其职，单一职责，但是缓存策略难免会更改父类的逻辑，如此就很难不违背开闭原则。框架的缓存只有一个失效时间控制，笔者想要拓展时发现要改的东西太多。同一个 request 实例多次 start 调用网络请求时 (多个网络请求并发情况)，并未作出实际的处理策略，仅保留最新的
NSURLSessionTask，而对旧的未结束的所有NSURLSessionTask丧失了控制权。网络请求任务强持有所有 request 对象，在弱网环境下可能会有大量 request 对象无法释放，而界面降落点可能不存在了。
CTNetworking
可读性比YTKNetwork好
CTJsbridge已经可以跟CTNetworking交互，H5工程师可以很方便地使用基于CTNetworking的网络API。
各种错误错误类型回调比较全
YTKNetwork
可能是使用了命令模式的原因吧，我觉的YTKNetwork的可读性不如CTNetworking 个人觉的不管用什么设计模式，为的是代码逻辑更加明确，代码更加易懂易读，如有不认同笔者的，请忽略，毕竟人生百味，请允许我有百想，
YTKNetwork和CTNetworking的日志输出，缓冲，取消网络请求，当我们使用的时候还的进行网络的三次封装，笔者认为，一个网络层设计，应该是都封装进去，然后提供开发人员调用就可以了，
SSJNetWork封装缓冲，日志，自动网络请求。
1.缓存处理
缓存处理配置都在SJNetWorkConfig和SJNetworkRequestConfig类中，支持以下配置：
- 内存/磁盘存储方式
- 缓存的有效时长
- 根据请求shouldAllIgnoreCache判断是否需要缓存
- 以及直接配置 YYCache
- 支持缓冲最大数量（采用YYCache LRU算法）
- 缓存的版本
2. 自动取消网络请求
采用AOP方式hook方式自动取消网络请求
请配置 SJNetworkRequestConfigz 中 className 如不传入参数网络请求对应vc的className,则自动取消网络请求无效
半自动取消网络请求根据的的是，视图pop和dismiss的时候取消当前VC下所有的网络请求设计的
3.采用NetworkEye部分代码可以监控App内所有HTTP请求并显示请求相关的所有信息，方便App开发的网络调试
SJNetWorkConfig`变量配置，
dubugLogeEnable：请求完成控制台直接输出
SQLLogEnable:记录在sql提高跳转到vc的时候展示
ne_sqlitePassword：log日志数据库密码
ne_saveRequestMaxCount：保存请求的最大个数
源码地址 请点击这里，欢迎大神指导，若考虑不周的地方，请大家多提意见
