移動平台遊戲網路重連方案(轉)

標籤：資料   activity   資源   3.1   重點   協議   應對   網路連接   建議   

　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），避免使用者進行其他動作導致重複請求。這也要求我們在代碼邏輯層面上避免多個關鍵協議的嵌套和並發。

<ignore_js_op>

　　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：斷線重連流程圖

<ignore_js_op>

　　附錄2：RSSI訊號強度分級

<ignore_js_op>

移動平台遊戲網路重連方案(轉)