看天龙的结构,奇怪为什么这么多直接继承了MonoBehaviour,而不是自己实现一套帧频更新呢,两者利弊都在哪?
从顶层来看看GameManager的单件。
管理了当前的载入的场景(ActiveScene),任务管理器(MissonManager),表数据管理器(TableManager),声音管理器(SoundManager),网络管理器(NetManager),主角数据(PlayerData),其他玩家数据(OtherPlayerData),自动寻路接口(AutoSearchAgent)。这些管理器在后边打算逐个分析下功能与设计。可以看出来他们都是作为MonoBehaviour脚本挂到同一个GameObject上,注意是动态Add上去的。
GameManager在Start时,其实就是载入,但未执行本GameObject的帧循环前,会执行初始化。并检查如果内存如果小于768,或者处理器个数小于2,就认为是低端机,设置成低端机,能自动控制什么呢?此外,会把NPC的刷新时间从0.06秒改成0.09秒。这里他取内存的方式其实挺简单的:SystemInfo.systemMemorySize,不像我现在做的,从Android里取出来,再送到上层,结果其实是一致的。
此类提供了数据加载的功能。维护了一个WWW类型的成员rawWWW,这里不得不吐槽下,命名规范很不统一,有的是m_XXX,有的是XXX,挺乱的,个人还是觉得统一点好。
看看他的数据加载
public void GetRawData(string strPath) { base.StartCoroutine(this.GetWWWRawData()); } [DebuggerHidden] public IEnumerator GetWWWRawData() { ... ... return <GetWWWRawData> c_Iterator; }
Unity的WWW加载是异步方式,因此需要用请求,然后等待数据返回,其存在成员LoadRawDataFinishDelegate,能在加载完成后支持回调。其实这种协程的方式有待考量,现在我在项目里用的帧刷新,轮询的方式也能满足需求,我这种集中式管理,主要问题在于回调产生的IO与实例化的管理不善,但集中式轮询应该没有大问题。