谈谈 iOS 网络层设计

孙杰同志 2019-04-30 09:38:55 1847

首先网络层的基础组件应该是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优点:

    • 1.省去了写代理的很多代码

    • 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 方式建立模块,化继承为组合。独立等协议作为集约管理部分,若个别接口需要修改这些公共配置,只能在集约管理模块来判断,显得有一点繁琐。

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

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

    作者:孙杰同志
    链接:https://juejin.im/post/5cb58e516fb9a068b16e1627