IOS網絡連接失敗的政策建議

Question

我要找的建議，來處理iPhone應用程序（iOS9/Swift2/Xcode7）網絡連接問題，提供最好的用戶體驗，因爲我們知道，移動數據網絡是最好的方式不可靠的。我有我的編碼選項，但我想知道其他有經驗的技術人員的工作情況。這裏有很多信息，但沒有什麼我可以找到特定於在發生連接失敗時發生的策略。

這是我對付失敗的連接基本策略，我想實現（與問題）：

1. 應用程序發送請求api.myserver.com，請求失敗
2. 等待X秒（S）和嘗試要求再次api.myserver.com（多少次嘗試，並在什麼時間間隔你會建議？）
3. 嘗試ping一些其他的服務器（即google.com），看看我們是否可以訪問其他資源比api.myserver.com
4. 如果我們可以ping google.com然後w Ë知道我們的互聯網是工作，所以如果這最後ping失敗然後我們提醒，我們不能因爲某種原因通信，並稍後再試

用戶我們再次嘗試ping api.myserver.com

我使用蘋果技術，這在一般意味着你隨時檢查您的服務器的連接首先，使用可達性作爲一個獨立的檢查，以保證手機的硬件可推薦this SO answer列出的理念。

在過程中如果可以訪問是假，則我們會把我們的請求隊列中的這個過程中隨時可以再次嘗試恢復手機硬件連接時。

我想我已經得到了所涉及的代碼手柄，但尋找像見解：「這是什麼工作對我們的應用程序，並給出了在連接問題的良好的用戶體驗......，並獲准在蘋果應用應用商店...」。我理解在出現故障時嘗試/重試連接並提醒用戶（目前我的代碼已成功執行此操作）的概念，但仍然不適用於我應該嘗試重新連接多次的良好策略以及間隔？

Answer 1

對於大多數我已經在這工作的應用程序是定義了幾個具有不同規則的請求類別的有用。對於每個類別，考慮重試是否合適，以及在考慮請求失敗之前可以等待多久。

1. 最敏感的是阻塞請求，用戶必須允許它們在完成之前完成的事情。登錄，簽出，編輯操作等等。對於這些，通常不值得重試（1），並且需要立即向用戶傳達故障：如果設備處於脫機狀態，讓用戶決定何時再次嘗試，如果請求失敗了，你可能已經讓用戶等待了太久。由於失敗往往會阻礙用戶，所以他們通常也需要突出溝通。
2. 較不敏感的通常是使用啓動但不阻止的操作：拉到刷新，加載所選集合項目的詳細信息或執行搜索。您的用戶可能會等待查看結果，但可能可以免費放棄或在應用中的其他位置導航，稍後再回來查看。故障仍然需要傳達，以便用戶可以選擇重試或至少知道停止等待，但通知這些故障可能不那麼突出。這裏重試開始有意義。我通常首先嚐試從用戶的角度定義時間限制，在應用程序感覺中斷之前等待多長時間，然後讓這成爲請求可以等待連接多長時間的限制或對響應進行任何次數的重試連接失敗。
3. 更不敏感的是僅由用戶間接觸發的請求;輪詢更新，加載非必要的圖像，加溫緩存。這些你可能會重試，但失敗的影響往往很低，以至於無關緊要。

在所有這些請求中，您的重試策略實際上只會影響＃2，所以我會確保您在擔心此類問題之前確實獲得了該類型的請求。假設這些其實也適用於應用...

等待X秒，並嘗試要求再次api.myserver.com（多少次嘗試，並在什麼時間間隔你會建議？）

我會在這裏設置一些時間間隔（幾十到幾百毫秒，取決於你的正常api性能），以避免意外的請求氾濫。當我沒有一個確切的理由時，我不想提出一個確切的數字。

我的經驗是，優化這個值不會給你的用戶帶來明顯的差異，因爲請求通常需要幾百毫秒的時間才能失敗，用戶只願意等待幾千毫秒，因此可以創建1或5或10那時候的要求並沒有真正改變最終的結果。如果您能夠爲用戶設定不同的期望，那麼您的結果可能會有所不同。

嘗試ping一些其他的服務器（即google.com），看看我們是否可以訪問其他的資源比api.myserver.com 如果我們能夠成功地ping google.com那麼我們就知道我們的互聯網是工作，所以我們再次嘗試ping api.myserver.com

我不會認爲這是事實，我也不認爲向第三方發出額外請求將幫助您做出有關何時嘗試觸及的有用預測你自己的系統。這似乎是構建和維護的額外工作，可能會成爲誤導性結果的來源而非有價值的信息。你認爲這是什麼情況爲你的應用程序或其用戶提供了有用的信息？

也許不是你正在尋找的答案，但希望它仍然有用。

---

聲明：我的經驗偏向於具有相當簡單的一組REST或RPC樣式的網絡請求的應用程序。如果您正在處理一個需要流式傳輸數據，P2P連接或其他場景的問題，則不要從這些假設開始。

（1）這裏最後要說明一點，因爲我經常把它看作失敗的根源：這些請求應該是冪等的。是的，即使那些POST創建新的資源，檢查您的購物車，或任何其他。當您無法安全地重複請求時，您最終會看到請求已完成但客戶端從未收到確認的情況，因此看起來像是失敗。通過對相同請求進行重試（自動或用戶觸發）來恢復比從重複請求中檢測和恢復要容易得多。

Answer 2

爲了更好的網絡性能。在我的應用程序中，如果可以訪問API請求，我會在每個API請求之前ping Google服務器，然後我調用我的服務器API，否則不會發出網絡警報。

如果您的WiFi網絡上的時候，你也必須做同樣的，因爲無線網絡的可達性只有WiFi連接檢查沒有進行網絡訪問。