最近一直在想一些烧脑的逻辑问题。
在此之前,我们抛出了一个网络请求框架,在这个框架中,能够很清晰的管理每一个请求,每一个回应,以及统一处理,特殊处理等,但对于开发人员来讲,这只是一个easy的文件目录而已。
目前这个框架仍然存在很多问题,例如请求重发机制有待优化,不支持冻结网络请求,还有在页面销毁时,不支持取消未完成的请求(ps:一次性取消所有请求,但这不是我希望的效果)
先说说从新手以来对于网络请求管理这块的理解过程:
说一下,我们讨论的前提是,希望无关请求都会正常cancel。
1. 统一单例类,管理所有请求
该方法,提供一个单例类,还有几个请求API接口,然后在工程中任何需要网络请求的地方使用,加上url,相关参数以及callback,而且内部的核心代码也是直接与AFNetworking处理,方便快速,但是对于成百上千(这个数字可能会越来越大)的服务端接口来说,不易管理。
而且在取消全部请求的时候会出现一些意想不到的问题
举个栗子
1 | A页面push B页面 |
request:
直接调用
response:
统一处理
cancel:
取消全部请求
如下图
2.统一非单例类,分管请求
这种方法,创建一个类,每次调用请求的时候都new一个新的实例,然后由vc持有,这样做便于在页面dealloc时,直接取消当前页面发出的所有请求。请求管理类似于,谁请求,谁负责cancel。
很明显,这种方法大大增加了系统的开销,而且不符合设计思想,虽然可以方便的取消自己管理的请求,但是不支持取消全部请求。如果要支持取消全部请求的话,还需要一个管理类来管理管理请求的管理类,这样的话整个目录看起来横七竖八。
由于对回调的统一处理也是独立的,所以也会存在部分需求不满足的问题
举个栗子
1 | 需求中存在token过期的问题 |
request:
创建新的实例,直接调用
response:
单独统一处理
cancel:
持有者取消独自管理的全部请求
3.统一单例类,分管请求
分管请求有很多种,例如可以根据功能、接口、或者页面属性来独自管理有共同特点的请求。
这里的独自管理,其实无非就是给请求加了一个标签,便于管理请求的时候,可以按照某一共同特征来管理。相比较第一种形式,他的优势在于可以按需求取消部分请求,比如在某个页面dealloc的时候,按照页面名称,取消请求队列中有关当前页面所有未完成的请求。
举个栗子
1 | 首先支持按照标签取消请求 |
request:
直接调用
response:
统一处理
cancel:
取消全部请求同时支持按照tag取消
开源框架结构简析
1、YTKNetwork
上面的截图来自YTKNetwork的设计框架,将服务端每个api也做简单的封装处理(例如图中的RegisterApi),使用起来很舒服,但是这样写下去,需要些成百上千个.h.m,想想都觉得不可思议,当然这只是一种设计模式,方便开拓使用者更广泛的思路。
我在工程中的做法都是根据功能,将服务端的api做了分类,接口中保留了服务端需要的info,由调用者填充即可。如下图
有兴趣的朋友可以下载我的Demo捋一捋。
2、MGJRequestManager
虽然这个框架仅有两个文件,但是功能很强大,而且支持缓存,用起来如图,我们可以简单的把他当做一个请求类来使用,最好还是配合YTK的模式,封装好请求和回应,接口统一管理,这样用起来才不失效率。
截图来自:
JZNetworkSingleton
开源框架参考:
YTKNetwork
MGJRequestManager
看完YTK的框架设计,框架越复杂,功能越强大,用起来越方便
欢迎大家与我交流!!!
本站文章如无其他特殊说明,均为原创,转载请注明出处。