GameFrameWork调研

 

自上而下对应

 

 

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模块,接口设计可能需要修改，但是并没有错。

建议使用：

Config	不需要
DataNode	不需要
DataTable	不需要
Debugger	可用
DownLoad	不用
Enttiy	不用
Event	可用
FileSystem	不需要
FSM
Localization	不用
Network	不需要
Object Pool	先不用
Procedure	不用
Resource	不用
Scene	不用
Setting	不需要
Sound	可用
UI	可用
WebRequest	可用