前言

ProjectS已正式启动，准备先搭建项目框架以及整理工作流程，框架方面准备进行如下开发工作，为日后的业务开发铺好道路

接入 ET 7.0
接入 huatuo C#代码热更方案
接入 YooAssset 资源热更方案
接入 FGUI UI方案，并提供MVVM UI框架
接入 luban 配置表方案，并提供周边工具链
接入 UniTask，全量替换ETTask
全面移植 NKGMoba技能系统，及其周边工具链

文章主要描述各仓库接入思路和过程，目前已完成接入工作，并已开源，https://github.com/wqaetly/ET/tree/et7_fgui_yooasset_luban_huatuo，已经在最大限度上保留ET特点了，并且存档了一个Release：https://github.com/wqaetly/ET/releases/tag/et7_fgui_luban_huatuo_yooasset，追求ET原生开发体验的朋友可以下载体验了。但对于我个人而言，使用起来还有诸多不便，所以还会再进行魔改，望周知。

留个封面背景图：

ET7

ET7于前阵子发布，虽然还没有正式Release，但相比于ET6，彻底剔除了ILRuntime，使得代码简洁了不少，并且比较稳定，是个接入的好时机

问题

程序集拆分导致的开发不便

ET从6开始，就倾向于将4个热更程序集全部移出到项目外。一般项目这样做做好csproj引用并没有什么问题，但是ET特殊的地方在于它是全热更的，这就导致需要用到热更代码的编辑器开发工作无法进行，比如技能编辑器，剧情编辑器，地图编辑器等

所以无论如何我们还是要将这4个程序集移回Unity，保证开发体验，但还需要保证4个程序集相互之间引用是正确的，所以不能直接往Asset里移动，那么唯一的方案就是移到Packages目录（感谢 @闲蛋超人提供的思路），即专门创建一个hotfix package存放4个程序集原代码文件，并将其asmdef编译选项设置为仅Editor可用

尤其需要注意的是，如果编辑器工具需要对数据进行序列化反序列化，并且在运行时使用，一些序列化库例如Odin要求是强类型数据，这时候如果我们在Packages下的热更程序集名称和Assets外部的热更程序集名称对不上就会导致序列化失败，所以需要保持一致，具体操作可见项目源码

当然，如果没有编辑器工具开发的需求，还可以设置asmdef的Define Constraint为自定义编译宏，这样只有这个编译宏开启的时候Unity才会去编译这个package，但请注意，也只有这个宏开启的时候编辑器工具才能正常引用热更package里的代码

此外，编译程序集使用的是Unity的编译系统，这样其实我们hotfix package代码和Asset中那几个热更asmdef引用的热更代码是冲突的，所以还需要在编译时将package中热更代码剔除掉，这样一来即可达成 既满足编辑器工具开发需求，又能实时得到热更程序集的编译错误问题，还不会破坏热更程序集之间的引用关系，一举多得

为了保证项目规范，我们需要在csproj里工作，而不是我们创建的用于保证编辑器开发引用的Package里

YooAsset

基础框架处理好就该处理资源管理了，毕竟资源管理是后续几个模块的基础，这里选用YooAsset，在开源资源管理方案里，YooAsset是周边基建（运行时资源引用Debug工具尤为强大，可以及时发现资源泄漏的情况）和稳定性最佳的其中之一（可惜了GameFramework资源管理模块和框架绑定）

YooAsset功能很多，比如资源分组，原生资源加载支持等以及后续的SBP适配计划都值得期待

将YooAsset接入ET过程中没有遇到什么问题，唯一需要做的就是做好ETTask封装以及Operation的管理维护，具体操作可以查看仓库相关代码

huatuo

huatuo介绍：划时代的代码热更新方案huatuo源码流程解析，作为新兴的基于IL2PP的C#热更方案，huatuo以碾压的姿态冲击了所有Unity代码热更新方案，饶是ET用了非常多C#高级语法，仍然只花了一天时间就接入完成

对于ET来说，唯一需要做的就是准备好用于AOT元数据补充的dll即可，否则会有类似ExecutionEngineException: metadata type not match的错误，除此之外，没有任何的额外工作！不需要适配器，不需要重定向，不需要代码生成。

此外，等待huatuo AOT Hybrid技术发布后，我们的热更就更加简单，性能也更高，可以直接无脑AOT发包，然后无脑补丁包热更逻辑

顺带一提，GameFramework也有同好做了huatuo热更适配，感兴趣的可以去看看

luban

luban是当前业界游戏配置表方案开源当之无愧的第一人，它不仅支持各种容器，复杂结构，还支持OOP，以及json与Excel的互转工作

支持OOP这个就很厉害了，这意味着我们完全可以把一些原本只能存在Unity编辑器里的一些配置（比如技能配置，Buff配置，行为树配置等）存到配置表中，这样有多个好处

配置存在Excel中，将不会再出现由于配置类结构变动而导致序列化数据丢失问题
编辑器下编辑的数据可以直接反导到Excel中，这对于大量数据的管理维护是很有帮助的

此外项目中用到了 https://github.com/LiuOcean/Luban_Unity_GUI 的Unity插件，它支持我们在Unity里配置好luban导出参数，然后直接一键导出配置表，当前还有一些功能需要支持完善，比如支持配置多套配置，比如client一份配置，server一份配置等。大家可根据自己喜好和需求进行魔改

luban本身还是有一定的学习门槛的，当然这个学习门槛是对于我们程序员来说，因为我们需要为自己项目搭建维护一整套基于luban的工作流程，luban的文档很全面，基本上可以得到任何自己想要的信息：https://focus-creative-games.github.io/luban/，策划是只需要熟悉luban的配置规则即可，可以参考：https://github.com/LiuOcean/Luban_Example/tree/main/Data/Excels