FairyGUI还是UGUI，从性能上怎么选

作者：admin
/
时间：2小时前
/
浏览：18 次
/
分类：厚积薄发

1）FairyGUI还是UGUI，从性能上怎么选
2）FairyBatching为何还会断批

这是第492篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。

UWA社区主页：community.uwa4d.com
UWA QQ群：793972859

本次推送的实战案例来自于使用UWA服务的项目的真实且典型的问题。UWA将关键线索、定位路径与处理建议整理成了可复用的案例笔记，便于大家快速对照、排查自身项目中的同类问题。

实战案例

Q：新项目正在评估FairyGUI和UGUI，单从性能角度看，能不能直接判断哪一种方案更好？

A：不能简单判断FairyGUI一定比UGUI好。两套方案都可以做到比较好的性能，差别更多在于各自容易踩到什么性能坑。

UGUI比较常见的问题集中在Canvas体系。界面中动态元素较多时，如果Canvas划分和动静分离没有处理好，容易出现网格重建、顶点属性更新等额外开销；SetActive、SetParent以及UI Particle等操作，也可能成为性能热点。

FairyGUI的实现方式不同。UI进入Unity后更接近普通MeshRenderer的渲染方式，不依赖UGUI那套Canvas网格重建流程，因此动静分离、频繁顶点更新这类问题相对少一些。

但FairyGUI也不是“天然性能更高”。它同样有自己的性能限制，例如动态合批条件、Renderer相关属性、文本顶点数量以及UI与特效的混排方式，都可能影响最终性能。

从目前接触到的项目经验来看，UGUI遇到的性能问题类型会更多一些，而FairyGUI相对集中。但这并不代表FairyGUI天然性能更高，两套方案都可以做到比较好的性能。选型时更适合结合团队现状判断：

已经有成熟UGUI框架和优化经验
现有积累本身就有价值，没有必要仅因为换方案可能减少部分性能问题就重新切换。

更关注UI制作效率，且愿意重新建立使用规范
可以重点评估FairyGUI，尤其是动态UI较多、希望减少程序拼UI工作的项目。

如果项目本身比较重UI，最好再准备几个接近真实业务的测试场景，例如大量动态文本、频繁开关界面、角色预览、UI特效混排，放到同一设备、相近画面复杂度下进行对比。

FairyGUI并非在所有场景下都更占优势，它只是规避了UGUI中的一部分常见性能问题；最终怎么选，还是要结合团队已有积累和实际UI场景。

实战案例

Q：FairyGUI已经开启FairyBatching，为什么同材质的UI元素还是会出现合批被打断？

A：FairyBatching主要是调整UI元素的渲染顺序，为后续合批创造条件，并不代表开启后，同材质元素就一定能够合起来。

实际能不能合批，还会受到网格复杂度、UI层级关系以及特效混排等因素影响。例如文本开启Outline、Shadow等效果后，生成的顶点数量会明显增加。当网格复杂度超过动态合批允许的范围，即使材质一致、FairyBatching已经调整好顺序，也可能被拆成多个Draw Call。

UI对象之间的包围框重叠同样会影响排序。FairyBatching在重新组织渲染顺序时，还要保证原本的前后遮挡关系不被破坏，所以不同组件的包围框一旦互相覆盖，同材质元素就不一定能够自由调整到连续的绘制顺序中。这里比较容易忽略的是：画面看起来没有重叠，不代表实际包围框没有重叠。

如果UI中还穿插了粒子或3D特效，情况会更复杂。通过GoWrapper等方式把特效放进UI层级后，一旦形成类似：UI → 特效 → UI这样的交错关系，原本能够连续绘制的UI元素也可能被拆开。

开启FairyBatching后Draw Call仍然偏高，可以重点检查三件事：文本和UI Mesh顶点是否过多、UI对象包围框是否重叠，以及特效或3D对象是否穿插在UI渲染顺序中。

FairyBatching只是尽量为合批创造条件。开启后Draw Call仍高，就需要继续找是哪一个条件打断了合批。