基于Unity中的NGUI 插件 如何设计通用的 UI 框架

在设计通用的UI框架时，确保其通用性的关键在于明确区分需求是框架所需还是项目特有的。例如，所有项目通常都需要一个弹窗提示接口，但不同项目的弹窗样式各异。若在开发时未想好如何分离这部分功能，可将其放入项目类库，以保证框架不受影响，后续再进行重构。

下面将针对提问要点，基于NGUI框架给出具体方案（UGUI相关内容仍在研究中）。

1. UI和场景中物体的交互控制

目前在场景中遇到的交互类型主要有以下几种：

• 类似血条的显示：可通过摄像机转换坐标的方法，将场景中物体的坐标转换为UI坐标，从而实现血条位置的同步显示。
• 对点击等操作的响应：这类操作属于控制管理器的范畴，不应放置在UI框架中。不过，UI框架需要提供UI尺寸与实际尺寸的比例，以便规划控制范围。
• 3D物体的展示：3D物体既可以直接放置在界面中，也可以使用renderTexture。直接放置在界面中操作更为方便。

2. 切换场景时对UI的处理

尽管Unity提供了Scene功能，但我的最终目标是让整个游戏在一个场景中运行，不过这并不影响UI框架的设计。这里设计了两种管理器：一个是每个场景独有的单例管理器（M2），另一个是跨场景的管理器（M1）。M2负责具体UI的创建和关闭，M1则负责对象池等功能。

• 多场景情况：场景切换时，M2实例和界面会自动销毁，无需特殊处理。
• 单场景情况：UI的创建和销毁由M2实例负责。

3. UI的分组/分类管理

此问题的描述较为模糊，既可以理解为资源管理，也可以理解为结构管理，下面分别进行阐述。

资源管理

• 小项目：可采用公用图集（+Texture）的方式管理UI资源。
• 大项目：由于UI资源过多，仅依靠公用图集会导致严重的内存占用。因此，建议采用公用图集 + 功能图集（+Texture）的组合方式。功能图集是针对一个功能模块的公用图集，在该功能操作完成后即可释放，以节省内存。由于涉及细节较多，此处不再展开。

结构管理

我的思路是将UI分为以下三类：

• 控件：包括button、label、sprite等基础元素。像buttonGroup这种由多个button组合而成的控件，可通过代码进行创建和控制。
• 弹窗/界面/列表项：这三者均由控件组合而成。
• 共用布局：此类布局是为了节省开发时间而划分的。例如，在卡牌游戏中反复出现的卡牌布局就是共用布局。若每个界面都重复制作，会造成资源浪费。是否需要此类布局，关键在于UE结构是否明确以及复杂布局的复用程度。

4. UI深度的统一管理

这一问题可引申为对Z坐标（当UI中有3D物体或UI本身为3D时）、renderQueue、界面调用顺序等全局属性的管理。这些信息应在界面制作时记录在界面信息中，并在界面创建、聚焦/失焦、关闭时同步记录到管理器中。

需要注意的是，UI本身的深度管理相对容易，但UI上可能存在3D物体和特效，不同的shader可能会引发不同的问题。

5. 打开、关闭及被遮挡时的动效处理

动效应更多地视为项目需求，而非框架需求。建议设置单独的动效管理器。若项目规划中对动效的规划不明确，可将动效实现放在具体的代码中。

如果项目缺乏可靠的UE设计，框架开发得越复杂，后续维护的难度就越大。引用程序界的质能公式：error = (more code)²。

此外，3D UI相较于2D UI会带来更多问题，需要提前考虑周全。例如，在界面包含3D物体（不使用renderTexture）的情况下打开弹窗时，要处理好Z坐标和缩放的管理。