游戏UI制作归纳
原则：制作方便，使用简单
- 管理层面
- 逻辑管理、界面加载，显示，隐藏，关闭，根据标示获得相应界面实例、层级深度、分组、导航、动画、样式
- 资源管理、图集管理，界面元素合并，资源缓存
- 规范制定，颜色，字体，大小尺寸，命名等... ...
- 制作层面
- 资源使用，制作工具
- 模板使用，样式使用
- 使用层面
- 数据传递，组件的MVVM操控
- 性能层面
- 加载，缓存，释放
- 通用组件
- 富文本、Tips
- 提示框、对话框、
- 道具栏、分页栏、Collider 等
具体内容：
一、UI管理
1、定义UI的树结构，定义分组
不同UI环境不同，可能与场景共同销毁，也可能同一组一起隐藏；所以要进行分组管理。
UI的主要分组有：
主界面组，该组为应用的主控台，基本不会销毁，可能在剧情播放期间会隐藏。
功能界面组，该组可能会同功能场景的销毁而一同销毁。
通用界面组，该组为常用的提示框，对话框，等常规功能界面分组。
自定义分组，提供给应用的扩展组，特殊系统使用，比如实时活动界面、公告栏。
2、UI加载显示和释放
应用层通常只需调用open，close类似这样的函数打开关闭UI，但在管理器需要做一些封装；
首先是UI对象的构建，然后是加载对应的UI图集，通常很多应用的UI会做延迟销毁，所以每次打开
先去缓存找一圈是否存在。UI加载完成后要进行初始化处理，屏幕适配，分组设置，显示排序，等。
3、导航
从用户体验层面考虑，用户打开过的窗口可能会保存操作记录，再次打开的时候
会进行历史记录的导航，导航到对应分页。
4、样式
主要用于美术迭代，一款成熟的应用UI通常会更换几版，如果界面以样式表的方式记录界面样式。
这样的支持可以使美术调整界面的时候只改变样式表的信息，再进行检查一轮微调即可。
关于样式表的做法，以unity制作UI为例，在制作界面后通过工具将该perfer包含的所有gameobj进行样式分析，导出样式表xml。
在其他界面制作的时候，挂在样式表脚本并指定对应样式表，里面的元素将会安装规则去寻找样式进行填充。
并同时解决了打包中资源复制的情况，资源可以按样式表管理和加载。
二、UI制作
1、资源管理
UI制作的时候，特别重要的一点是资源管理，管理不合理便很难找到资源并复用，也很难达成资源复用的效果。
资源管理的冲突主要在分类和分组之间，分类是理解，分组是管理（分组不合理资源就会存在多个分组之中）。
即使很多是通用资源，那也可能存在通用资源分批加载和分阶段加载的情况。
资源分类大概为：初始化资源组、共享资源组、功能资源组（功能资源分的比较细）并且在等级段未开启对应功能
的时候也没有加载相关资源的必要（比如10级军团开启，10级之后的军团共享资源才会加载）。
2、制作工具
各种游戏引擎都提供了针对引擎控件的UI编辑器，但对于美术来说PS才是最好的。
所以也有一些公司采用PS直接生成界面文件来用的。
优点在于，优化了产出流程，“可能”提高了产出效率。
缺点在于，资源管理复杂，提供给美术的PS插件学习成本已经和对应引擎UI制作学习成本几乎一致
（排除大力气做控件到PS中的公司）做第一版UI用psd生成较快，但是后续调整却变得更慢。
三、UI使用
UI的时候基本上就是逻辑层的业务了，通常的情况是：
打开界面 -> 传入参数 -> 添加事件监听 -> 处理用户输入 -> 移除事件监听 -> 销毁。
虽然使用很容易，但还是要做几层基类封装，基类UI，提示类UI，对话类UI，便于可扩展。
四、性能
UI模块的性能开销依然很高，也是我们统计中的重要性能杀手。在中低端设备上，超过80%的研发项目在UI端都面临较为严重的性能问题，主要体现在以下几个方面：
（1）同一时刻存在大量需要更新的Panel，比如，攻击时刻的血条、不断移动的伤害数字等HUD。这些在“人堆”中范围攻击时或者进攻高地时是很容易大面积出现的；
（2）不断滑动的摇杆和点击的技能icon，这些是MOBA战斗场景中使用最为频繁的UI元素，研发团队需要时刻注意这些icon的变动是否会带来较大范围内的重建。
以上情况都是MOBA项目研发团队每天面对的主要UI问题，可能一个Widget的使用疏忽，就能让研发团队的UI模块性能开销飙升一个量级。
我们的做法是，对富文本进行了纹理回收，比如场景不断产生的数字。
五、通用性
通用性会直接影响项目的开发便捷性和规范性。
有了通用，模板化的UI组件后，程序只需复用组件（业务不同只是换一个实现对象）。
就可以进行数据填充和操作了，同时大家对很多纤细的理解上也保持较高的统一。
所以一开始项目就要定义好哪些写基础组件，要求demo一旦完成就要立即实现。避免开发过程中有其他同事使用的时候卡主。