剑客
关注科技互联网

iOS网络请求在Controller退出后是否应该被取消?

一个编写iOS代码的经典场景:用户进入某个Controller,发起Http网络请求从Server获取数据,在数据返回之前用户退出了Controller。此时是否需要Cancel之前发出的网络请求呢?

如果请求的数据只在当前Controller产生内容,结论当然是需要Cancel,虽然我知道不少iOS程序员因为偷懒而忘了取消。我们用工程的思维,深入本质,一起看下这背后都发生了什么,如果不Cancel会有哪些副作用。

我们可以把一个Http请求分为这几步:

第一步:三次握手

这一步会有三个packet产生,sync,sync+ack,ack。

第二步:客户端发送Http的request

此处根据请求类型产生的packet数量会有差异。

第三步:客户端接收Server的Http Response

根据Response的大小,产生的packet数量不相同,一般一个packet在1.5KB左右。

通过代码查看测试样本

我们在Demo项目中运行如下代码,再配合tcpdump抓包看看背后究竟发生了什么?

NSURLSessionConfiguration *configuration = [NSURLSessionConfiguration defaultSessionConfiguration];
    AFURLSessionManager *manager = [[AFURLSessionManager alloc] initWithSessionConfiguration:configuration];
    
    NSURL *URL = [NSURL URLWithString:@"http://httpbin.org/get"];
    NSURLRequest *request = [NSURLRequest requestWithURL:URL];
    
    NSURLSessionDataTask *dataTask = [manager dataTaskWithRequest:request completionHandler:^(NSURLResponse *response, id responseObject, NSError *error) {
        if (error) {
            NSLog(@"Error: %@", error);
        } else {
            NSLog(@"%@ %@", response, responseObject);
        }
    }];
    [dataTask resume];
sudo tcpdump -i rvi0 -AAlnn src 23.22.14.18 or dst 23.22.14.18

下图是tcpdump获取的结果:

iOS网络请求在Controller退出后是否应该被取消?

  • 图中标号1,2,3表示的tcp三次握手。
  • 标号4是客户端发送Http Get,标号5是Server Ack。
  • 标号6是Server Response。

后面还有几个断开tcp连接的包被我省去了,前面这6个packet足以说明问题了。

上述三步中,前两步消耗的是用户上行的流量,第三步用的下行的流量。国内移动运营商对于上行和下行的流量都算在包月的总流量当中的,所以如果用户在第六个或者之后的Packet没有返回之前退出Controller的话,后续的Packet依然会通过连接,走下行通道,抵达我们的客户端,耗费用户的流量,Response往往还是一个请求的流量大头。

如果我们在请求返回之前,调用Cancel:

[dataTask cancel];

取消请求的话,客户端会发送如下一个Reset Packet断开当前的Http连接,阻止后续的流量产生:

iOS网络请求在Controller退出后是否应该被取消?

所以结论是:如果不Cancel,请求完成之后通过回调找到delegate,如果是weak引用,Controller被释放,delegate变为nil,业务流程被中断,代码还算安全。但是会的的确确浪费一些用户流量。养成好习惯,自己产生的垃圾自己清理哦。

欢迎关注公众号:

iOS网络请求在Controller退出后是否应该被取消?

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址