在ios平臺上做網(wǎng)絡開發(fā)最常用的兩個類：

NSMutableURLRequest?*urlRequest = [[NSMutableURLRequestalloc] initWithURL:url cachePolicy:NSURLRequestUseProtocolCachePolicytimeoutInterval:10];? NSURLConnection?*_connection = [[NSURLConnectionalloc] initWithRequest:urlRequest delegate:selfstartImmediately:YES];

?

? ?一個用來創(chuàng)建請求，一個用來將請求發(fā)送出去。然后我們實現(xiàn)?NSUrlConnectionDelegate 的幾個回調(diào)函數(shù)就能完成整個流程了。

? ?一般發(fā)送網(wǎng)絡請求都會去設置一個超時時間，防止請求在那一直等待。根據(jù)不同的場景，我們還需要設置不同的超時時間。在上面的代碼中我們設置了10秒超時。

? ?上面的故事看起來很完美。但是 apple的開發(fā)人員在這里給我們挖了一個坑。

如果你的請求是個簡單的“Get”請求，或者木有 body的“post”請求。一切都是那么完美，請求能夠按照我們設定的時間自動超時。但是如果你發(fā)的是個“POST”請求，并且[urlRequest setHTTPBody:httpBody]; 那么，不好意思，你被潛規(guī)則了。

? ?ios3.0 以后 蘋果的sdk對這種情況做了調(diào)整，如果是post請求，并且設置了 httpBody，那么請求的超時時間就被默認設置為 240 秒了。就算你再使用[urlRequest?setTimeoutInterval:10];也是無效的，我們可以再設置完成后再讀取這個值，發(fā)現(xiàn)它不會變成10，依然保持240秒。于是乎，網(wǎng)絡不穩(wěn)定的時候，你的程序就可能會陷入漫長的等待。

? ?發(fā)現(xiàn)這個問題后。我們通過自己起timer的方式來控制超時。具體怎么弄這里就不細說。只說下我們的策略。

我們將整個網(wǎng)絡過程分為 ?鏈接建立，發(fā)送數(shù)據(jù)，數(shù)據(jù)發(fā)送完成等待回包，接收數(shù)據(jù) 4個階段來控制具體的超時。

設置我們的標準超時時間為 N （系統(tǒng)默認為 10秒，網(wǎng)絡模塊通過暴露相關接口，調(diào)用方可自由設置）

? ? 鏈接建立鏈接超時時間： ? ?N * 1.5

? ? 每數(shù)據(jù)包發(fā)送超時時間： ? ?N * 1.5

? ? 數(shù)據(jù)發(fā)送完成等帶回包超時： N * 2

? ? 每數(shù)據(jù)包接收超時時間： ? ?N * 1

以上超時分別在?NSUrlConnectionDelegate 的各個回調(diào)階段進行相關設置就能達到比較精細的控制。

特別說明下，為什么數(shù)據(jù)發(fā)送完成后等待回包的超時會設置的比較長。因為在實際測試過程中發(fā)現(xiàn)發(fā)包完成到接收到第一個數(shù)據(jù)包比較耗時，一般httpbody越大越明顯，初步猜測是網(wǎng)絡模塊在發(fā)送數(shù)據(jù)緩沖區(qū)的數(shù)據(jù)，所以這里做了特殊的控制。

哦了。羅嗦了半天，終于說完了。希望能對大家有幫助。能跳過這個坑。

總結

以上是生活随笔為你收集整理的NSURLConnection超时大坑的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。