最近給兩個新人解釋幀同步，寫了一個簡單的幀同步模型，但是公司不給上網，程式碼上傳不了，於是回家重寫了一個，但是有些工具類不想寫了，在網上找了一些可以用的程式碼湊合著用了。

幀同步的原理就是在一個回合內（一個固定的時間頻率，比如100ms）客戶端發服務端傳送關鍵幀，服務端收到所有客戶端廣播關鍵幀，所有的客戶端收到服務端廣播的關鍵幀後再執行。由於所有的客戶端程式碼都是一樣的，執行的幀數也是一樣的，所以每個客戶端得到的結果都是一樣的。

幀同步實現的過程有個很重要的地方就是邏輯層和表現層一定要分開，表現層先行，邏輯層等發到服務端的指令再處理。

幀同步適合做人數比較少（5到8人比較合適，多了資料包的傳送量非常大，會比較卡，特別是在手機上），同步要求比較高的遊戲，比如FPS遊戲和格鬥類遊戲。

幀同步雖然同步效果好，程式碼也簡單，但是還是有很多蛋疼的地方

（1）斷線重連，幀同步的斷線重連相當的蛋疼，還要服務端配合。

（2）一個客戶端卡了，所有的客戶端都會卡，所以有可能一個客戶端掉線了，其他人都會卡住

（3）物理引擎，一旦物體處於物理引擎的控制下就不能再強制去設定它的位置，如果強制設定它位置就會出現一些不可預知的結果，所以物理引擎是一個大坑，同步的最好不要用物理引擎，自己模擬就好了

（4）UDP傳送的包是不包證順序的，而且還可能丟包，

下面會附上一個幀同步的模型

服務端:https://github.com/caolaoyao/AsycServer

客戶端:https://github.com/caolaoyao/AsycClient

這個模型還有幾個問題

1、服務端沒有處理超時，一個客戶端掉了，所有的客戶端都會卡住了，服務端應該設定一個超時回撥，一旦超過某個設定的時間沒有收到客戶端的包，就當它什麼也沒有做，把關鍵廣播出去

2、服務端和客戶端都沒有處理收包的順序

3、同步物體的位置資訊的時候應該同步物體的狀態和方向，不應該直接同步位置，不然看起來移動的時候會很不自然，雖然提高同步頻率可以緩解這個問題，但這不是一種好的做法