为什么要做二次封装
GameFramework 框架本身是个很优秀的，完整的商用框架，覆盖到了常用开发的各个功能模块，扩展性也相当出色。但框架本身稍显复杂，对上手框架不是太友好。
- GameFramework 是比较底层的框架，要考虑到不同游戏的需求，所以导致接口量很大，而且混合了不同游戏的场景，理解难度大。
- GameFramework 使用了大量的接口和继承，这两种方式对底层框架来说也许是必要的（增加框架的控制力），但同时也大大增加框架的复杂度，因为接口和继承都意味着实现的不确定性。复杂度 = 不确定性。
- 有很多超大类，融合了太多职责。比方 ResourceManager 有差不多6000行的代码。其实建议可以按业务职责进行代码聚合和分类会更好一点。
框架太复杂，接口多，理解和调试难度高，会造成团队里不同的成员对框架的理解和使用不一致，增加多人开发项目的管理难度。所以就萌生了对其进行二次封装的想法，大致思路是
1.对GameFramework的功能组件，再封装一层单例管理类 XXXMgr。
- 统一通过GameCompMgr获取GameFramework的功能组件。
- 业务层只能调用 XXXMgr，到时如果想改用自己的框架，只要把接口重新实现一次就可以了。
- XXXMgr封装了对框架组件的使用接口，只保留开发常用的，必要的接口，有需要再开放新的接口。这有利于保证团队对框架使用的一致性，而且接口少了，且和业务贴合，更容易理解。
2.代码根据实际业务功能来组织，而不是按分层来组织。这样代码会更模块化几点，更内聚一点，方便实现业务功能实现的一致性。耦合度低，功能的新增和移除也更容易。
一.专栏介绍
-
本专栏参考自 PassionY 的 GameFramework专栏目录，可以看成是对它的补充，所以基本会按照相同的目录结构，更多从使用的角度来进行补充。读者可以两边参考着来学习GameFramework这个框架，相当于两个不同的角度。
-
项目 github地址，通过二次封装，重构 starforce 的实现。可以先check out 出来跑一下，我用的是 Unity 2021.3.6f1 版本。但应该是2017之后的都支持，没有实测过。
二.GameFramework 参考资料
PassionY 的 GameFramework专栏目录
三.专栏目录（这里会按发布文章陆续整合进来）
GameFramework 开发脚手架之 项目的目录结构介绍
GameFramework 开发脚手架之 Procedure 流程管理
GameFramework 开发脚手架之 Config全局配置
GameFramework 开发脚手架之 Setting配置存档
GameFramework 开发脚手架之 DataTable配置表模块
GameFramework 开发脚手架之 DataTable配置表 导表工具
GameFramework 开发脚手架之 Resource资源管理器
