本节是对框架整体的概览，对比了与1.0的区别（不必在意区别，不影响理解），各系统的文档分为两类，原理性文档和使用手册，本框架由Joker和ParKS共同开发，中文课堂连接

独立游戏程序框架2.0

文件结构调整

框架2.0对框架进行分层设计，每个系统有若干可用的功能模块进行装载，不同的模块有着不同的功能，如资源管理系统可使用ResManager也可以使用Addressable。

alt

单例模式弃用

在1.0中，为不同的管理器设立了若干单例模式，在实际应用过程中，管理器挂载在GameRoot下非常繁琐，并且我们只需要其中的方法，并不需要实例化管理器本身，所以取消使用单例模式，使用静态工具类且比单例更快，因为静态的绑定是在编译期进行。

当需要面向对象的能力时（比如继承、多态）时，选用单例类，当仅仅是提供一些方法时选用静态类。

  • 单例模式会提供一个全局唯一的对象，静态类只是提供很多静态方法，这些方法不用创建对象，通过类就可以直接调用 。

  • 单例模式的灵活性更高，方法可以被override（需要将单例的私有构造函数改为protected），因为静态类不能被继承，所以不能被override。

  • 如果是一个非常重的对象，单例模式可以懒加载，静态类就无法做到。

  • 单例模式会使调用单例的各个功能模块耦合程度提高，如果直接对单例扩展可能会导致多处调用的地方出错，不利于维护和拓展。

对象池系统扩展

对象池系统有两类对象池（GameObject对象池和Object对象池）分别负责对需要在场景中实际激活/隐藏的GameObject和不需要显示在场景里的对象（脚本类、材质资源）进行管理。

相比1.0的对象池系统，由1.0的两层（PoolManager和PoolData）变为三层来提供对象池私有化并增加了对象池的容量限制、默认容量、对象池可视化功能：

  • PoolSystem层封装了两类对象池的所有操作，但与数据无关，仅包含逻辑，作为静态工具类，管理着全局对象池。
  • PoolMoudle层的两类Moudle包含对每一类对象池中所有池子的具体操作，并负责层物体和对象池字典的创建。
  • PoolData层包含了对底层具体的一个池子数据进行操作

这种设计使得外部调取System实现逻辑时与底层数据解耦，便于进行维护，且可以让某个对象通过持有Model层获得自己特有的对象池，像框架中其他模块如果有用到对象池就可以持有PoolMoudel，而与全局对象池无关，因为我们不希望用户清理全局对象池的时候把框架模块内的对象池缓存数据也清除。

提供对容量的限制，且初始化时，可以预先传入要放入的对象根据默认容量实例化放入对象池，比如场景中默认使用20发子弹，可以在对象池初始化时就实例化好20枚子弹放入对象池。

此外将层物体（每一种对象池的父节点）和poolData类本身分别用GameObject对象池和Object对象池进行管理实现资源重复利用，可以理解成鸡蛋和篮子，将鸡蛋（数据）清空后，篮子（载体）留作备用。 篇幅原因，详见链接。