網路條件異常
    在弱網路情況下，網路會顯式的丟擲一些異常，大部分情況下是NetworkException，少部分情況是Timeout（當然還有連線關閉等等其他異常，就不一一贅述）。在這種顯式丟擲異常的情況下，就說明網路已經無法順利的和伺服器進行連線，在這些訊息型別中，對於客戶端斷網或網路波動導致的原因，客戶端這邊就會觸發斷線重連流程。

2  　　心跳包觸發以及觸發時間的確定
    上一種情況的觸發條件是客戶端手機本身斷網或網路發生異常的情況的觸發，但實際情況中，還有可能發生客戶端網路並未斷開，也並沒有異常丟擲，但是卻出現客戶端和伺服器無法正常進行收發訊息的情況。
　　這種情況一方面原因是中間鏈路的連線異常，另一方面也會由於延遲過高或丟包導致的TCP重發造成的延遲過大，影響到伺服器和客戶端之間正常的收發訊息。

在　　市區低速移動的網路的模擬測試中，我們收集到的最大心跳包延遲是10s左右，也就是說，在此“弱”網路情況下，網路延遲峰值大概有10s以上。因此，我們對心跳包在一定時間內如果沒有收到返回包的情況下也認為是一種掉線情況，會觸發斷線重連處理，目前在大廳設定的觸發時間是30s，戰鬥中觸發的時間是20s。

遊戲切出
　　有一種情況是由於客戶端切出遊戲，或者中間接到電話等導致遊戲暫停等情況，在一定時間後伺服器會主動斷開和客戶端的連線，客戶端也需要主動觸發重連。

３、斷線重連的大致流程圖
　　斷線重連收到網路異常訊息階段處理流程：

　　斷線重連結果處理階段：

４、對流程圖的補充說明
　　1)在重連過程中，如果收到客戶端主動斷開的訊息，會遮蔽所有重連行為
　　2)由於在收到NetworkException的時候無法保證網路狀態，如果此時網路已經連線上，會無法觸發後續重連過程，所以會在NetworkException的時候double check一下是否連線到網路。

５、關於狀態機：

斷線重連並不是一個瞬間操作，而是一個過程。在整個斷線重連的過程中，存在著一個個階段，也就對應一個個的狀態。初步來說，主要分為以下幾個階段。
A. Start：網路正常狀態，簡稱S
B. Wait：網路已經斷開，等待網路恢復，簡稱W
C. Reconnect：重新連線狀態，簡稱R
D. End: 重新連線失敗，簡稱E
　　狀態轉換圖見下：

６、重連後的相關處理
　　在程式斷線重連的過程中除非重連失敗，否則最理想的情況是希望玩家在斷線前後無感知，可以流暢的繼續遊戲而不受到斷線的影響。
1) 對於大廳的後續處理
A.拉取相關屬性和物品。再重新連線後，由於在斷開過程中可能會有相關資料的變化，會拉取人物相關屬性和物品
B.重發斷線前的相關請求：這個和具體的系統相關，如果斷線前的系統進行的是一些對資料敏感的操作，比如合成物品，購買物品等，在發起的時候會做無法二次點選的處理並加入到重發列表中，在網路恢復之後重發。此時如果伺服器未做處理便會直接處理，如果做了處理需要伺服器忽略（注，這個需要伺服器配合）
2)對於戰鬥的後續處理
A．重新拉取戰鬥狀態資料：這個是由於我們遊戲是對戰鬥實時性要求較高的遊戲，所以在斷線過程中的戰鬥狀態可能會發生很大的改變，這些改變必須需要重新同步，比如可能會死亡，球變大或變小，位置改變等都有可能，所以在重連之後，我們是全量拉取玩家戰鬥資料，同步到最新的狀態。

7、對重連的一些說明
　　1)在戰鬥過程中，其實還伴隨這大廳這個連線，所以很多情況下，戰鬥連線的斷開也會伴隨著大廳連線的同時斷開。對此，我們對於不同連線建立不同的重連器，從而達到兩個連線相互獨立，無論只是單個連線的斷開還是兩者同時斷開，都不會相互影響，各自走各自的重連過程。

8、對之前版本遊戲更加容易掉線的一些思考
　　雖然其實很多時候確實是wifi不穩定導致的網路問題，但之前版本確實比其他遊戲更容易掉線，具體體現在在同一個網路下，兩個差不多的手機，玩我們遊戲的時候掉線的頻率更高，對此以下是我的一些想法。
　　對於網路經常觸發異常的原因，除了網路本身的不穩定外，主要還是TCP協議中，客戶端緩衝區在網路不穩定的時候容易寫滿導致的問題。
　　對於這個問題，一方面可以適當的擴大緩衝區的大小，對此把客戶端網路的緩衝區擴大，從1024*100，擴大到1024*2000，也確實改善了遊戲的網路狀況。
　　但這種方式只是並沒有從本質上解決這個問題，網路其實的壓力還是很大，流量過大也是我們遇到的問題之一。
　　由於包頭和TCP持續計時器的原因，在每個包的包頭都會有一些不屬於遊戲協議內容的造成的流量，對於一些能夠合併到一起傳送的小包，合併小包和減少包量可以很大幅度的減少流量。而且也容易避免由於滑動視窗可傳送部分的迅速充滿導致的網路擁塞。
　　另一方面，單個包的大小過大也會迅速的撐大緩衝區，而且在傳輸過程中造成傳輸峰值，造成網路延遲，拆分過大的包，比如一瞬間全量拉取排行榜等的資料通過分批拉取，減緩網路壓力，也能達到優化網路的目的。

9、對於為什麼會有wait狀態
　　其實對於一般的想法來說，其實斷線重連只需要Start，Reconnect，End三種狀態，確實，這三種狀態可以把整個斷線重連的過程完成，對於wait，主要一下幾個原因。
1.Wait 狀態和Reconnect狀態的區別在於Wait狀態手機網路並沒有連線，而Reconnect狀態的網路已經恢復了，這個其實是有差別的，可以對網路的狀態進行不同的處理。
2.因為由於一些原因（比如在wait狀態可能由於Apollo錯誤原因而無法收到網路恢復的訊息等）我們也低頻嘗試了重新和伺服器建立連線，但是其目的是發現是否能夠建立連線，更多的時候會返回失敗的訊息，是一種double check 的保證策略，而Reconnect狀態下的重連是我們知道了網路已經恢復，嘗試去連線伺服器，目的是為了真正的建立連線，這兩種情況無論在目的上還是在連線的頻率上都有差別，而且將兩個狀態區分便於我們在不同狀態下做不同處理。