距离上一款游戏上线已经两月有余，上线期的鸡血退去后只留下无鞭的寂寞。所以就来开了个博客，通常一血会比较重要，经过一番深思熟虑，朕决定来总结下上款游戏里我的主要工作。本篇是系列篇之一。
名字其实起大了，说是一款通用框架，也就是我的一些感想。从零开始做一款游戏，第一款游戏，并且作为公司内部最早使用cocostudio做UI的项目，坑我们是踩的比较多的，自然想法也会多一些。
保守点说，项目百分之四十的工作量在UI上面。我进组的时候项目还是个demo，只有一个战斗用的界面，并不成系统。然后发现随着界面的增加，控制它们之间的跳转实在是件麻烦事。一个很简单的事，界面A跳转到界面B，而C也可以跳转到B，B界面上有一个返回按钮，它的行为应该是啥？没有系统的话只能二选一，意味着从C跳到B，再点返回键却到了A界面。首先体验很差，其次逻辑也不对。这里体现了程序员对所谓UI系统的一个需求：记录界面跳转栈。除此之外，想优雅地做UI内存控制也是离不开一个良好的系统的。下面就来详述一下当初我设计的UI系统。
首先，我们来定义一下UI，我的想法是，一个界面用一个类管理，称为一个UI，这些类继承自共同的父类。需要引入并强化ui生存周期概念，主要相关方法如下：
a）oncreate（）ui首次创建时调用的方法，通常可以在此读取ui配置文件和纹理图片；
b）onenter（）从其他界面跳转到此界面调用的方法，通常在此实现ui和后台数据的同步，恢复ui的cpu活动。
c）onleave（）从此界面切到其他界面，通常在此使ui不再显示，并根据需要停止其cpu活动
d）ondestory（）销毁此界面对象。从内存中销毁对象，减小内存占用。
e）update（）界面的实时更新。用于监视关联数据，数据一旦变化需要实时显示。由于此方法被频繁调用，建议最小化之。
其次，根据我的理解，我把UI分成了几个大类。分类的逻辑主要在于他们各自不同的行为，分类的结果最明显地体现在绘制顺序的不一样，在cocos2dx中就是zorder不同。
a) 背景UI。很明显，这类UI最早被绘制。它存在的主要原因是很多主要的界面会共用同一张图作为背景，把这个图抽出来单独管理一方面可以节省资源，二来也可以统一做些花头。这个UI来一个实例就全局够用了。zorder最低。定义为UI_TYPE_BG。
b) 主UI。举个例子，一般游戏都有个大厅，这个大厅就属于主UI。这类UI的特点是同类UI同时只有一个可见。我在大厅选择“出战”，跳到了选关界面，这俩都是主UI，所以这时大厅界面就没必要绘制了。zorder其次。定义为UI_TYPE_MAIN。
c) 常用UI。最常见的例子是玩家属性条，显示玩家的金币、体力之类的。这种界面常驻GPU，大厅上会见到它，选关时候也会看到它，所以它的逻辑不同于上一类。它可以和其他UI同时显示，zorder会比主UI至少高一层。而依据游戏的具体需求，不同的常用UI可能zorder也会不一样，这就具体方案具体实现了。定义为UI_TYPE_CONSTANT。
d) 弹出框类UI。比如付费确认就是个弹出框。一般会是一个流程上的卡点，没法绕过的。所以它出现的时候其他UI应该都不能用了，包括同为弹出框的其他UI。所以它的特点在于，和同类UI绘制不兼容，和其他类UI绘制兼容但操作不兼容。zorder比较高，应高于所有的常用UI。定义为UI_TYPE_POPUP。
e) 其他类UI。目前我遇到的是新手指引的界面。关于新手指引，后面打算另开一篇讲讲，也是个大坑。新手指引比较inba，zorder高于所有的UI，因为所有的UI都可能要指引。这类UI在管理层上逻辑并不复杂，因为通常是单例，基本可以套用主UI的逻辑。定义为UI_TYPE_OTHER。
然后管理器也需要来一个类UIMgr，最好是单例。严格来说，UI类对外部操作者不可见，程序员在UI类外部对UI进行操作都需要经过管理类的消息转发。管理类的内部逻辑控制着UI的跳转流程等等。例如，程序员只需要告诉UIMgr，需要进入某一个UI，传入的参数只有UI的名字和必要的初始化参数，然后整个游戏的界面会变成什么样就交给UIMgr内部黑盒处理。
从游戏UI设计的角度出发，最值得关心的是美术风格和玩家交互，但是从程序员的角度出发，应该考虑的是整个UI的系统性。难免会遇到奇葩需无法在现有系统中实现，这个时候解决办法有两种，一种是扩展系统，丰富系统功能，二是和UI设计者协调，有时候降低百分之十的效果预期会减少百分之八十的程序工作量，这种情况程序员应尽力去争取。而最不该做的就是往系统里加各种判断代码，丝毫不顾系统性，增加维护成本不说，观感也差。