首页/资讯中心/详情

深入UGUI源码：从核心架构到性能优化与自定义组件开发

深入UGUI源码：从核心架构到性能优化与自定义组件开发
📅 发布时间：2026/7/28 8:29:14

1. 项目概述：从“会用”到“懂它”，UGUI源码的价值

做Unity开发，尤其是客户端开发，UGUI是绕不开的一环。从新手教程里的第一个按钮，到复杂活动界面的嵌套滚动、自适应布局，我们每天都在和它打交道。但很多时候，我们对UGUI的认知停留在“拖拽Canvas、挂上Button脚本、绑定事件”的层面。当界面卡顿、渲染异常、或者需要实现一个标准组件没有的“骚操作”时，往往就束手无策，只能上网搜一些“魔改”方案，知其然不知其所以然。

最近在重温《Unity3D高级编程 主程手记》第四章关于用户界面的内容，特别是UGUI核心源码的部分，感触颇深。这章内容的价值，不在于教你如何拼凑出一个界面，而在于带你深入UGUI的“发动机舱”，看明白每一个控件是如何被驱动、如何被绘制、事件是如何流转的。这对于解决实际开发中的性能瓶颈、实现定制化UI组件、乃至优化整个UI框架的设计，都有着决定性的作用。比如，为什么频繁SetActive一个包含大量子物体的UI节点会导致卡顿？Canvas的“批处理”到底在什么情况下会生效又什么情况下会失效？Image组件的填充方式（Filled）在底层是如何计算顶点和UV的？这些问题，只有看过源码，心里才有底。

2. UGUI核心架构与设计思想拆解

UGUI的源码并不算特别庞大，但其架构设计体现了Unity团队在易用性与性能之间所做的精妙权衡。理解其顶层设计，是后续深入具体组件的前提。

2.1 核心基类：一切UI组件的起点

UGUI的类继承树有一个非常清晰的根：UIBehaviour。这个继承自MonoBehaviour的类是所有UGUI可视化组件的基类。它本身没有添加太多功能，主要意义在于“标记”——标记这是一个UI相关的行为脚本。更重要的是它的子类：Graphic和Selectable。

Graphic是所有需要被绘制到屏幕上的UI元素的基类，比如Image,Text,RawImage。它的核心职责是管理材质（Material）、网格（Mesh）以及如何将这些网格提交给Canvas进行渲染。Graphic类中你会看到OnPopulateMesh这个关键虚方法，所有派生类都需要重写它来定义自己独特的几何形状（比如Image是矩形，Text是字符网格）。

Selectable则是所有可交互UI控件（如Button,Toggle,Slider）的抽象基类。它封装了状态机（Normal, Highlighted, Pressed, Disabled）、过渡（颜色过渡、精灵过渡、动画过渡）以及导航（通过键盘或手柄在UI控件间切换）这一整套交互逻辑。当你为一个Button设置不同状态下的颜色时，背后就是Selectable在驱动状态切换和颜色插值。

这种继承结构的好处是职责分离非常清晰。一个Button，它同时是Selectable（负责交互）和Graphic（负责显示背景图）。而Text作为Button的子物体，只继承Graphic，负责显示文字。这种组合大于继承的思想，让UGUI的组件既灵活又可复用。

2.2 渲染核心：Canvas与CanvasRenderer

这是UGUI性能表现的关键所在。Canvas组件并不直接负责绘制，它是一个“管理器”和“批处理器”。它的核心作用是收集其下所有Graphic组件生成的网格数据，并尝试将它们合并成更少的Draw Call（绘制调用）。

每个Graphic组件都会持有一个CanvasRenderer。你可以把CanvasRenderer理解为一个“网格数据容器”。当Graphic需要更新（比如文本改变、图片替换）时，它会调用CanvasRenderer的SetMesh方法，将OnPopulateMesh生成的网格数据塞进去。Canvas则在特定的渲染时机（如Canvas.willRenderCanvases事件触发时），遍历所有子节点，从各自的CanvasRenderer中取出网格、材质信息，进行合批判断。

合批（Batching）是UGUI提升渲染效率的核心手段。它遵循一个基本原则：使用相同材质球（Material）和纹理（Texture）的Graphic，且满足深度排序等条件，它们的网格就可以被合并到一个Draw Call中绘制。源码中会检查CanvasRenderer的材质ID和纹理ID。这就是为什么UI图集（Atlas）如此重要——它将大量小图合并到一张大纹理上，使得多个Image组件可以共享同一个材质和纹理，从而满足合批条件，大幅降低Draw Call。

注意：很多性能问题源于合批失败。动态字体（Dynamic Font）生成的文字纹理是动态的，每个Text组件可能使用不同的字符子集，导致纹理不一致，难以合批。频繁改变UI元素的位置、旋转、缩放，或者改变其材质属性（如Color），也可能导致合批断裂，因为Canvas需要重新计算和排序。理解这一点，在制作UI时就要有意识地进行静态和动态分离，将频繁变化的元素放在独立的Canvas中。

2.3 事件系统：从点击到响应的旅程

UGUI的事件系统是一个独立但与渲染紧密协作的模块，核心是EventSystem类。它管理着一个BaseInputModule列表（如StandaloneInputModule处理PC点击，TouchInputModule处理触摸）。每一帧，EventSystem会调用当前模块的Process方法。

事件处理的流程是一个“射线投射-命中检测-消息传递”的过程：

  1. 射线投射：输入模块根据点击/触摸屏幕的位置，生成一条从摄像机出发穿过该点的射线。
  2. 图形射线检测：通过GraphicRaycaster组件（通常挂在Canvas上）。GraphicRaycaster会沿着射线方向，对其所属Canvas下的所有Graphic进行检测。检测的依据是Graphic的Raycast方法，默认实现是检查点击位置是否在该Graphic的矩形范围内（对于Image）或字符网格范围内（对于Text）。
  3. 命中排序：所有被命中的Graphic会按照深度（Sorting Order）、渲染顺序等排序，形成一个列表。
  4. 事件传递：系统从列表最顶层的Graphic（即最后被渲染的，视觉上在最前面的）开始，尝试执行事件。它首先检查该Graphic是否实现了IPointerClickHandler等事件接口。如果没有，则会沿着Transform层级向上查找，直到找到实现了对应接口的组件（比如挂在父节点上的Button组件）。

这个过程解释了几个常见现象：

  • 为什么空白的Image也能接收点击？因为Graphic.Raycast默认只检查矩形范围，不检查像素透明度。可以通过设置Image的Raycast Target为false来禁用，或者使用Alpha Hit Test Minimum Threshold进行透明度阈值检测（源码中会采样像素Alpha值）。
  • 事件是如何从子物体冒泡到父物体的？这就是上述第4步的向上查找过程，是UGUI内置的机制，而非真正的“事件冒泡”事件。
  • 如何阻止事件穿透？在顶层UI的Graphic上处理事件，并调用EventSystem.current.SetSelectedGameObject(null)或直接处理掉事件，可以阻止事件继续向后面的UI或3D物体传递。

3. 核心组件源码精读与实战启示

了解了宏观架构，我们再深入到几个最常用组件的源码细节，看看它们是如何工作的，以及能给我们带来哪些实战优化思路。

3.1 Image组件：网格生成与填充模式

Image是使用频率最高的组件。它的核心在OnPopulateMesh方法中。这个方法接收一个VertexHelper对象，用于填充网格的顶点、UV、颜色和三角形索引。

对于最简单的Simple模式，Image会生成一个由4个顶点、2个三角形组成的矩形网格。UV坐标对应图片的矩形区域。而Sliced（九宫格）和Tiled（平铺）模式则复杂得多。

  • Sliced模式：源码中会根据sprite.border（九宫格边界值）将矩形分割成9个小格子。中间的第5格进行拉伸，四个边角（1，3，7，9）保持原比例，四条边（2，4，6，8）进行单向拉伸。关键点在于：当Image的矩形尺寸小于原始Sprite尺寸时，九宫格的中间部分可能会被压缩甚至消失。源码中的计算逻辑确保了边角永远不被拉伸，这是保持UI视觉不变形的关键。
  • Tiled模式：平铺的逻辑是，先完整地平铺中间区域，然后再处理四条边。这里有一个性能陷阱：如果Image的矩形非常大，平铺模式会生成极其大量的顶点（每个瓦片4个顶点），可能导致网格超出Unity的顶点数限制（65535）或者造成严重的CPU开销。对于大区域的平铺背景，更好的做法是使用一张无缝衔接的大图，或者使用材质球的纹理平铺（Material.SetTextureScale）在Shader层面实现，而非网格层面。

填充模式（Filled）的源码实现尤其有启发性：无论是水平、垂直、径向还是90度填充，其本质都是通过修改顶点位置和UV，将完整的矩形网格“裁剪”出一部分来显示。例如Horizontal填充，源码中会根据fillAmount（0到1）计算一个比例，然后调整右侧两个顶点的X坐标和UV的U坐标，使它们向中心靠拢，从而实现从左到右的填充效果。这意味着，填充操作是每帧进行的（如果fillAmount在变化），会触发网格重建（SetVerticesDirty）。如果界面上有大量动态变化的填充条（比如血条、进度条），这会是性能热点。一个优化方案是，将频繁变化的填充条单独放在一个Canvas中，或者考虑使用Shader通过顶点颜色或UV动画来实现填充，避免CPU侧的网格重建。

3.2 Text组件：字体、排版与富文本

UGUI的Text（旧版，非TextMeshPro）组件性能问题较多，其源码也相对复杂。核心流程是：当文本字符串、字体、大小等属性改变时，调用GenerateText方法。

  1. 文本生成：该方法会遍历字符串中的每个字符，从当前字体中获取字符信息（glyph），包括其UV（在字体纹理中的位置）、宽度、高度等。然后为每个字符计算其在行中的位置，处理换行、对齐等。
  2. 网格构建：为每个字符生成一个四边形（两个三角形），设置其顶点位置和UV。注意，同一个字体、字号、风格的字符，只要在字符串中重复出现，它们就共享字体纹理中的同一块区域。因此，Draw Call的合批主要取决于字体纹理是否一致。
  3. 富文本解析：支持``这样的标签。源码中会解析这些标签，并动态地改变后续字符的颜色、大小等属性。这里有一个重要的细节：颜色和大小等属性的改变，并不是通过创建新的材质球或网格实现的，而是通过修改顶点颜色（color）和顶点位置（scale）实现的。这意味着，一个使用了多种颜色和大小的Text组件，仍然是一个Draw Call（前提是字体纹理相同），这是非常高效的。

Text组件的性能瓶颈主要在于：

  • 字体纹理重建：对于动态字体，当遇到字体纹理中没有的字符时，需要动态将其光栅化并添加到字体纹理中。这个过程（Font.RequestCharactersInTexture）是阻塞的，可能引起卡顿。解决方案是做好字体预载（在加载界面时提前请求所有可能用到的字符），或者使用静态字体文件。
  • 网格重建：任何导致文本布局变化的操作（文本内容、宽度、对齐方式改变）都会触发完整的GenerateText流程。对于频繁更新的文本（如倒计时、飘血数字），应考虑使用对象池来复用Text组件，或者使用TextMeshPro，后者在文本布局和渲染效率上都有巨大提升。

3.3 RectTransform：UI布局的基石

RectTransform继承自Transform，但增加了锚点（Anchors）、轴心点（Pivot）和尺寸（Size Delta）的概念。它是UI布局灵活性的来源。

其源码的核心在于如何将我们设置的锚点、位置偏移量，最终计算成世界坐标系中的位置、旋转和缩放。RectTransform的Update方法或其父节点变化时，会触发重新计算。

锚点（Anchors）的实质是“相对定位”。四个锚点值（Min和Max）定义了一个在父RectTransform矩形内的相对位置。当我们将锚点预设为“拉伸（Stretch）”时，Min和Max的X或Y值分别为0和1。此时，RectTransform的width和height直接由sizeDelta决定，而anchoredPosition则代表了中心点的偏移。理解这一点至关重要：在代码中动态设置一个拉伸模式的UI元素的位置和大小，你应该操作sizeDelta和anchoredPosition，而不是localPosition。

强制布局重建：当你动态改变了RectTransform的尺寸，或者改变了LayoutGroup（如HorizontalLayoutGroup）的子物体，可能需要手动调用LayoutRebuilder.ForceRebuildLayoutImmediate来立即更新布局。在源码中，布局系统是延迟执行的，标记为dirty后在当前帧的渲染前更新。但在某些需要立即获取正确布局后的尺寸进行后续计算的场景，强制立即重建是必要的。

4. 性能优化深度剖析与实战策略

阅读源码的最终目的是为了优化。基于对UGUI核心机制的理解，我们可以制定出更具针对性的性能优化策略。

4.1 Canvas合批策略与拆分艺术

Canvas的合批并非总是自动且最优的。我们需要主动管理。

  • 静态与动态分离：这是最重要的原则。将界面中位置、形态固定不变的元素（如背景、边框、静态文字）放在一个或多个Canvas中，并将这些Canvas的Canvas组件上的Additional Shader Channels根据需要设置好（通常需要TexCoord1, Normal等用于合批），然后禁用Canvas组件的Pixel Perfect和Override Sorting，并尽可能使用CanvasScaler的Constant Pixel Size模式，以减少运行时计算。对于动态元素（如滚动列表项、动画特效、进度条），放在另一个独立的Canvas里。这样，动态元素的变化不会导致整个静态界面的网格重建和合批计算。
  • Overlay vs Camera vs World Space：Overlay模式的Canvas直接绘制在屏幕最上层，不受3D摄像机影响，适合全屏UI。Camera模式将Canvas投影到指定摄像机的某个平面上，适合世界空间中的UI（如血条）。World Space则是完全的3D物体。从性能角度，Overlay通常效率最高，因为它省去了3D空间变换和深度测试的一些开销。但具体选择需根据项目需求。
  • 避免嵌套Canvas：每个Canvas都是一个独立的合批单元。嵌套Canvas会导致子Canvas内的元素无法与父Canvas或其他Canvas的元素合批，即使它们材质纹理完全相同。除非有明确的渲染顺序或动态/静态分离需求，否则应避免不必要的Canvas嵌套。

4.2 重建（Rebuild）的触发与规避

UI重建是性能杀手，主要分为几何重建（Geometry Rebuild）和布局重建（Layout Rebuild）。

  • 几何重建：由Graphic.SetVerticesDirty()触发。当Image的sprite、color、material改变，或Text的文本、字体、对齐方式改变时会发生。重建过程会调用OnPopulateMesh重新生成网格。优化点：对于频繁变化的UI，如计时器，避免每帧直接修改Text.text。可以每若干帧修改一次，或者使用StringBuilder来构建字符串，减少不必要的字符串分配和重建触发。
  • 布局重建：由LayoutRebuilder.MarkLayoutForRebuild()触发。当RectTransform的尺寸改变，或LayoutGroup（如GridLayoutGroup）的子物体数量、顺序变化时会发生。重建过程会重新计算所有子物体的位置和大小。优化点：对于复杂的滚动列表，使用成熟的对象池方案（如Unity自带的UI Virtualization或第三方插件），只对可视范围内的项进行布局计算。避免在每一帧都动态添加/删除列表项。

一个实战技巧是使用Canvas.willRenderCanvases事件来监控重建。你可以添加一个监听，在编辑器中打印日志，看看是哪些UI元素在频繁触发重建，从而定位性能热点。

// 示例：在开发阶段监控Canvas重建 using UnityEngine; using UnityEngine.UI; public class CanvasRebuildMonitor : MonoBehaviour { void OnEnable() { Canvas.willRenderCanvases += OnWillRenderCanvases; } void OnDisable() { Canvas.willRenderCanvases -= OnWillRenderCanvases; } void OnWillRenderCanvases() { // 这里可以添加调试代码，例如记录时间、检查特定Canvas的dirty状态等 // Debug.Log("Canvas will render at: " + Time.frameCount); } }

4.3 图集（Atlas）管理与内存优化

UGUI合批的前提是材质纹理相同。使用图集将多个小图打包进一张大图，是降低Draw Call的标准做法。但图集管理也有学问。

  • 图集大小与格式：根据目标平台选择合理的图集大小（如1024x1024, 2048x2048）。过大图集可能超出某些低端设备的显存限制，且加载慢。使用合适的纹理压缩格式（如Android用ETC2，iOS用PVRTC）。
  • 动态图集：Unity的Sprite Atlas系统支持动态图集（在Player Settings中开启）。它会在运行时将未打包的Sprite动态合批到一张大纹理上。注意：动态图集有大小和数量限制，且动态合批本身有CPU开销。对于性能敏感的项目，建议还是使用静态图集进行预打包。
  • 清理无用Sprite：当从图集中动态加载了一个Sprite使用后，如果不再需要，确保将其引用置为null，以便Resources.UnloadUnusedAssets能够正确释放其占用的纹理内存。否则，即使UI元素销毁了，整个图集纹理可能仍驻留在内存中。

5. 高级应用与自定义组件开发

理解了源码，我们就不再局限于使用标准组件，可以开发更强大、更高效的定制化UI组件。

5.1 实现一个高性能的圆形进度条

标准Image的径向填充（Radial Fill）顶点数固定，且在极端比例下可能变形。我们可以通过自定义Graphic来实现一个更平滑、顶点数可控的圆形进度条。

核心思路是重写OnPopulateMesh方法，根据进度值fillAmount，计算一个圆弧，并生成一个扇形网格。顶点数可以根据精度需求动态调整，在进度变化时只修改顶点位置和UV，而不是重建整个网格（除非顶点数需要变化）。

using UnityEngine; using UnityEngine.UI; [RequireComponent(typeof(CanvasRenderer))] public class CircleProgressBar : Graphic { [Range(0, 1)] public float fillAmount = 1.0f; [Range(3, 100)] public int segments = 40; // 控制圆滑度 protected override void OnPopulateMesh(VertexHelper vh) { vh.Clear(); if (fillAmount <= 0) return; Vector2 center = rectTransform.rect.center; float radius = Mathf.Min(rectTransform.rect.width, rectTransform.rect.height) * 0.5f; // 添加中心顶点 UIVertex centerVertex = UIVertex.simpleVert; centerVertex.position = center; centerVertex.color = color; vh.AddVert(centerVertex); // 计算需要的圆弧段数 int activeSegments = Mathf.CeilToInt(segments * fillAmount); float angleStep = (Mathf.PI * 2 * fillAmount) / activeSegments; float currentAngle = -Mathf.PI / 2; // 从顶部开始 // 添加圆弧上的顶点 for (int i = 0; i <= activeSegments; i++) { float cos = Mathf.Cos(currentAngle); float sin = Mathf.Sin(currentAngle); Vector2 pos = center + new Vector2(cos * radius, sin * radius); UIVertex vertex = UIVertex.simpleVert; vertex.position = pos; vertex.color = color; vh.AddVert(vertex); currentAngle += angleStep; } // 添加三角形 for (int i = 1; i <= activeSegments; i++) { vh.AddTriangle(0, i, i + 1); } } // 提供一个方法供外部更新进度 public void SetFillAmount(float amount) { fillAmount = Mathf.Clamp01(amount); SetVerticesDirty(); // 标记顶点数据为脏，触发重绘 } }

这个自定义组件比Image的Filled模式更灵活，我们可以轻松控制顶点数来平衡效果和性能，也可以扩展出更多效果，比如圆环、锯齿状边缘等。

5.2 扩展事件系统：实现长按、双击与拖拽

UGUI的标准事件接口提供了基础的点击、按下、抬起等事件。但像长按、双击等复杂交互，需要我们自己基于基础事件进行扩展。

以长按为例，我们可以在IPointerDownHandler中开始计时，在IPointerUpHandler或IPointerExitHandler中取消计时。

using UnityEngine; using UnityEngine.Events; using UnityEngine.EventSystems; public class LongPressEventTrigger : MonoBehaviour, IPointerDownHandler, IPointerUpHandler, IPointerExitHandler { public UnityEvent onLongPress = new UnityEvent(); public float durationThreshold = 1.0f; private bool isPointerDown = false; private float timePressStarted; void Update() { if (isPointerDown && Time.time - timePressStarted > durationThreshold) { // 触发长按事件 onLongPress.Invoke(); Reset(); } } public void OnPointerDown(PointerEventData eventData) { isPointerDown = true; timePressStarted = Time.time; } public void OnPointerUp(PointerEventData eventData) { Reset(); } public void OnPointerExit(PointerEventData eventData) { Reset(); } private void Reset() { isPointerDown = false; } }

对于更复杂的拖拽，需要实现IBeginDragHandler,IDragHandler,IEndDragHandler接口，并配合EventSystem.current.currentSelectedGameObject来管理拖拽状态。理解事件系统的传递流程，能让我们在正确的时机拦截或转发事件，实现复杂的UI交互逻辑。

5.3 与Shader结合：实现高级UI视觉效果

有时，单纯靠网格和Sprite无法实现某些视觉效果（如扭曲、溶解、流光）。这时就需要与Shader结合。UGUI的Graphic组件有一个material属性，我们可以为其指定一个自定义的Shader。

例如，实现一个简单的溶解效果：

  1. 创建一个新的Shader，接收一个_DissolveThreshold参数和一张噪波图。
  2. 在片段着色器中，采样噪波图，与阈值比较，决定是否丢弃（clip）该像素。
  3. 在C#脚本中，动态修改material的_DissolveThreshold属性。

关键点：直接修改Graphic.material会导致该Graphic使用一个独立的材质实例，破坏合批。正确的做法是使用Graphic.materialForRendering（这是一个属性，返回实际用于渲染的材质实例），或者更推荐的方式是使用MaterialPropertyBlock。但UGUI对MaterialPropertyBlock的支持有限，通常更实用的做法是，对于需要特殊效果的少量UI元素，接受其无法合批的现实，或者将这些元素合并到一个单独的Canvas中，使用同一个材质实例。

// 示例：使用MaterialPropertyBlock修改UI Shader属性（注意：此方法对UGUI的合批影响需测试） public class DissolveUI : Graphic { public Texture2D noiseTexture; public float threshold = 0.5f; private MaterialPropertyBlock mpb; protected override void OnPopulateMesh(VertexHelper vh) { /* ... */ } void Update() { if (mpb == null) mpb = new MaterialPropertyBlock(); // 获取当前渲染用的材质 var renderMaterial = materialForRendering; if (renderMaterial != null) { // 通过CanvasRenderer设置属性块 GetComponent<CanvasRenderer>().GetPropertyBlock(mpb); mpb.SetTexture("_NoiseTex", noiseTexture); mpb.SetFloat("_Threshold", threshold); GetComponent<CanvasRenderer>().SetPropertyBlock(mpb); } } }

6. 调试技巧与常见问题排查

开发中遇到UI问题，掌握基于源码知识的调试方法能事半功倍。

6.1 性能问题定位

  • Frame Debugger：Unity内置的神器。在Window -> Analysis -> Frame Debugger中打开。它可以冻结一帧的渲染过程，让你清晰地看到每一个Draw Call是什么，由哪个Canvas、哪个材质、哪个纹理触发。合批成功与否一目了然。如果发现本该合批的UI元素被拆成了多个Draw Call，可以检查它们的材质实例是否相同、纹理是否相同、渲染顺序（Sorting Order）是否连续。
  • Profiler：关注Canvas.SendWillRenderCanvases和Canvas.BuildBatch这两个函数的CPU耗时。前者代表UI重建的开销，后者代表合批计算的开销。如果它们耗时很高，就需要用上述方法优化重建和合批。
  • Overdraw：在Scene视图的渲染模式中选择Overdraw，可以查看UI的重绘区域。不透明的UI会完全遮挡后面的UI，但半透明的UI会导致多层绘制。尽量减少全屏半透明UI的重叠，特别是在低端设备上。

6.2 显示与交互异常排查

  • UI不见了？首先检查Canvas的Render Mode和对应摄像机的设置。检查Graphic的color的Alpha值是否大于0，material是否有效。检查RectTransform的锚点设置是否导致其被拉伸到屏幕外。
  • 点击没反应？检查Graphic的Raycast Target是否勾选。检查该UI或其父节点上是否有CanvasGroup且Blocks Raycasts为false。检查是否有更上层的UI（更高Sorting Order或更晚渲染）拦截了射线。使用EventSystem.current.IsPointerOverGameObject()可以判断当前点击是否在UI上。
  • 布局错乱？动态添加删除子物体后，记得可能需要调用LayoutRebuilder.ForceRebuildLayoutImmediate。检查ContentSizeFitter和LayoutGroup的组合使用，有时会产生循环依赖，导致布局计算不稳定。可以尝试在下一帧（Coroutine中yield return null）再获取或设置布局相关尺寸。

6.3 内存泄漏排查

UI是内存泄漏的重灾区，因为MonoBehaviour之间的引用关系复杂。

  • 事件监听泄漏：最常见的泄漏是事件注册后未注销。如果一个UI对象订阅了某个全局事件或另一个长生命周期对象的事件，当UI对象被销毁时，如果未取消订阅，那么事件持有者就会一直持有对该UI对象的引用，导致其无法被GC回收。务必在OnDestroy中取消所有事件订阅。
  • 静态引用泄漏：静态变量或单例持有对UI对象的引用。
  • 协程泄漏：在UI对象上启动的协程，如果内部有while(true)或长时间等待，并且没有在OnDestroy中通过StopAllCoroutines()停止，协程会保持该对象的引用。
  • 使用内存分析工具（如Unity Profiler的Memory Snapshot）定期检查，查找未被释放的UI对象实例。

回过头看，《主程手记》里对UGUI源码的剖析，其价值远不止于解决眼前的一两个BUG。它更像是一张地图，让你在UI开发的复杂地形中，清楚地知道每一条性能消耗的河流、每一个交互触发的山脉是如何构成的。当你再面对一个棘手的UI需求或性能问题时，你不会再感到迷茫和被动搜索，而是能基于对底层机制的理解，主动地分析、设计和实施最优雅高效的解决方案。这种从“被动使用”到“主动驾驭”的转变，正是资深开发者与普通使用者的分水岭。