基于AFNetworking 3.0的取消已发出的网络请求
一般情况下主动取消请求的需求不会太多
除非以下几种情况
1.比如电商应用为例 请求频繁,数据量大
2.对性能的要求比较高
3.网络环境比较差
当一个用户打开一个界面 看到的却是漫长的等待框 这时候用户很可能退出当前界面 浏览其他界面。再以上几种情况下 我们有必要做网络资源的控制。当一个请求发送以后,没必要等他的结果的时候我们就应该主动取消请求。
主动取消请求不仅节省了网络资源 ,还可以避免block引用VC导致的延迟内存释放问题。现在很多网络框架都支持这种操作,只要你拿到请求队列随时可以发起/取消请求。为了操作队列我们会VC里持有队列,设计角度上每个需要请求的VC都持有若干个队列,而且手动的取消请求 显得特别麻烦。
我这边设计的主要思路是:
通过类别来动态管理请求队列,避免VC直接持有请求队列。
通过runtime来自动触发取消请求操作。
下面是代码
AFHTTPSessionManager *session = [AFHTTPSessionManager manager];
for(int i =0 ; i < 10 ; i++) {
NSURLSessionDataTask *dataTask = [session GET:@"https://api.github.com/users/facebook" parameters:@[] progress:^(NSProgress * _Nonnull downloadProgress) {
} success:^(NSURLSessionDataTask * _Nonnull task, id _Nullable responseObject) {
[self removeTask:task];
} failure:^(NSURLSessionDataTask * _Nullable task, NSError * _Nonnull error) {
[self removeTask:task];
}];
[self addTask:dataTask];
}
下面是类别方法
下面来看下 取消请求的代码段
我这边是用runtime 再一个VC消失的时候触发了取消请求操作
//类别方法取消请求
操作runtime 用了开源
import"Aspects.h"
这只是思路 字典的存取没做线程安全控制 可以改进很多地方
如果不是每一个VC都有这种需求,可以通过维护特定的VC列表来 避免所有的VC做判断。
现在看来我们每个VC 没有做额外的工作 只是添加删除队列 就可以完成界面消失的时候自动取消请求的需求。
==============推广=================
我有故事你有酒吗?
我有酒 ,而且只有酒 ,因为我穷得只剩酒。
北上广里有故事,有梦想,有爱情 ,有八卦,有生活。
来[北上广]听听他们的故事吧
下载IOS版本:http://7x2x43.com1.z0.glb.clouddn.com/bsgwbtt.html
或者appStore 搜北上广
[北上广]-献给专注实现梦想的你