2.delegate效率高，delegate只是保存了一个对象指针3.在多个通信事件的时候，delegate显得直观也易维护。

delegate缺点：1.因方法的声明和实现分离开来，代码的连贯性不是很好，没有 block 好读

2.很多时候需要存储一些临时数据

------------

笔者崇尚于更轻型，更简单，更连贯的代码，所以笔者在封装SJNetwork的时候采用的是Block，佛家云：有所舍，才能有所得。

indulge_in 大神 认为CTNetworking 不足：

使用 IOP 方式建立模块，化继承为组合。独立和等协议作为集约管理部分，若个别接口需要修改这些公共配置，只能在集约管理模块来判断，显得有一点繁琐。

记录了一个 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：保存请求的最大个数