NSURLSessionTask 在 WiFi 关闭时从不回调答案

【问题标题】：NSURLSessionTask Never Calls Back When WiFi OffNSURLSessionTask 在 WiFi 关闭时从不回调
【发布时间】：2017-07-10 05:35:42
【问题描述】：

当我关闭 WiFi 连接并在 iPhone 6s 10.2 模拟器上运行以下代码时，从未执行回调。我预计回调会很快触发，并出现“无 Internet 连接”之类的错误。

NSLog(@"request-start");
NSURLRequest* request = [[NSURLRequest alloc] initWithURL:[NSURL URLWithString:@"https://www.google.com"] cachePolicy:NSURLRequestUseProtocolCachePolicy timeoutInterval:0];
task = [[NSURLSession sharedSession] dataTaskWithRequest:request completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) {
    NSLog(@"request-end");
}];
[task resume];

我的问题

我在应用首次加载时获取数据。如果wifi被关闭，我需要显示一个错误。如果我设置了超时，它会被遵守 - 但它需要超过 10 秒，我不想让他们等待。我也试过用可达性检测网络状态，但是第一次加载应用时网络状态通常是unknown。

【问题讨论】：

这可能是因为您使用了共享会话吗？
“但它需要 10 多秒，我不想让他们等待”。我不明白，如果您的连接需要 10 秒才能收到响应，您为什么不设置超时？您需要设置超时来处理连接错误和超时。即使“wifi 已开启”并不意味着连接将 100% 正常工作。您不应专注于“让人们等待”，而应相应地处理错误和用户界面，以便在连接花费的时间超出预期时向您的用户显示进度信息栏。
@matt - 我不确定 - 我试过 defaultSessionConfiguration 和 ephemeralSessionConfiguration 并得到了相同的结果
@Sneak - 我在实际项目中确实有超时，如果连接速度很慢，我不介意让他们等待。但如果没有 wifi，那么我宁愿不让他们等待完全超时 - 比如 ajax/browsers/curl/etc

标签： ios ios-simulator nsurlsession nsurlsessiontask

【解决方案1】：

timeoutIntervalForResource

该属性决定了所有任务的资源超时间隔在基于此配置的会话中。资源超时间隔控制等待整个资源的时间（以秒为单位）在放弃之前转移。资源计时器在请求已启动并计数直到请求完成或达到此超时间隔，以先到者为准。

默认值为 7 天。

和

timeoutIntervalForRequest

重要

后台会话创建的任何上传或下载任务如果原始请求由于以下原因而失败，则会自动重试暂停。配置上传或下载任务的时长允许重试或转移，使用 timeoutIntervalForResource 属性。

默认值为 60。

因此，如果没有设置超时，您的连接将运行 7 天。

一般来说，一个 NSURLSession 后台会话不会使任务失败，如果电线出了问题。相反，它继续寻找那时运行请求并重试的好时机。这继续直到资源超时到期（即 NSURLSessionConfiguration 中的 timeoutIntervalForResource 属性用于创建会话的对象）。当前的默认值值是一周！

Source

【讨论】：

谢谢@Sneak。我没有意识到它是故意设计为“等待重试请求的好时机”。有没有方法可以在不等待重试的好时机提出请求？
@bendytree 您唯一的选择是：stackoverflow.com/questions/7938650/ios-detect-3g-or-wifi/…，但是，Apple 的最佳实践和指南是在遇到连接错误之后检查可访问性，以显示适当的信息，而不是您提出的每个请求。但是，我不知道您的用例是什么，这就是您所需要的我的朋友。 GL，顺便说一句，无论如何，您都应该设置超时以避免遇到奇怪的东西。
感谢您的帮助。基本上，当显然没有连接时，我不希望用户等待完全超时（即使只有 10 秒）。我想这在 iOS 上是不可能的。
@bendytree 对于这里和那里的单个请求，使用上述链接解决方案应该没有任何问题。但是，如果您正在处理许多请求等，则没有直接的方法可以消除超时错误的需要。但是，您可以添加一个可访问性观察者来检测更改，请检查：stackoverflow.com/questions/20919244/…，但请记住，没有什么是 100% 保证的。你可以试试看。