Golang游戏服务器Leaf接入FlatBuffer步骤记录（附微信开发者平台接入FlatBuffer步骤3）

1.为什么不用Json，效率低

2.为什么不用ProtoBuffer，Laya发布的微信游戏不支持，在官方社区问了一万年官方也没给出个具体的实现方案后，转向了FlatBuffer。开始并不知道能不能用，会不会出现各种问题，因为微信是阉割版的H5所以刚开始并不确定能不能用。在测试过后，明确的告诉各位看客，是可行的。

3.什么是Golang，什么是Leaf这里就不回答了，给出Leaf的连接。Leaffffffffffffffffffffffffff

FlatBuffer作为通讯协议，要满足以下几个条件。

1.要接入Golang编写的服务器要支持Golang，

2.要接入微信开发者平台要支持JavaScript

FlatBuffer这两个都支持，剩下的就是遇水搭桥，逢山开路，一点一点跑通整个流程。

Leaf是个框架有一整套的流程其中，其中对于来自于客户端的请求消息都是由Processor来处理的，发送也是由Processor来发送。

Process在处理完毕序列化和反序列化后，把数据要么通过channal传给其他模块去处理，要么通过建立的客户端连接connection把数据发送出去。

其中Leaf提供了2种数据的序列化处理 1.Json 2.ProtoBuffer

这两种都有序列化和反序列化的处理，如果再写一个也不难，

难就难在FlatBuffer不需要序列化，也不需要反序列化，如果走框架就很麻烦。

为什么麻烦？因为如果想要在Processor Unmarshal这一步拿到FlatBuffer的具体类型，根本不可能啊？FlatBuffer的对象都是这么来的，MyGame.Monster.getRootAsMonster(data)，意味着每一个类都有一个自己的“构造”方法了，没有办法通用处理。

但是如果把数据能进入到具体处理那个消息自己的处理函数，这样是不是就可以在那里再具体的调用各自的构造方法去实例化这些数据所代表的对象呢？

最后发现在Route分发数据的时候，数据分为两种格式一种是MsgRaw的格式，一种是当前正在应用的格式。比如如果用的是Json那么就是Json.Unmashal序列化出来的类型。如果是ProtoBuffer那么就是proto.Message这种类型。

MsgRaw说穿了，就是[]byte，没有经过任何处理。

但是FlatBuffer自己本身就是二进制，根本不用序列化和反序列化，是不是