本人引用但未注明的版权资料，可邮件联系 （不是故意只是懒~）

2025-04-28

人还是比较懒，虽然更新了很多代码（同时维护四个以上的框架，还是没时间更新文档）每次打开又要重新组织语言，还是得保证人能看懂（尽管写的比较散）

• 像 Anywhere 现在叫 Zen 新增了大量模块 （比如 ECS版网络Module，Multiplayer 多人联机 Module 等, 哦 当然 Kpb序列化终于实现C#版本，（基于最早的C和Go版本已经过去了近两年，所以整个来说确实 挺墨迹的， 倒不是难而是懒，总觉得同一个算法写三次感觉脑子瓦特了，哈哈~

• skynet 最早是为了解决云风大佬一些特异化场景而驱动开发的，但现在已经完全像个学术派 （ 把Go写成浓浓的C style味），果然还是喜欢折腾

• 前阵子翻了翻几年的库，自我感觉写的一般，又拿出折腾了一番

• 总之尽快更新新的文档，后续先提供可用版本，至于开源的事再考虑考虑，（毕竟国内，吃干抹净，过河拆桥的人不在少数，至少本人用开源保留 copyright, 也会提 issus 促进发展 ）

事件总线

消息订阅，发布是每个服务器都必备的机制，当然 skynet 也不例外，而且更加优雅。

绕不开传统的事件订阅流程，skynet的事件总线是一个process,意味着

1. 所以事件订阅发布都是异步的，

2. 所有消息的发布是可调度的（参见上节 scheduler）,

3. 可以通过控制独占来解决事件总线的调度频率

emm… 似乎也没什么好些的，eventbus更像底层某些机制的封装，了解即可

序

还没写

序

还没写

序

还没写

序

对于一个源码文件而言，里面的内容只是一个个字符，机器是无法识别的，而词法分析器的作用类似于转义器，将一个个字符拆成若干个有特定意义的词，而这一过程称为词法分析，此时它也不能被机器(或者这个虚拟机)识别

序

还没写

这篇文章将会是一个系列，更新会比源码慢，文档写的也不会写的很完全，名字暂定 typelang, C syntax-like

设计缘由

早在2019之前就想开发一门脚本语言，一是加深编译原理的理解，二是觉得程序员不应该消耗在语言特性上，也一直想为自己的服务端框架 skynet 写一门dsl，现在是用lua作为服务的脚本端。但由于的若约束性导致在开发的时候很多同时并不够优雅，总是以一种奇怪的方式来解决问题，Lua本身并没有任何问题，它被设计之初是为了修补C的不足，但它的语法设计却并不符合我的预期。

尽管它的性能是脚本语言中顶尖的，但是一些隐式写法并不能保证它的预期性能，如混合table,过多的函数调用栈，字符串操作以及无类型系统。

关于类型系统有利有弊，但我个人的观点是宁愿多出30%的开发时间，从而减少70%的bug。

简介

Beam 是一个全自动化，且简单易用的资源管理系统, 它只提供资源的加载和管理方式，不提供资源的解析方式，意味这它是可以跨引擎使用，这里只指出它在Unity中的部分，他本身只会管理文件的依赖 （manifest）以及 文件句柄资源 （在 C++ 中叫 fd，在C#中成为 FileStream）

Feature

1. 自动化检测文件变动 通过Radix算法，监控资源变动，来自动构建manifest。上层只需要关注资源本身，无需关注AssetBundle包的构建。可做到对上层完全无感。

2. 自动化引用计数 通过 RC+ finalizer，监控资源的引用，来自动释放资源。且无需轮询检查资源的引用计数，提供更好的性能，做到对上层完全无感。也没有手动释放接口，提高安全性和易用性

3. 自动化冗余剔除 在构建的时候自动收集冗余资源，如像A->(C,D) B->(C) 此时(A,D)将会作为一个的bundle，而C则会单独作为一个bundle

4. Profile资源使用分析，用以在运行时统计各个资源的引用和加载数

5. 自定义流处理，支持加密等自定义操作

6. 多种模式支持

   1. Builtin: 内建资源，默认将资源插入母包中。

   2. Remote: 远程资源模式，仅需要配置远程资源地址即可，所有资源不会在本地存盘，只会在内存中使用，使用完后立即释放，防止被反编译资源

7. 无感知资源更新 一般出现资源更新的时候，都是先下载到本地，然后再通过加载本地资源的方式实现， 现由FS映射的远程目录，通过分流的方式，可以实现一边从远程直接读取，并copy另外一部分流到本地磁盘，减少重新读盘的情况。 对于下载过程对于玩家而言完全无感，其本身下载速度是可以被控制，当前并没有暴露此接口（因为带宽值是动态变化的，无法根据不同的条件找到一个合理值），只是需要设定一个百分率阈值，内部自动计算下载速度尽可能保证达到预期值。

8. 淘汰策略 当某个Assetbundle的引用计数为0时候，底层不会立即释放它，基于引用计数+ LRU 淘汰机制，当然也提供了强制卸载函数。

后续计划

现阶段Resource是依赖于Assetbundle 后续会抽象出一层 FS 以提供自定义流提供更多可操作性和安全性。 已实现

Resource现在可以说是完全不能脱离Unity独立运行，这不是一个好的方式，我期望提供更高的抽象满足多个引擎的需求。当完成这一步时只需要在Unity中需要手动实现一个Adaptor即可。

简介

DatatableModule 是一个基于 kpb 编码的配置文件管理系统,它定义了一个配置文件的数据结构，并提供了相应的API来操作和访问配置文件。在Zen中它是一个GameComponent。它包含了一个代码生成器，和数据解析器和编码器。

数据表的加载只有4(2)个接口 LoadDatatable<T>(bool lazy) GetRow<T>(int row) 以及一套同作用的异步接口，前者获取一整张表，后者获取某表的某一行数据，即对应的数据结构体。

Datatable 静默行为是 Lazy load 对于同一张数据表，它只会根据需要读取指定行然后才缓存，而不是一次性读取所有表格。

Feature

1. lazy load,它不会加载表格的所有数据，而是按照需要动态一部分一部分的加载，直到全部加载完毕。

2. DatatableModule 加载接口提供同步和异步两种模式，也可以加载远程资源，依赖于 Resource

3. DatatableModule 提供代码和数据生成的编辑器，无需关注实现逻辑。

4. 多种类型数据支持 bool,int,float,string,binary,int*,float*,string*,满足绝大部分场景 （2024/05/23）增加了定长数据的支持，减少内存消耗。

5. 基于kproto编码协议，极小的二进制文件，以及极快的编解码速度。

6. 栈内存映射，大部分情况下不需要开辟堆空间，节省一部分堆内存的分配，减少Mono Reserved的分配。