谈谈 iOS 网络层设计（SSJNetWork封装缓冲，log日志，自动取消网络请求）

首先网络层的基础组件应该是AFNetworking 大部分开发人员都是基于AFNetworking的二次封装，比较知名的就是CTNetWork和YTKNetwork，阅读完源码，我认为和咱们的实际业务需求不符合，我认为一个好的网络层，应该还有如下特色

1. 简单，易懂的代码 
2. 日志输出
3. 缓存应该采用lru算法，由于一个开发人员不清楚用户具体喜欢哪些内容，只能作重要界面的全部的缓冲，然而用户可能某时间基于好奇心会点击APP内大部分界面和形成大量缓冲，这种资源浪费是不必，因此我的感受要清除命中率不高的缓存
4. 取消网络请求

下面谈一下比较知名的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方式自动取消网络请求

swizzling_exchangeMethod([self class],@selector(popViewControllerAnimated:), @selector(ssj_popViewControllerAnimated:));
swizzling_exchangeMethod([self class],@selector(popToRootViewControllerAnimated:), @selector(ssj_popToRootViewControllerAnimated:));
swizzling_exchangeMethod([self class],@selector(popToViewController:animated:), @selector(ssj_popToViewController:animated:));
swizzling_exchangeMethod([self class],@selector(dismissViewControllerAnimated:completion:), @selector(ssj_dismissViewControllerAnimated:completion:));
复制代码

请配置 SJNetworkRequestConfigz 中 className 如不传入参数网络请求对应vc的className,则自动取消网络请求无效

自动取消网络请求根据的的是，视图pop和dismiss的时候取消当前VC下全部的网络请求设计的

3.日志输出，采用NetworkEye部分代码能够监控App内全部HTTP请求并显示请求相关的全部信息，方便App开发的网络调试

SJNetWorkConfig`变量配置，

dubugLogeEnable：请求完成控制台直接输出

SQLLogEnable:记录在sql提升跳转到vc的时候展现

ne_sqlitePassword：log日志数据库密码

ne_saveRequestMaxCount：保存请求的最大个数

源码地址  请点击这里，欢迎大神指导，若考虑不周的地方，请你们多提意见