能将对象Add到EventSystem中。
2.协程中将IsDispose判断对象释放改成用InstanceId来判断，因为对象池的原因，IsDisposed
方法并不能精确的判断对象是否释放，有可能释放之后又被重用了。
3.更新运行指南

打印错误码，ActorMessageSender也增加了Error字段

一致导致新人理解困难，ActorComponent改为MailBoxComponent对应actor模型中的
mailbox概念，ActorProxy改为ActorMessageSender
2.上个版本Actor增加了一种知道instanceId发消息的模式，这个版本把gatesession改成了这
种机制，创建unit的时候，带上gateSession的InstanceId（不是gateSession的Id），这样
gateSession不需要注册location，unit直接拿着gateSession的InstanceId就能发消息到
gateSession,减少了一次location查找，这种机制其实就是最原始的actor模型（actorId中
带有地址信息）

ActorProxyComponent增加了一个GetWithActorId方法，假如已经知道了actorId(即actor的instanceId),就可以使用此方法，可以不用向location server的请求

到的是actor的instanceid，因为instanceid头16字节表示服务器id，因此可以得到actor的服
务器。actor消息中的actorid也变成了instanceid，这样即使actor销毁重新创建也不会有同
样的actorid，保证了唯一性。
2.这样改动的原因是，比如一个gate挂掉导致player意外掉线，然后player立即上线，其他服务器发给player的消息有可能是之前的消息。产生异常。
3.erlang中的actorid是processid，保证是唯一的。与逻辑无关。ET的改动保证与erlang一致。

2.一部分服务端逻辑移动到hotfix层

2.移动服务端部分方法到hotfix层
3.版本提示使用Unity2017.1.3p2，并且打印下载地址

每个ActorComponent在add的时候需要指定一个ActorType(string), actor在收到actor消息的时候会先分发到ActorTypeHandler处理

1.添加HttpComponent的一些功能；标记同个类中的方法，进行不同的处理；自动注入HttpListenerRequest，HttpListenerResponse；以及Get参数和Post信息(json形式)的注入。

但是也有少部分需要，例如玩家的物品背包组件需要单独存数据库，那么这个组件需要Id,需要存数据库的组件都需要继承ComponentWithId

1.每个Component都增加了一个InstanceId，这个id每个对象是唯一的，区分开来逻辑Id跟对象Id，比如Player对象的Id在整个游戏期间都是不变的，但是每次登录Player的InstanceId都应该不一样，actorid应该用InstanceId来处理。例如erlang的进程id是actorid，但是erlang进程中的玩家id不会是进程id。
2.加入instanceid是因为存在一个问题：Player的id是唯一的，但是断线重连，假如只有Player.Id系统无法区分,断线前的Player跟断线后的Player。
3.简化了EventSystem的实现，并且不需要ActorManagerComponent了，所有的Component都会注册在EventSystem里面，有很多好处，不细说了。
4.Disposer类删掉了，之前继承Disposer的类都可以通过继承Component来实现

2.actor消息因为无法继承，所以做了一些实现上的改动

消息到热更层要new个数组，感觉不太合适，还是想办法把它去掉。去掉消息协议中的rpcid，rpcid还是可以放到消息中，根据opcode来确定消息是否需要抛到热更层，在有热更层进行分发。这样hotfix层消息接收时可以减少new一块内存，减少gc

2.调整module下文件的位置，文件位置更加合理

2.事件机制现在完全抹平了差异，而且使用action回调实现hotfix层订阅mono层事件，性能大大提升

2.去掉了消息的Header结构，Header结构增加了一次序列化，想想还是不划算
3.目前消息结构是size(2byte) + flag(1byte) + opcode(2byte) + rpcid(4byte可选) + 消息内容