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