基于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];
}

下面是类别方法

Paste_Image.png

下面来看下 取消请求的代码段

我这边是用runtime 再一个VC消失的时候触发了取消请求操作

Paste_Image.png

//类别方法取消请求

Paste_Image.png

Paste_Image.png

操作runtime 用了开源

import"Aspects.h"

这只是思路 字典的存取没做线程安全控制 可以改进很多地方

如果不是每一个VC都有这种需求，可以通过维护特定的VC列表来 避免所有的VC做判断。

现在看来我们每个VC 没有做额外的工作 只是添加删除队列 就可以完成界面消失的时候自动取消请求的需求。

==============推广=================

我有故事你有酒吗？

我有酒 ,而且只有酒 ,因为我穷得只剩酒。

北上广里有故事,有梦想,有爱情 ,有八卦,有生活。

来[北上广]听听他们的故事吧

下载IOS版本:http://7x2x43.com1.z0.glb.clouddn.com/bsgwbtt.html

或者appStore 搜北上广

[北上广]-献给专注实现梦想的你