此篇为下文，上篇：Mirror网络库 | 说明

一、官方实例说明

以HostMode进行测试
多端测试工具

• AdditiveLevels：以Offline作为启动场景，AdditiveLevelsNetworkManager的SceneManagement的OfflineScene和OnlineScene对应上示例的Offline和Online；选择附加(Additive Scenes)的场景为SubLevel1和SubLevel2。SubLevel1和SubLevel2中的Portal的DestinationScene选择对方。整体流程：Offline场景运行 -> 附加加载OnlineScene为“游戏环境”，SubLevel1和SubLevel2为“关卡”场景，默认显示SubLevel1(First is start scene) -> 移动到标有SubLevel1字样的物体，则切换到SubLevel2(关卡2)，同理，移动到标有SubLevel2字样的物体，则切换到SubLevel1(关卡1)。
• AdditiveScenes：以MainScene为启动场景，不需要设置OfflineScene和OnlineScene的默认“环境”，SubScenes中添加SubScene作为附加场景。整体流程：MainScene场景运行 -> 附加加载SubScene -> 移动到一定范围内重新LoadScene并且使用InterestManagement的距离类型过滤掉其他Observers。
• Basic：BasicNetManager的OnServerAddPlayer和OnServerDisconnect监听Player.ResetPlayerNumbers方法，此方法标记了[ServerCallback]且为internal static，记录Player类的playerNumber从0递增，表示加入的“玩家编号”。Player类的OnStartServer中存储自身到容器，且设置color和data。至此，服务器改变了playerNumber、playerColor、playerData三者的值，通过SyncVar属性及hook钩子这些变量值变化时会触发对应的Method，而Method中包含了对应的事件调用。Player类中的OnStartClient中，对这些事件进行了PlayUI中的实际方法绑定及Invoke。整体流程：开启主机模式 -> 服务器为Player00，其Data每隔1秒在[100, 1000)之间切换 -> 加入一台客户端(玩家) -> 玩家为Player01，Data同样在1秒内切换一次。Stop则断开连接，对应的PlayerUI消失。
• Benchmark：运行之后，Snapshot Interp这一块的参数值来自于NetworkClient的OnGUI，在NetworkManager(抽象类)的OnGUI中调用；timeline(经过快照插值处理后的远程服务器的时间)、buffer(时间快照数量)、DriftEMA(ExponentialMovingAverage：指数移动平均线。平均最后一秒的快照时间差)、DelTimeEMA(传输时间的指数移动平均线)、timescale(每个update中调整本地时间标尺)、BTM(存储的快照插值运行数据缓冲时间乘数)、RTT(消息从client->server->client的时间，单位：秒)、SendRate(消息发送间隔，单位：Hz，1/sendrate=ms，针对时间和值快照插值。这个是博主自己添加的一个参数打印) 。底部的Radius滑条是SpatialHashingInterestManagement的OnGUI，影响visRange，其CheckMode分为2D和3D两种模式。
• BenchmarkIdle：TCP协议服务器生成完毕，编辑模式花费35秒；客户端加入花费2秒；传输数据方面客户端send大概在320-580B/s，recv大概在712KB/s-1.04MB/s；服务器send大概在1.04MB/s，recv大概在385B/s-704B/s。替换为KCPTransport后，数据基本没有倍数变化。
• CCU：Client/Server Statistics这个是NetworkStatistics的OnGUI绘制的。这个生成好快！把BenchmarkIdle的Interleave从2改为10，结果生成花费的时间基本不变，因为这个参数只是改变了间隔距离，生成数量没变；换成KCP + DistanceInterestManagement花费时间没咋变化，fps有很大提升。这里生成时间能否节省？如果不能节省就提前生成？
• Chat：有一个ChatAuthenticator，验证消息传递，用户登录，可以像Basic那样扩展离线通知。对于需要身份验证、保证消息可靠传递可以参考这个示例。
• Discovery：WebGL不支持。开启udp循环广播，进行监听，查找可连接的服务器，请求连接。**扩展：服务器断开，那么客户端的Find Servers列表要响应清楚该Server。**这个可以应用在app查找可用服务？
• LagCompensation：Fps games非常有用，避免明明瞄准了打的枪，结果敌方没死掉。通过存储player的快照，在不同的网络情况下，预测不同客户端的时间，算出对应时刻的玩家位置，再进行判定。
• MultipleAdditiveScenes：这个和AdditiveScenes很像。设置MultiSceneNetManager的Instances(场景实例个数)和GameScene(场景)，运行，会附加加载指定个数的指定场景。
• MultipleMatches：这个有点像腾讯游戏大厅之类的下象棋游戏，任何一端可以创建一个房间，建房的端可以等进入房间的人都处于Ready状态时，就开始游戏。示例实现了一个简单的回合制井字棋游戏。
• Pong：看到这里的时候，可以发现基本上就是NetworkBehaviour、NetworkManager、NetworkTransform这些东西整来整去，整个框架的使用应该时不难的，但是想看核心的东西也比较难吭，比如：如何做到双端一个工程，发布后逻辑自动划分的？为什么要带一个Mono.Cecil？Weaver是干嘛的？能不能快速替换Transoport以适应不同的网络、平台等情况？组件和常用核心代码的应用场景？
• RigidbodyBenchmark：虽然只有2000个，相对前面的几万个来说比较少，但是这个好快！用了延迟模拟+SpatialHashingInterestManagement。这个才是正确使用方式么…
• RigidbodyPhysics：案例没得ReadMe，咋一看NetworkManager也没有业务子类，上面也没啥可疑参数，ok，看Scripts找到按空格键施加一个向上的力这么一段代码。模拟的力有点假，特别是小球向上的力和重力抵消，快要消失的时候，太生硬了。
• Room：这个和Lobby还是有点区别的，应该说默认就在房间，然后再ready->play，没有在大厅创建房间这一步。上面的MultipleMatches有建房间，且任意一端均可以。
• Snapshot Interpolation：延迟补偿的原理因素之一。
• SyncDirection：谁给谁做同步。HostMode把Player上的SyncDirection改为ServerToClient，然后空格改值，该值的变化会同步到Client端。示例用了SyncVar和SyncList这两个来做同步测试。这个案例虽然比较简单，但是可以解决**如何做到双端一个工程，发布后逻辑自动划分的？**这个问题。可以看看代码，路径还是挺清晰的。
• Tanks / TanksCoop：坦克大战小游戏，就是不能后退有点蠢…可以看看ClientRpc的使用。

二、多路复用器测试(PC + Android + Webgl)

• Tanks的sendRate = 120之后，PC发布包测试，RTT并没有到1，是我的工作电脑cpu不行么？哈哈
• 本来想做个KCP+RPC+Lantency Simulation的功能测试，但是实例看完，这些都包含了，不做了。
• 最后，整一个Multiplex测试~

MultiplexTransport：KcpTransport(PC + Android) + SimpleWebTransport(Webgl)

NetworkManager -> MultiplexTransport -> KcpTransport（1） + SimpleWebTransport（2）
官方教程

• PC + Android，借用官方示例的Chat示例，没有问题
• webgl没有服务器测试…还要配置ssl(后面有机会补齐哈 …)
• 如果想单纯的使unity和webgl交互，协议采用websocket，推荐用这个库：UnityWebSocket