你说得对，但是EmiteInnaACTSystemFramework是一款由EmiteInna自主研发，适用于PC平台的Unity第三人称上帝视角3D动作游戏代码框架。您将在游戏里扮演一个名叫游戏程序的角色，通过跳跃，冲刺和各种各样的丝滑小连招击败你的对手，修复程序中的bug，找回失散多年的代码能力，发掘未知的设计模式和模拟算法，揭开游戏行业无法入行、毕业即失业的真相。

本篇是ACT系列之一，github仓库位于：https://github.com/EmiteInna/EmiteInnaActSystem

简述

对象池采用和JKFrame差不多的模式，不过把go和object合一了，是否合理姑且不论（7.18更新：现在看来就是不合理- -），基础是个queue。采用了service来整合成dictionary，理论上可以存在多个service，用静态单例作为访问入口。

存在的问题一是在读取内容的时候如果池里的对象不够，那么会用一开始的prefab去创建，而对于其它类型的对象来说，在没有初始化的情况下无法直接去取对象，而jkframe是可以的。

配置系统采用Odin的so，让我们能在unity里直接编辑字典，非常的好用，同样是用service+单例的管理模式，使得一些全局配置能被访问到，大量使用字典的好处是构建代码非常方便，坏处是在Editor端可能会比较卡，所以后面也会用AB包来管理。

说起AB包，现在之所以没有在底层搭建的时候直接用AB包或者其它资源管理手段，是因为如果这个框架所制作的游戏体量比较小，我们完全可以直接加载资源，而作为学生党，其实我大部分时间都在做这样的游戏……但是资源管理当然是非常重要的，毫无疑问。因此我决定一开始先不用资源管理模块，而是采用尽量减少物体之间的相连关系、尽量将大部分配置文件独立开来，然后用一个配置文件去索引配置文件的手段去代替资源管理，实际上等到替换成资源管理的时候只需要去取代这个索引配置文件使用的部分就可以了。

为什么要这样做呢？一是时间比较紧张，二是我并不能保证自己搭建的底层非常稳健，我尽量将搭建底层这件事做到会的都做，不会的用已有的东西取代，来避免底层的构建反而影响了上层的功能实现。

内容

学了jkframe的方法，构造是一个Pool类，底层是一个Queue，一个PoolService，用一个字典来索引Pool，然后是一个静态类，用来从其它位置来调用Service。

对GameObject的处理上，我采用了如果不够的时候会按照第一次创建Pool的时候的Prefab来创建缺少的GameObject，而且我选择了在一开始的Core类（相当于负责整个框架内容的一个初始化的工具）里创建对象池，而不是在任何地方都能创建，虽然有利有弊，但是管理比较清晰。

配置的方法在上一段里其实已经说明过了，具体而言就是，通过一个叫ConfigureService的SO文件存一个字典，里面索引着名字和一个object，其实类似Addresable的管理方法，但是只是表面功夫，然后在这个Core里去指向这个ConfigureService，从而实现在全局上可以查找任何资源而不用考虑依赖关系的功能。

别骂了，以后一定改。