原则：制作方便，使用简单

• 管理层面
  • 逻辑管理、界面加载，显示，隐藏，关闭，根据标示获得相应界面实例、层级深度、分组、导航、动画、样式
  • 资源管理、图集管理，界面元素合并，资源缓存
  • 规范制定，颜色，字体，大小尺寸，命名等... ...
• 制作层面
  • 资源使用，制作工具
  • 模板使用，样式使用
• 使用层面
  • 数据传递，组件的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一旦完成就要立即实现。避免开发过程中有其他同事使用的时候卡主。