$.ajax({
//其他参数已省...
timeout:5000, //超时时间,考虑到网络问题,5秒还是比较合理的
complete:function(XHR,TextStatus){
if(TextStatus=='timeout') //超时啦,干点什么呗
}
})
如果你用的 AFNetworking
- (NSMutableURLRequest *)requestWithMethod:(NSString *)method path:(NSString *)path parameters:(NSDictionary *)parameters//方法通过添加
[request setTimeoutInterval:10.0]
如果是 ASIHTTPRequest
[request setNumberOfTimesToRetryOnTimeout:2]NSMutableURLRequest是NSURLRequest的子类,常用方法有
设置请求超时等待时间(超过这个时间就算超时,请求失败)
NSMutableURLRequest *urlRequest = [[NSMutableURLRequestalloc] initWithURL:url cachePolicy:NSURLRequestUseProtocolCachePolicytimeoutInterval:10] NSURLConnection *_connection = [[NSURLConnectionalloc] initWithRequest:urlRequest delegate:selfstartImmediately:YES]一个用来创建请求,一个用来将请求发送出去。然后我们实现 NSUrlConnectionDelegate 的几个回调函数就能完成整个流程了。
一般发送网络请求都会去设置一个超时时间,防止请求在那一直等待。根据不同的场景,我们还需要设置不同的超时时间。在上面的代码中我们设置了10秒超时。
上面的故事看起来很完美。但是 apple的开发人员在这里给我们挖了一个坑。
如果你的请求是个简单的“Get”请求,或者木有 body的“post”请求。一切都是那么完美,请求能够按照我们设定的时间自动超时。但是如果你发的是个“POST”请求,并且[urlRequest setHTTPBody:httpBody]那么,不好意思,你被潜规则了。
ios3.0 以后 苹果的sdk对这种情况做了调整,如果是post请求,并且设置了 httpBody,那么请求的超时时间就被默认设置为 240 秒了。就算你再使用[urlRequest setTimeoutInterval:10]也是无效的,我们可以再设置完成后再读取这个值,发现它不会变成10,依然保持240秒。于是乎,网络不稳定的时候,你的程序就可能会陷入漫长的等待。
发现这个问题后。我们通过自己起timer的方式来控制超时。具体怎么弄这里就不细说。只说下我们的策略。
我们将整个网络过程分为 链接建立,发送数据,数据发送完成等待回包,接收数据 4个阶段来控制具体的超时。
设置我们的标准超时时间为 N (系统默认为 10秒,网络模块通过暴露相关接口,调用方可自由设置)
链接建立链接超时时间: N * 1.5
每数据包发送超时时间: N * 1.5
数据发送完成等带回包超时: N * 2
每数据包接收超时时间: N * 1
以上超时分别在 NSUrlConnectionDelegate 的各个回调阶段进行相关设置就能达到比较精细的控制。
特别说明下,为什么数据发送完成后等待回包的超时会设置的比较长。因为在实际测试过程中发现发包完成到接收到第一个数据包比较耗时,一般httpbody越大越明显,初步猜测是网络模块在发送数据缓冲区的数据,所以这里做了特殊的控制。
部分内容来自于博客园《NSURLCONNECTION 网络超时的那些事。》
先声明,我不知道如何解决这个问题,但我想提一些建议。需要4、5分钟的 *** 作我不清楚具体是什么,如果是单纯的数据库 *** 作之类的这个设计就有问题;如果是数据量十分大的 *** 作那么应该考虑缓存、预处理等。
还有,你可以发送数据请求到后台,后台接收后便立即返回调用成功,然后把4,5分钟的 *** 作放到另一个线程里去做,然后对每一次的请求后台都做一个静态的唯一标识,然后把标识返回前台,然后4,5分钟之后前台通过这个标识去后台找结果,或者不确定 *** 作所需时间就缩短轮询的间隔,比如每30秒一请求,后台 *** 作不完成便继续等待下一次请求。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)