要保证通用性必须分清需求是框架需要还是项目需要。举一个例子,所有的项目都需要一个弹窗提示的接口,但是不同项目弹窗都不一样,当时做的时候我没有想好怎么分离,那就放到项目类库里,保证框架不受影响,以后再重构。

下面根据题主提的要点针对性说下方案(以NGUI框架为基础,UGUI还在研究中):

  • UI和场景中物体的交互如何控制

目前遇到的场景中交互有几种:

类似血条的显示:通过摄像机转换坐标的方法转换为UI坐标来同步血条位置。

对点击等操作的响应:属于控制管理器,不应该放在UI框架中,但是UI框架需要提供UI尺寸和实际尺寸的比例便于规划控制范围。

3D物体的展示:可以直接放在界面中也可以使用renderTexture,前者更方便。

切换场景时对 UI 如何处理

虽然unity提供了Scene这个功能给我们使用,但是我个人的最终目标是将整个游戏运行在一个场景中,但这并不影响UI框架。一个场景一个单例的管理器(M2),还有一个跨场景的管理器(M1),M2负责具体的创建和关闭,M1负责对象池之类的功能。如果多场景,场景切换时M2实例和界面就都销毁了,不需要特别处理;如果单场景,创建和销毁都已经由M2实例负责了。

  • UI如何分组/分类以方便管理

个人看来这一条本身提的比较模糊,因为可以理解为资源的管理也可以理解为结构的管理,下面分别回答。

资源管理:小的项目可以使用公用图集(+Texture)的方式,大的项目UI资源太多,只靠公用图集肯定会造成内存的严重占用,所以建议是公用图集+功能图集(+Texture)。功能图集就是一个功能模块的公用图集,在功能操作完毕时就可以释放掉了。这里涉及到的细节太多,就不展开了。

结构管理:我的思路是分为三类:1控件,就是button、label、sprite等等。(像buttonGroup就是button的组合,使用代码创建和控制)2弹窗/界面/列表项,这三者都由控件组成。3共用布局,这一类是为了节省时间而分的,比方说卡牌游戏中反复出现的卡牌布局其实就是共用布局,每个界面重复制作显然浪费,是否有这类关键在于UE结构是否明确和复杂布局的复用程度。

  • 如何统一管理UI的深度

这条可以引申为Z坐标(如果UI中有3D物体或者UI本身就是3D的)、renderQueue、界面的调用顺序等全局属性的管理。这些内容都应该在界面制作的时候就记录在界面信息上,在创建、聚/失焦、关闭界面时记录在管理器中。

UI本身的深度其实很好管理,麻烦在UI上可能会有3D物体和特效,不同的shader可能会导致不同的问题。

  • 打开、关闭时的动效,以及被遮挡时的动效

动效本身其实更应该当作项目需求而不是框架需求。首先建议有单独的动效管理器,其次如果项目规划中对动效规划不明确,可以放在具体实现中。

如果项目中没有靠谱的UE设计,框架做得越多其实越累。引用程序界的质能公式:error=(more code)^{2}

3DUI相比2D多了很多问题,要提前想清楚,比方说在界面上有3D物体的情况下(不用renderTexture)打开弹窗时,Z坐标和缩放的管理。