自上而下对应
Config
提供了全局配置的读写功能，可用，但是没有意义，因为直接用1个全局静态类，直接读写就好了，更高效方便。而二进制功能需要的话，用scripObject方式也可以。
DataNode
可以设置任意类型的组件
DataTable
二维表功能
Debugger
可用，且需要。
DownLoad
不用，后期的话，下载只存在于资源加载与管理里（上层业务不用关心），上层业务基本不会显式的调用下载。而且下载模块需要持续迭代，且下载会有需要深度定制的需求。
Enttiy
不用，场景相关的，提供的框架意义不大，且ava的处理方式，重点在于解决多个资源异步，以及避免上层业务使用异步接口，这个问题没解决。
Event
可用。 事件系统
FileSystem
可用但不必需。虚拟文件系统
FSM
需要有限状态机，但是看不到所有代码。待评估
Localization
不可用。因为实际项目的字符串，是按句子拼接，现在的功能不够强大。
Network
应该不需要网络部分。
Object Pool
后边再用，基本只要长度缓存即可。
Procedure
流程类，后边会深度根据项目定制。
Resource
资源类，ResourceManager接口实现错误，不可用。
Scene
实现有缺陷，先不要用（用了后边也好改，因为用的地方不会多）。
Setting
本地数据存储，可用但没有意义。
Sound
声音，依赖了Resource模块。
UI
UI模块，从提供的接口的来看，后边需要二次开发。这倒不是框架的问题，而是不同的项目有自己的设计。
且它不是完整的UI解决方案，后边应该还要做代码导出，组件扩展，辅助方法等等。最好有源码能再评估下。
UIGroup的功能是不是项目设计需要的也不确定。不过
层级的管理可能也需要改变，得看设计。
WebRequest
可用.提供了http功能
总得来说：
1.各个module之间没什么依赖，有依赖的基本依赖ResourceManager和ObjectPool,以后移除也方便。
2.注意很多地方用法，现在的package,容易误导人，使用各类Component，其实是可以直接使用module对应的manager方法。
3.重点使用下UI模块,接口设计可能需要修改，但是并没有错。
4.需要源码
标签：需要,可用,接口,后边,UI,模块,GameFrameWork,调研 From： https://www.cnblogs.com/marcher/p/17090284.html