我的项目是类似《贪吃蛇》玩法的一款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最近马上要更新一个大版本优化，小小期待一下，希望能越来越好吧。