Server

• 一个引擎内部代码组织代码概念，主要用途是用来将引擎内部一些比较独立系统组织起来。
• 只是一个逻辑概念，代码上没有一个框架，都是每个Server按照自己的情况去创建。
• 嵌入到引擎也是通过Hardcode（例如在main.cpp初始化某些Server）
• 一般来说每个Server都是有自己一套线程运行，跟主逻辑线程主要依赖CommandQueue（引擎提供），主线程一般只在需要的跟Server做同步（例如物理、渲染）
• Server本身是一个Object，可以发送信号到场景对象。
  

Modules和GDExtensions

• 两者都是C++扩展引擎的方式，主要区别是Modules是以静态方式编译进引擎，GDExtensions是动态库方式。
• Modules功能更全，因为和引擎一起编译，可以访问所有的API。不过官方承诺如果发现GDExtensions实现不了的功能，可以提Ticket，尽量保证和Modules功能相近。
• GDExtensions编译更快，Modules修改需要重新编译整个引擎（但是我觉得只要依赖正确，基本多不了多少时间）
• GDExtensions由于是二进制，可以使用其他语言开发（社区有个Rust的）。大概只需要将引擎的API导出到Rust就可以（不过引擎API的二进制兼容性如何？）
• iOS不支持动态库加载，GDExtensions似乎无法使用，也没法直接将GDExtensions静态连接到ios。

参考：

• What is GDExtension?
• Why does Godot use Servers and RIDs?

周日心血来潮开了一下Unity，突然想起之前有一个据说秒天秒地秒空气的热更框架huatuo，打算找来研究一下原理。

搜索了一下，发现huatuo已经归给掌趣，作者后来自己开了一个HybridCLR。知乎、B站、Google搜了一圈，发现基本都是同样的内容，像极公关稿。说什么工作在IL2CPP层、没有虚拟机、性能牛B、开箱即用，玄乎到不行。好奇行心驱使下，看了一下源代码，大概明白工作原理：

1. 在IL2CPP生成完Unity自身C#对应的C++代码之后，插入一些HybridCLR的C++代码，其中包含所谓的interpreter和transform。
2. interpreter本质就是一个虚拟机，用来执行HiOpcode。
3. transform就是用来做IL->HiOpCode转译
4. interpreter传宣是register based，但是代码看来就是stack based。不知道作者是否有商业版本的实现
5. HiOpCode就是基于Unity的一个特化指令集。只要指令集命中的执行效率肯定高，除此之外通用性能可见的不太理想。另外虚拟机的指令集是变长的，想要优化效率估计有困难。可以简单类比CISC和RISC的区别。
6. 相比现有脚本解决方案，绕一层C#再到引擎接口，HybridCLR直接通过interpreter调用IL2CPP::vm接口，确实性能会有优势。还是那个前提，只要你的代码能命中特化的opcode。
7. 这个方案的本质还是Unity不提供纯C++库的调用方式。IL2CPP::vm这个胶水层虽然比直接C#要薄，但是相对纯C++接口还是太厚了。如果Unity自己能提供一层C/C++的封装（类似fmod那样），对脚本接入就不用这么纠结。

综上所述，HybridCLR所获得的性能提升主要在更薄的胶水层和特化的OpCode；相对应的通用解析性能可以预见的不高（盲猜，没有任何证据，不用杠。杠就是你对）。对于纯C#的项目，想获得一些热更修复的能力，可以考虑。如果是想达项目的脚本化，HybridCLR估计有难度。

ILRuntime的原理其实也类似，只是我记得最早ILRuntime是直接运行IL OpCode的。今天看了，好像也用了类似的方式。

今晚在整理以前的笔记，发现一篇关于cocos2dx renderer的设计摘录。cocos2dx可以说是我客户端之路的启蒙引擎，对我有很大的启发，也跟随着我经历过一段神奇的工作经历。好奇心驱使下，去搜了一下目前的状况。发现2018年基本已经停止更新，最新的版本也停留在v4.0(2019年)。后来的替代者是cocos-engine。简单的浏览了一下文档，虽然增加了不少新的特性，绑定语言也变成了TS，从代码树来看似乎也继承了cocos2dx部分代码。但是整体的功能和设计不要说跟双U比，就算跟目前的后起之秀GODOT也差了不少，论坛也比较冷清。

这不禁使我思考，为什么当时如日中天的coco，为什么后来会掉队呢？

崛起

cocos2dx其实是从coco2d的’翻译’过来的（我记得后面甚至原作者也跳到cocos2d）。coco2d是一个基于ios objc的2D引擎，一开始定位就是做2D小游戏的。在这样的背景下，再加上钓鱼达人在手游的爆火，作为幕后功臣的cocos2dx自然得到更多人的关注，而当时正处于手游崛起时代，国内（国外）游戏引擎近乎空白。cocos2dx自然顺利成章的’补位’。

转折

对于cocos2d-x v2.2之前的历史我所知不多，但对于v2.2以后甚至v3.0的版本，可以说这个引擎的巅峰，时间大概是2012-2015年。伴随着各大传统厂商入局手游，市场迅速扩大。cocos2d-x可以当时游戏研发的唯一选择，当时的触控科技可以说是当红炸子鸡。触控当时也看到移动设备的性能不断攀升，推出了重构了渲染层、’支持’3D的v3版本。在我看来，正是这个风向的转变，让cocos2d-x从第一梯队掉队。我认为主要原因：

1. 兼容性。V3当时的定位是V2的迭代，迭代了渲染队列和增加能显示3D的节点Node3D（如果我没记错的话？）这就导致花了大量时间的V3实际只是一个能显示3D模型的准2.5D引擎。从现在我个人的角度来看，如果要做3D的话，原有的引擎API根本不适合，单说场景管理这块就已经很头疼。另外3D引擎的工作流需要有很强的定义和整合能力，当时cocos2d-x也是一个渲染引擎，根本达不到这样的高度。与其从V2兼容迭代，不如另开炉灶，做一个领先时代的新的产品。事实上触控后面也开了Cocos Creator，UE3->UE4也是完全重写（虽然用了不少UE3的代码）。
2. 稳定性。对当时cocos ui 编辑器的稳定性印象深刻。每天都会crash不少次，还会有一些性能问题。即便是后面的版本也基本没有太多改善。对于inhouse的工具，可以忍；作为一个产品几乎无法接受。
3. 技术滞后性。cocos2dx很长一段时间都是以一个单独的渲染引擎+UI编辑器存在。直到后面Unity出来，才发现可以将所有东西整合在一起作为一个编辑器。这时候Unity已经以技术领先态势抢占市场份额。回头Unity在3D引擎的基础上开发出2D引擎的内容把cocos2d-x仅有的2D市场也吃掉。

总结

其实，无论你之前处于什么样的领导地位，只要一次没跟上时代的步伐、看清楚形势就会被时代抛弃。无论是对于个人或公司，触控如是，诺基亚如是。反观同样是有自己产品和引擎的E宝，在Unity已经抢占手游市场的大半江山，依然能通过开源占领市场，并利用自己技术优势和不断迭代，重夺引擎市场桂冠。可惜，触控始终不是Epic，时代总要翻篇。

认真的看完这个DEMO两次，结合当前自己的状态，感触很深。PS：游戏终于能进入高分辨率时代（伪）。PSS：为什么两个总监都这么年轻啊？