总篇

本篇将会统一讲述各个设计方案的基础理念，适用场景以及举例。后续将会结合实际例子来详细讲解的设计方案

————

前言：

网络同步是一个复杂的工程问题，一般来说根据需求，我们需要研究以下问题

1:我们需要同步什么东西

2:我们的同步是部分同步还是完全同步

3:同步更注重于连续还是注重于结果

4:我们的同步的是参数还是结果

5:同步逻辑是群发的还是单发的

6:同步逻辑是否需要双向通信

7:同步是否需要适配持久化保存

有一些东西是……原则上必须实现的：

1:迟到者同步：为新加入的玩家重新同步

2:性能考虑：你必须考虑到网络同步的性能问题

3:防呆设计：你必须保证无论什么情况下你的同步过程中都不会导致崩溃

4：主副机相等：发出同步的人必须和接受信息的人最后的结果一致。

基于上述问题和原则，根据常用的场景，我个人常用以下几种设计原型

————

单文件同步设计

理念：将业务代码和网络同步放入同一个脚本内，同步只需要将重点变量同步即可。同步方式根据需求自由选择。

适用性：这种网络同步模式是最基础的模式。也是大部分复杂度不高，同步要求也不高的插件的通用方案。

其有着设计简单，逻辑清晰的优点，而且易于debug。

其缺点也很明显，网络部分和业务代码高度耦合，后期维护性较差。

适合场景：简单插件

————

网络同步分离设计：网络同步隔离设计：

将网络同步部分代码和业务代码分离，互相之间通过通过函数进行通信。常用于网络同步部分参数除了本体需要以外，还可能被参数多个插件需要的情况。例如UdonChips-Udon钱包。

同步方式主要以手动同步和自动同步为主，常见搭配PlayerObject使每一个人都有独立的对象。

而且这种同步方案对持久化设计十分友好，可以轻松实现持久化。

优点：结构相对简单，开发难度较低，后续继续开发。

缺点：性能较差，因其它脚本无法主动得知更新时间，通常需要多次无意义的重复获取数值来保证数据最新，这带来了十分严重的性能浪费。

（tips：可以弥补的，纯某UdonChips懒导致的性能问题）通常会结合下面一个模式的部分特性来弥补缺点。

————

同步管理模式：

同样是业务代码和同步代码分离，但前者强调同步代码不参与管理，只提供同步。而这个模式下的网络同步组件需要负责组件管理职责。

比如业务代码A是一个控制台，他负责收集玩家的操作指令，组合成参数然后传输给同步代码。

一对多网络同步模式：简单来说就是控制面板所在的控制台不参与同步，在收集完信息后，利用另一个只负责同步的脚本进行同步。同步代码接收到之后，触发同步，并且主动通知所有需要这些同步的脚本数据已更新。或者自己本身就是一个业务脚本，根据参数进行相关行为。

这种同步模式可以形成可接受多种输入，多种输出的模式，无论上层和下层如何改变，只要最终数据符合要求就可以正常使用。

优点：可拓展性强，根据设计可以适配多种不同的场景，非常好用的大型网络同步方案非常好用的大型网络同步方案。因为有了通知机制，没有太多的性能浪费。

————

同步对象池模式：

多对一网络同步模式：这个同步模式主要用于解决持久化相关问题。这个模式主要是利用PlayerObject的特性，将数据存储在个人对应的PlayerObject中，控制面板根据需要从Loaclplayer中获取同步脚本。或者利用playerdatabase来进行同步。简单来说，在这个模式下，将多个同步脚本组成对象池，业务代码根据需要将结果存入对象池中的任意/随机同步对象中。由对象池管理同步信息。

这种同步模式在没有PlayerObject的时候曾经是热门的模式。现在大部分时候用于例如点菜系统，任务分配系统等——玩家的每一个操作都需要独立记录的场景。

优点：可以实现持久化效果好，是特殊场景的设计方案

缺点：复杂，自由度低。

——