摘自自運營微信定閱號 創心思考 ，搜索關注獲得更多內容！
移動設備的產品的網絡狀態取決於用戶所處的網絡環境。
這個網絡環境也會根隨的用戶的位置進行改變。
也很有可能前一秒是在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
這麼執行下來，超時時長就變得精確多了，無論發送數據量多少，網絡是什麼樣，這個傳輸變的更可靠。
同理，該方案，也可應用到其它類同的場景中，根據產品需求及技術依賴進行優化。
補充：類似的功能，也可以嘗試使用分包的策略降低單次網絡請求的失敗率，減少總時長，歡迎大家閱讀及交流
摘自自運營微信定閱號 創心思考 ，搜索關注獲得更多內容！