共计 2486 个字符，预计需要花费 7 分钟才能阅读完成。
这篇“Unity 服务器下发配置的方法是什么”文章的知识点大部分人都不太理解，所以丸趣 TV 小编给大家总结了以下内容，内容详细，步骤清晰，具有一定的借鉴价值，希望大家阅读完这篇文章能有所收获，下面我们一起来看看这篇“Unity 服务器下发配置的方法是什么”文章吧。
1 Sproto 协议
在之前的客户端技术选型的文章里我们就介绍过，服务器使用的是 SkyNet。
Sproto 是谷歌 Proto 的一个变种，是云风基于 SkyNet 实现的一种优化格式。之所以选择这个格式是因为 SkyNet 对 Proto 的支持只到 2.x，并且已经不再维护了。而 Sproto 更符合目前服务器在 Lua 端的性能表现。为了配合服务器的通信协议格式，客户端也选择使用 Sproto。
详细的内容以及扩展阅读可以参照技术选型文章里的 Sproto 部分。
2 Sproto 表格
客户端关注两个部分的数据，一部分来自运行时服务器的下发，一部分来自静态的策划配置。既然和服务器通信采用的是 Sproto 格式，那就没理由再整一套额外的数据格式来处理策划数据。
但，策划大部分时候都是用 Excel 编辑数据，所以我们需要制作一个导表工具，用来将表格数据转化为以 Sproto 格式序列化的 Byte 文件，就像 Proto 一样。
这里的转换过程有点复杂，一言难尽，有空我们讲导表工具的时候再进行详细阐述。总而言之，就是客户端将服务器的通信协议和策划的表格配置统一成了 Sproto 格式读取和处理。这带来了很多好处，比如要联调服务器数据的时候，我们完全可以使用表格伪造数据进行联调，或者将服务器下发的数据持久化存储，变为静态数据的一部分。同时这样也可以让策划把一部分敏感数据配置在服务器，登陆之后再由服务器下发存储到安全的地方，防止反编译。
当然这些特性其实我们都没有做，只是用到了服务器数据格式和策划数据格式一致的特性，进行了部分表格的增改。当然这里就包括对多语言的更改。
3 增改结构
客户端对于不同的数据源也是分开存储的，策划数据汇总于 DataManager，而服务器数据汇总于 NetDataManager。二者之间基本不会有交互，只有一种情况下除外。服务器在下发了登陆成功协议之后，紧跟着会下发策划数据表的热更新 Bytes。
这里需要和传统的客户端资源热更新形成区别。客户端的热更新是静态的，走的是 CDN，它是一种常规的管线功能，更新的资源体量大，种类多。但是只会在游戏登陆之前（一般是刚启动）。而我们这种功能实现是为了应急或者修补 BUG 而应用的备份策略。服务器的流量本来就很贵，不应该用来下发大量的静态 / 表格数据。同时作为应急功能，它不能被过渡使用从而导致过多过于复杂的逻辑。
我们会在一个专门的导表目录里放置需要热更的表格数据，导出之后，服务器会识别到该目录下的所有文件，根据文件名建立名字 - 数据索引，然后存储在内存中，客户端连接上之后，以专门的协议下发，客户端收到之后，和缓存中的数据进行比较，没有的增补，已有的覆盖。
这个功能对于服务器来说是热重载的，对于那些已经在线的客户端，也可以通过运营工具进行广播，从而完成服务器不停机，客户端不重启，便对数据或者 BUG 进行修复。
4 屏蔽词实现
屏蔽词有些麻烦。为了兼顾查找和替换效率，我们是使用了 trie Tree 的方式进行的。如果有不清楚的，可以返回看这篇文章。
因为屏蔽词的条目非常之多（我们过审的版本有 52 万条，文本文件就接近 10M），所以必须提前将屏蔽词进行离线处理，然后运行时进行加载（不然每次登陆你可能要等 10 几秒）。但这也带来了额外的问题，因为它不像其他表格数据一样是离散的，所以不能使用上述方法进行增量下发。
而由于屏蔽词的树是提前遍历所有词组，然后离线生成的，它也不具备动态插入功能（重新生成整棵树代价很大）。所以针对屏蔽词我们使用了另一套规则。既然不能合在一起，干脆就完全独立为两棵树。数据格式是一样的，只是数据源不一样，那么我们就创建两个版本，Server 版本和 Client 版本。Client 版本多且大，离线生成。服务器版本小且动态生成。当需要查询屏蔽词的时候，优先查询服务器版本，没有再查 Client。
而这个时候，数据下发依然可以通过上述的框架结构进行数据增补，每次服务器有屏蔽词下发，就重建一次服务器屏蔽词树，因为服务器增补的条目数一般都很少，几乎不会造成性能问题（即使有也是一瞬间）。
我们在版署过审中，使用该方案减少了多次打回出包的问题。
5 复合配置热修复
所谓复合配置就是有些问题单张数据表无法修复的。比如系统邮件，如果本身邮件的数据表就缺少数据模板，这个时候我们不仅仅要下发语言相关的内容，还需要下发邮件的增补数据。同理如果邮件还涉及到新的奖励物品，也可以通过下发 Item 表进行增补。当然这些使用到的都是基于上述的增补框架。
6 运营介入
这部分涉及到的是运营的各种公告和通知。比如紧急停机，突发状况等等，这些都是无法预料的，自然也无法事先将语言或者数据配置在表格中。而上述我们所处理的都是游戏功能，属于策划层面的 BUG 修复。但是到运营这个层面就不同了，首选运营编辑公告或者处理不同地区服务器的时候不应该都经过策划或者开发组。事实上游戏运营者可能和开发者完全是不同的公司。如果是在不同的国家的当地发行，甚至语言都不通。
这个时候就需要一套完整的工具链来帮助运营直接使用该功能。前面我们聊了这么多也知道，服务器和客户端之间进行数据增补是完全没有问题的，现在需要在这条链路里增加一个控制方。确切的说应该是变更一个控制方。因为现有的链路服务器和客户端交互是在某个特殊的目录下，存有特殊的 byte 文件。而这个文件是策划导表生成的。服务器读取文件，转化为二进制，通过协议下发。
而我们稍微转变一下思路，即提供一个运营工具，让他们可以将需要的配置通过工具生成一个指定的文件或者二进制缓存，传递到服务器，然后就可以按照正常流程进行数据增补了。
以上就是关于“Unity 服务器下发配置的方法是什么”这篇文章的内容，相信大家都有了一定的了解，希望丸趣 TV 小编分享的内容对大家有帮助，若想了解更多相关的知识内容，请关注丸趣 TV 行业资讯频道。
