我的項目是類似《貪吃蛇》玩法的一款IO游戲，就是幾個玩家在游戲界面中可以吃食物，也可以相互吃，吃了食物或對方都會變大這樣子。我是在用cocos creator做完前端開發的部分后，開始接入的Matchvs。其實在接觸Matchvs之前，也了解過國外的一些產品，比如photon、proudNet，不過網絡問題和收費是一個現實問題，...畢竟對於一個人開發者來說技術和資金都比較有限，這點大家應該都懂得。
雖然Matchvs把他們提供的服務官方稱為“一站式服務”，其實在我看來主要就是兩個，一個是接入他們的SDK，可以實現聯網功能。二是gameServer，gameServer命令行工具用於后端代碼本地調試。后端的代碼提交到Matchvs為我們提供的git倉庫，直接運行在它為我們提供的服務器中。
在Matchvs有一些像注冊、登陸、加入房間、發送事件這種很通用的功能，這些不用花太多時間就能基本掌握。二對我來說，最大好處還是在於幾乎不需要對服務器相關知識有所了解，只需要關注前端和后端的邏輯編寫，就可以完成一個游戲的開發。
一開始認為，這些api已經可以滿足我大部分的需求，但之后在使用過程中，我發現了它設計中一些存在改進空間的地方。
以下是我在接入Matchvs過程中的部分使用總結：
先說優點吧。
1、api簡潔且覆蓋面廣。
關於數據收發，sdk的api有sendEvent、sendEventNotify、sendEventEx；gameServer的api有pushHander、pushEvent。 游戲的數據交互，只用調用這幾個接口就可以了。我的項目屬IO項目，類似貪吃蛇，一個玩家給了食物調用sendEvent，另一個玩家綁定sendEventNofity， 數據就從這兩個簡單的api中傳遞了。
支持多平台，也可以配合其他游戲引擎使用。
例如: 在windows平台， 我使用cocos creator+matchvs開發，按照以下配置，打包成Web Mobile、Web Desktop、Wechat Game、Android、Windows等等平台。
// 以下是偽代碼，調用不用環境的的sdk
var engine
var response = {}
if (isNative) {
engine = Matchvs.MatchvsEngine.getInstance()
} else if (isWeb) {
var jsMatchvs = require("matchvs。all")
engine = new jsMatchvs.MatchvsEngine()
response = new jsMatchvs.MatchvsResponse()
} else ...
2、gameServer比較實用。
如果游戲邏輯簡單，簡單到只需要客戶端運行所有的邏輯代碼，我們就可以不使用gameServer。 如果游戲邏輯復雜，可以使用gameServer來同一管理所有的客戶端。
gameServer+node(gs)，使會js的人就可以寫后端代碼，開發速度更快。
例如在我的項目里，由於房主會變化，客戶端中，用房主來判斷游戲是否要開始是很繁瑣的。 讓gs這個大管家來判斷的話，就顯得很方便， 客戶端不需要太關注房主的改變，只需要關心是不是要開始游戲，減少了客戶端if-else邏輯。
Matchvs提供了斷線重連的功能。
在一些網絡差(地鐵，電梯)，已與服務器異常斷開的情況，matchvs會幫助玩家自動連接，開發者可以設置連接次數和頻率，但只能滿足一些基礎場景。
例如: 如果掉線重連了，loginResponse會返回一個roomId的參數，表示是斷線重新的， 這時，客戶端可以選擇重連和忽略。
多節點服務器部署以及幀同步技術
例如： 我的項目是IO游戲，玩家移動的過程中，不斷的傳遞當前位置的數據，畫面看上去還是很流暢的，感覺游戲延遲還挺不錯的。開發者不用擔心數據同步的問題，也不需要對服務器有太多了解，就可以完成一個游戲。感覺還是很棒的。
缺點。
目前，Matchvs主要圍繞着'房間'這個概念。創建、加入、獲取房間，房間內各成員數據發送和接受。 所以目前不適用於房間外數據發收的場景。
例如: 客戶端中，需要修改用戶名，這個操作就不能輕松實現。
目前GS不支持數據庫，而是使用hashSet，hashGet，用起來太麻煩。 如果有數據存取的需求，開發者需要自己買個數據庫服務。
希望后續有數據庫支持，或者改為支持使用官方提供的數據庫和自己購買的數據庫。
GS的命令行工具部分不太好用，存在一些小問題
登陸時密碼沒有隱藏，錯誤提示令人不解。
退出是輸入quit，而不是習慣的ctrl+c。
關閉debug，斷開時間太長，甚至有時無響應。有時只好強關。
gs+node服務使用熱更新，會導致gs服務斷開等等一些小問題。
官網中，對應的文檔比較難找，引導性不強。找個文檔需要花不少時間，跟Matchvs團隊反饋后是說文檔會持續優化，近期也會改版一次文檔中心的結構。
有些接口和方法並沒有在官方中說明，只能通過查看源碼或者詢問官方了解使用方法。
例如: 在研究Demo-GS-JS的時候，想到一個問題，gameServer給客戶端推送消息的時候，客戶端用什么來監聽。后來，知道是由sendEventNotify來接收的。
我發現文檔並沒有這個描述。官網表示，會盡快補上所有的缺少的說明
回調的寫法不科學。
例如: mvs。response。sendEventResponse = callback(msg){} mvs。engine。sendEvent(data) 這種寫法是很不科學的，如果后續代碼中也有sendEventResponse， 在此之前的sendEventResponse就會被覆蓋。
建議: 回調的方式改成 sendEvent(data， callback(err， msg) { })
特別提示
隨機加入和指定加入的房間是相互獨立的。
例如: 通過'隨機加入'加入的房間，用戶想通過'指定加入'，是加入不了這個房間的。
官方人員解釋也是這么一回事。但是，官方文檔並沒有說明，希望官方人員注意到這一點。
剛收到joinRoomNotify通知時，用戶與其他用戶不一定能消息通知。
例如: 此時其他人(客戶端)給加入者發送消息，這個加入者很大可能不會收到。
官方人員給予了解釋: '這時用戶已經在房間中了，但是還沒有和其它玩家建立通訊通道。目前js-SDK還不夠完善，應該確定通道建立完成后再發出joinRoomNotify通知'， 並表示后續版本會修改這個bug。
我的解決方案: 在上述的加入者joinRoomResponse的時候，發送isEnter消息，告知其他人，我是真的進來了。
問題與建議差不多就這些了，不過有一點要說明下，雖然在之后的使用過程中的確遇到的一些問題，但這里要特別感謝下官方客服在Q群里面耐心解答與賣力優化（可以感覺到這是一個在用心做產品的團隊，現在想起來那個客服八成就是Matchvs的產品），讓游戲順利上線並保持穩定運行。
PS：聽說Matchvs最近馬上要更新一個大版本優化，小小期待一下，希望能越來越好吧。