1、背景

移動網絡信號波動頻繁，給移動游戲開發者帶來諸多困擾，處理不好會造成較差的用戶體驗以及重復扣道具等嚴重問題。因此弱網絡問題在TDR技術評審中作為客戶端重點挑戰項，并且弱網絡專項測試達標后方能上線。本文就過往項目中遇到的問題給出一種比較通用解決方案。

2、網絡連接方式

通常游戲客戶端都是通過創建socket與服務器取得連接，但也會根據使用場景劃分成兩種連接方式：TCP連接和HTTP連接。

1) TCP連接即我們常說的長連接。這種連接方式下socket連接一旦建立，通信雙方即可相互發送數據，直到一方終止連接。目前公司的移動端聯網游戲多采用這種數據通訊方式。

2) HTTP連接即我們常說的短連接。這種連接采用的是“請求-響應”的通訊方式，每次交互由客戶端發起請求，服務器收到請求后才能回復數據，數據傳輸完成后，socket連接便斷開。在下載CDN資源或云配置時通常會采用這種連接方式。

3、網絡檢測

3.1 檢測設備的網絡環境

iOS和Android都提供了檢測本地網絡環境的方法，具備我們需要的功能：

1) 網絡環境標識，區分當前網絡環境：WIFI/WWLAN/NOTREACHABLE等。

2) 網絡切換感知，網絡環境切換后會收到系統消息。

在蘋果開發者網站（developer.apple.com）上有一個reachability的例子，對底層網絡組件做了封裝，可實現此上的功能。Android上提供了Connectivity Manager服務，可加以封裝實現同樣的功能。附錄中提供了相關的開源代碼，并分別封裝了reachability在iOS和Android平臺上的實現。

3.2 檢測心跳超時和回包超時

心跳即每一定時間間隔（假定15秒）客戶端和服務器進行一次請求/應答，來判斷對方是否存活。若客戶端發送請求成功后，長久（假定60秒）未收到服務器的回應，則認為連接已經中斷或者服務器宕機。若服務器長久（假定300秒）未收到客戶端請求，則可以認為客戶端已經離線。另外常規的業務數據包也可以認為是心跳包的擴展，所以每次業務數據包通信成功，客戶端和服務器都要重新計時。一般心跳包是一個空的數據包，以節約流量，但通常也會包含少量字段，比如客戶端和服務器的時間同步信息等。

一些關鍵協議，比如進入房間的請求，需要等待服務回應后才能扣除體力進入房間。但網絡不穩定時，可能客戶端的請求發送成功，服務器的回應卻遲遲沒有收到，這種情況下，客戶端需要做一個超時控制，比如15秒后客戶端還沒有收到回包，則給出提示，不能讓客戶端無限的等待。這種因果關聯的一對協議我們稱作請求-應答協議，建議所有關鍵協議都采用這種機制。有一點要注意，這種異步操作有一個等待的時間，一般這段時間都會屏蔽輸入（轉菊花/show activity indicator），避免用戶進行其他操作導致重復請求。這也要求我們在代碼邏輯層面上避免多個關鍵協議的嵌套和并發。
?

3.3 檢測發包失敗

一般來講reachability足夠靈敏可靠，設備網絡發生變化時能及時感知，只要監聽到狀態切換為NOTREACHABLE便可認為斷線了（需要排除瞬斷的情況），但reachability也有限制，無法感知到傳輸層連接斷開。舉個例子：手機號轉讓手機和無線路由器連接正常，但是無線路由器和modem連接中斷，這時reachability是檢測不到網絡斷開的。此時需要依據socket錯誤碼來判斷網絡情況。

3.4 檢測socket狀態

以上幾種機制都是在應用層做網絡狀況檢測，基本上可以應對大部分情況，但有時為了更好的用戶體驗，我們需要更加精準的檢測方式。獲取socket底層錯誤碼及狀態能為我們提供更多的判斷依據。因實際項目中并未用到這方面的內容，便不在這里擴展。

3.5 檢測網絡延遲

某些類型的游戲對網絡延遲特別敏感（如實時對戰類游戲），較高的網絡延遲將會導致慘不忍睹的體驗。這些類型的游戲不但要從技術層面做優化，同時也要根據用戶當前的網絡延遲加以限制。比如平均延遲在1000ms以上便提示無法游戲。我們可以采用兩種方式評估延遲：信號強度（received signal strength indication）和收發包時間統計。

1) 信號強度（RSSI）檢測：這種判斷網絡延遲的方式不具客觀性，因為網絡延遲不僅取決于信號強度，同時受到帶寬、傳輸節點數、網絡硬件吞吐量等一系列因素的影響。但在其他參數相對固定的情況下，我們仍然可以參考信號強度來評判網絡狀況，同reachability類似，RSSI能及時給我們當前網絡狀態的反饋。在Android平臺上使用WifiManager類可以獲取具體RSSI值及信號強度等級。不幸的是iOS 5.0及以后的系統都不再支持RSSI的獲取（當然jailbreak之后還是可以的）。

2) 收發包時間統計：即在客戶端和服務器時間同步的情況下，每個數據包帶一個時間戳信息，基于過往的數據包計算平均網絡延遲。這種檢測方式相對合理，但是時效性較差，在網絡波動頻繁時不能及時正確評估，相反在連接平穩的網絡環境中，會得到理想的效果。

在Android平臺上要取得一個合理的網絡延遲，可以結合以上兩種方式。iOS平臺上暫時還只能采用第二種方式。

4、斷線重連機制

當檢測到斷線后，便可以啟動重連模式。根據當前的游戲狀態確定重連策略，一般有以下三種方式：

1) 靜默重連，即在用戶無感知的情況下進行重連。一般檢測到斷線后，可以先嘗試靜默重連一定次數（比如3次）。如果在游戲對戰過程中斷線，一般也會盡量嘗試靜默重連并且忽略重連次數，因為此時彈出提示框會打斷對戰體驗的完整性。靜默重連提供了一種友好的用戶體驗，能應付一些短暫的網絡中斷（比如進出電梯或者進程從后臺喚醒等）。

2) 顯式重連，在靜默重連一定次數（假定3次）之后，仍然無法連接成功的情況下，此時需要彈出提示框，中斷游戲流程，告知用戶當前網絡環境較差，引導用戶在網絡較好時再嘗試連接。

3) 服務器故障重連，這種情況下客戶端無論如何是連接不到游戲服務器的。此時客戶端也需要給出正確的引導，而不是誤當作斷線故障處理。因此我們在斷線重連失敗之后多加一個步驟：嘗試連接CDN服務器，若CDN服務器可以正常連接，那么說明網絡暢通，我們去獲取CDN上的云配置，檢查是否有服務器日常維護的標識，如果有則給出服務器日常維護的公告，否則可以認為服務器宕機，則給出服務器故障的公告。此步驟中若CDN服務器也無法連接，說明網絡確實不暢通，可以繼續走重連流程或者等待。

5、網絡協議的制定規范

要做到良好的重連體驗，不僅需要良好的解決方案，也需要有協議上的支持。通常協議制定時可以參考以下規則：

1) 登錄協議盡量簡單，僅包含必須的字段（如玩家等級，金錢，體力等）。一般重連即需要走重新登錄和鑒權流程，精簡的登錄協議能提高重連效率和節約流量。用戶的非關鍵校驗數據（比如背包數據，排行榜，卡牌信息）等可以延遲到界面開啟時再請求或者使用本地緩存數據。

2) 協議的解耦，不同業務邏輯需要的請求包不同，這里就需要進行協議解耦，減少冗余數據，降低傳輸的包量，提高單包發送成功率。

3) 支持數據包壓縮，對于較大的協議包（比如排行榜數據，好友數據等）需要做針對性的壓縮，提高單包發送成功率。

4) 關鍵協議需要添加序列號，避免客戶端重復請求造成的多次扣費等問題。

6、CDN資源下載方案

隨著硬件和技術的發展，移動游戲品質也和PC端游越來越接近，當然資源量也越來越接近。受限于移動網絡帶寬，較大的安裝包給玩家設置了較高的門檻，因此目前的手游產品也越來越多的考慮微端方案。即安裝包只包含部分游戲關卡，或者只作為一個下載器，而完整的游戲資源放在CDN資源服務器上，然后按需下載，這也是一般頁游的思路。這種情況下，我們對比了幾種打包機制給大家參考。

<todo>測試數據稍后提供</todo>

附錄1：斷線重連流程圖

附錄2：RSSI信號強度分級
?

總結

以上是生活随笔為你收集整理的移动平台游戏网络重连方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。