Unity UGUI系统到底是怎么工作的？

Unity 开发中，UGUI 几乎是使用频率最高的系统之一。

Button、Image、Text、Scroll View、Slider、Toggle……这些我们每天都在使用的 UI 组件，看起来只是一些简单的 GameObject，但实际上从一个 UI 元素被创建出来，到最终出现在屏幕上，中间经历了布局计算、几何数据生成、Canvas 重建、Batch 合批、Draw Call 提交等一系列过程。

尤其是在大型项目中，很多看似奇怪的 UI 性能问题，例如：

为什么修改一个 Text 会导致 UI 卡顿？

为什么 Layout Group 嵌套过多会影响性能？

为什么 Canvas 拆分之后性能反而提升？

为什么 Draw Call 不高，UI 依然很卡？

为什么 Scroll View 中几百个 Item 会产生明显的性能问题？

这些问题，本质上都和 UGUI 的工作机制有关。

所以这篇文章不讨论“Button 怎么用”这种基础内容，而是从底层运行流程出发，看看 UGUI 到底是怎么工作的。

UGUI整体架构

先建立一个整体认识。

UGUI 并不是一个单独的模块，而是多个系统组合起来的一套 UI 框架。

可以把它简单理解成下面这条链路：