移動設備的產品的網絡狀態取決于用戶所處的網絡環境。

這個網絡環境也會根隨的用戶的位置進行改變。

也很有可能前一秒是在Wifi網絡下，這一秒4G了，再過一會信號就變弱或無信號了。

那么，對于產品的實時性要求很高的產品，如何設定這個超時時長呢？

比如語音識別類的產品，有以下幾個產品特性，網絡性能對其影響較

1，上行的數據量比較大

2，服務端處理數據的時間，依賴于上傳的語音數據量

3，語音識別的過程是個持續的過程，一次完整的語音識別過程

4，用戶對于產品的實時性要求較高

這時，網絡超時時長的設定就不能以一個最大值的方式來執行了。

1，在網絡信號不穩定時，我們需要快速的告知用戶，由于網絡狀態導致識別的過程出錯，減少不必要的等待。

2，無論任何網絡狀態下，任何的數據量，我們都需要保證本次網絡請求的有效性。

3，總結一句話，只要這個超時時間精確，以上的問題就可以解決！

看到這里，想必大家都有一定的思路了

這里給大家例一下大概的思路

1，獲取當前網絡類型，根據網絡類型得到該網絡類型的網絡速度 N.s

2，獲取本次客戶端上傳的真實數據量C.d

3，數據量 C.d與網速N.s作比，得出上傳數據所花費時間?C.D.t

4，與服務端確定，處理單位數據量與花費時間值S.P.d，

5，數據量 C.d與單位數據量費時S.P.d關聯，得出服務器花費時間S.P.D.t

6，對于服務器返回數據進行預估S.d

7，數據量 S.d與網速N.s作比，得出上傳數據所花費時間?S.D.t

8，那么總的超時時間可以為 C.D.t + S.P.D.t + S.D.t（上傳數據時間+處理數據時間+下發數據時間）

9，也可能加上建立聯接時間的補充

10，一些容錯的時長buffer

這么執行下來，超時時長就變得精確多了，無論發送數據量多少，網絡是什么樣，這個傳輸變的更可靠。

同理，該方案，也可應用到其它類同的場景中，根據產品需求及技術依賴進行優化。

補充：類似的功能，也可以嘗試使用分包的策略降低單次網絡請求的失敗率，減少總時長，歡迎大家閱讀及交流