欢迎光临散文网 会员登陆 & 注册

Unity 组织结构小记

2023-04-28 15:07 作者:防辐射君  | 我要投稿

1、使用依赖注入管理组织容器

解耦的最好形式之一就是IOC容器,市面上很多现成的东西都可以用,实在不行也可以使用一个简易的方式实现管理。

针对问题:老版本中充斥着大量持久化单例,用单例可以,但要注意其生命周期。(内存问题)

相关文档学习链接:

https://www.cnblogs.com/artech/p/asp-net-core-di-ioc.html

2、尽可能少使用魔法数(常量),要用配置化制作

老版本中很多配置化的东西,也使用直接写在代码中的形式(甚至不以变量的方式管理)制作,导致修改时需要对一系列相同变量,跨文件、跨区域进行修改,重复性高,影响系统稳定度。

此外采用配置化,与产品部分需求对接也有便利。

3、项目组织管理

对外:

  • 与外界合作沟通上要有明确标准。

对内:

  • 注意使用程序集,优化编译速度。

  • 严格划分模块,以功能的形式?以模块的形式?以文件夹的形式?(待定)

4、一切事物均加载

老版本中包体过大的原因之一,就是在于很多资源由于在场景下挂载,实际上被打成了一式两份,因此。

场景内只留起动器及相似功能物体,其余均用加载的方式生成,同时严格遵守表现逻辑分离原则。

5、新架构

架构一

重度依赖Unity,但要配合第一点使用Unity外相关代码,同时注意脚本内容职责单一化,管理方式可参考官方推荐管理方式。

https://github.com/UnityTechnologies/open-project-1

https://github.com/UnityTechnologies/open-project-1/wiki

架构二(或许太麻烦了)

仿传统网络框架搞的一套

最理想的模式就是用这套仿网络框架的架构来运行游戏,模块间使用接口进行隔离,无需知道其实现细节。

这么做有额外的好处就是便于做单元测试、替换性强,可以直接替换任何模块。

框架搭起来成本或许会高,但是最终可以真正意义上做到及换及用,甚至可以作为公司游戏通用框架,因为不用考虑业务需求,只需考虑实际内容。

6、状态机控制流程

老项目的问题在于,没有明确的节点做一些切面操作,如加载器、游戏状态这种。

使用状态机控制后,可以避免老版本中在一个节点做了太多的事情。

7、新的UI系统

老版本UI Manager最大的问题就是他不是个UIManager,实际上是一个资源加载器,它缺少一切UIManager应该具有的功能,如弹窗队列、更新UI数据等。

可以针对第二点和第五点中的render部分进行相应设计。

8、资源回收(待议)

Unity中要在OnDestroy 或 OnDisable中做一些收尾处理

非Unity内容,要在销毁时做一些释放处理?

9、开发扩展器组件要加入日程

一些增加开发效率,避免重复性工作的事情要做成一键式

导入地址关联

打包前一体化配置工作?

debug调试功能最好编辑器,实体一式两份?

10、事件系统

之前使用过的SOChannel系统,只能做Unity层间通信,基于需求可能要对其修改,或使用更通用的事件系统?(待议)

11、引用公共库内容

目前根据名字判断,可以也许可以引用的有:

  • 日志库

  • 实验库

  • 存档库

  • 多语言库

具体引用及其表现还要与相关维护组进行咨询。

12、使用启动器启动

在游戏中有一个单进入点,用于初始化和保存全局对象。这将帮助咱们创建、配置和维护全局对象:广告管理器、音频系统、调试选项等。同时可以设置并显示系统初始化顺序,构建依赖关系图。

Eg:

13、使用叠加场景模式

对于预制体来说,始终牢记一点:一旦对预制体(基本上是任何其他对象)的引用实力化,其内容将完全(递归)地加载到内存中。这意味着,包括纹理、几何、其他引用的预制件、音频剪辑等在内的所有资产都将同步加载到内存里。它们是否被实例化并不重要,因为实例化过程只会创建一个浅拷贝,然后调用Awake/Start/OnEnable/...方法。

因此解决方案是有一个根场景(例如主菜单),然后根据需要以加法和异步方式动态加载和卸载场景。它们将自动堆叠在一起,尽管仍然要小心画布排序顺序。这种方法比预制体加载更先进一些,有相当大的好处:

  • 内存占用空间大大减少,因为您随时只加载所需的目标场景的内容。

  • 加载时间大幅度缩短,因为处理、加载和反序列化的时间要少得多。

  • 合并时避免了很多版本冲突,因为项目被分成较小的独立部分(场景),而不是所有人都在一起工作。

  • 产生的层次结构更干净、组织良好。更好的组织意味着更有效的工作。

14、命令模式

编程界黄金法则之一是:负责开始一个过程的对象也应该负责完成和清理它。

在这种法则下,一个有效的想法是命令模式。这种情况下一个行为可以被视为一条流水线。

命令是一个可实例化的类,用于包装方法调用,并在完成后销毁。这有利于我们可以用对象变量的形式沿其异步调用存储时间信息。命令确实以干净的状态开始和结束,并且只有在有最终结果(数据、成功/失败)时才会返回。

通过使用协程,Unity可以很好地利用这种模式。




Unity 组织结构小记的评论 (共 条)

分享到微博请遵守国家法律