1.音乐音效管理器：
如果策划没提特殊需求之前，其实封装一层音乐音效管理器用途不大。如：播放音乐接口里面封装的可能就只是一句调用引擎的播放音乐接口的代码。 可如果游戏里面都使用管理器的接口播放音乐，以后策划的一些需求就好统一处理了。如：策划要求播放A音效时要停止B音效播放，那我们就可以统一在管理类里面处理了。
2.界面管理器：
这个管理器最为重要的就是维护一个数据结构（根据不同项目的实际情况来自定义数据结构）。 数据结构如： 一个array，里面顺序保存着当前打开的界面，array里面对应的值就是每个界面需要记录的一些必要信息，如：打开界面时传入的参数、界面的zOrder、界面的名称等……
每次打开和关闭界面都通过管理器执行。
期望管理可以实现如下功能：
（1）可在界面打开或关闭时统一处理一些任务。（包括等待服务器数据返回、预加载和释放资源等）
（2）随时知道当前显示最上层的界面是哪个。
（3）切换场景再切换回来，可以按照层级重新打开之前开着的界面。
（4）应对类似【强化–探险—强化】这种界面循环打开的情况。
（5）还有太多太多太多可实现的功能了，看项目需求………………
3.数据管理器：
游戏的核心数据层。监听所有服务器返回的接口，不同更新服务器返回的数据。我们想要做到的，就是无论什么时候，从数据管理器里拿回来的都是最新的数据。 而且我们也可以封装一些需要计算的2级属性，如：当玩家升级时，体力值变化了（1级属性），那我们同步体力值的同时，也同步结算且更新玩家的HP（根据体力值换算的2级属性）。反正玩家只管在数据管理器中拿数据用就是了。 当然，为了避免数据管理器超级庞大，管理的主要还是整个游戏的一些通用数据，某些系统的部分特殊数据，可以交给各自系统的系统管理器去管理。
4.通用方法类：
个人觉得可以分成三种类型：
（1）和游戏相关的，如：创建通用的头像框、创建一个通用的动画特效等。
（2）和游戏无关，和引擎相关的，如：获取本地可写入路径、读写本地缓存的封装。
（3）和游戏与引擎都无关的，例如加密、解密、时区换算等各种算法。
通用方法的必要性不必多说，一人付出，众人受益，分成几种类型的目的也主要是为了以后做其他新项目方便移植。
【实用性技巧|游戏框架设计【各大管理系统篇】】5.消息分发器：
个人觉得是一个很重要、很方便、很好用的一个解耦神器。
观察者模式，界面与数据分离的最佳伴侣。不止界面与数据，各系统之间的消息通讯同样可以通过消息分发来通知状态改变。
