1. 从一次UI卡顿排查说起Graphic到底管了什么几个月前帮一个朋友看他们团队做的一个移动端项目场景不复杂就是一个列表页里塞了几十个带图标和文字的条目滚动起来却明显掉帧。他们一开始怀疑是布局重建太频繁又怀疑是图集没打对折腾了两天没找到根因。我过去看了一眼层级面板发现每个条目下面挂了一堆独立的Image和Text而且这些元素各自带着不同的材质球。问题其实就出在这里——他们完全没意识到UGUI里所有能被渲染出来的东西背后都站着一个共同的基类Graphic。这篇内容我想把Graphic这个类彻底讲透。它不是那种你天天挂在嘴边的东西但只要你做Unity的UI开发你写的每一行和显示相关的代码最终都会落到它身上。Image、Text、RawImage、MaskableGraphic这些你熟悉的组件全都是Graphic的子类。理解Graphic等于理解了UGUI渲染管线的入口。它解决的核心问题是一个UI元素如何把自己变成GPU能画的网格并且在这个过程中如何参与批处理、如何响应重建、如何被裁剪和遮罩。适合谁看如果你已经能熟练拖拽UGUI控件、写过一些简单的UI逻辑但遇到性能问题只会盲目优化图集或者想自己写一个自定义UI组件却不知道从哪继承那这篇就是给你准备的。我会从Graphic的职责边界讲起拆解它的生命周期、网格生成机制、材质与纹理的配合方式再落到实际项目里怎么用它做自定义组件、怎么避开常见的重建陷阱。全程按我自己的排查和实操经验来写不堆砌文档原文。2. Graphic在UGUI体系里的位置它到底承担了哪些职责2.1 渲染层级的入口CanvasRenderer与Graphic的绑定关系很多人以为Graphic就是“画图”的这个理解太窄了。Graphic真正做的事情是充当逻辑层和渲染层之间的桥梁。你在Hierarchy里看到的每一个UI节点如果它需要被画出来那它身上一定挂着一个继承自Graphic的组件。这个组件在OnEnable的时候会去获取同一个GameObject上的CanvasRenderer然后把自己注册到所在的Canvas里。CanvasRenderer是Unity底层真正负责提交绘制指令的东西但它不认识Image也不认识Text。Graphic的职责就是把自己“翻译”成CanvasRenderer能听懂的数据顶点、三角形索引、材质、纹理。你可以把CanvasRenderer想象成一个画框Graphic就是往画框里塞画的人。画框本身不知道画的内容它只负责把画挂到墙上。这里有个容易被忽略的细节一个GameObject上只能有一个CanvasRenderer但可以有多个Graphic吗答案是不行因为Graphic在Awake时会去GetComponent ()如果同一个物体上挂两个Graphic子类它们会抢同一个CanvasRenderer导致渲染错乱。我见过有人想在一个物体上同时挂Image和自定义的Graphic结果只有一个能正常显示就是这个原因。2.2 批处理的基本单位为什么Graphic的材质和纹理决定了DrawCallUGUI的批处理逻辑说穿了很简单相邻的、使用相同材质和相同纹理的Graphic可以被合并到一个DrawCall里。注意这里的“相邻”是指在Canvas的渲染顺序里相邻而不是Hierarchy里的相邻。渲染顺序由层级顺序和SortingOrder共同决定。所以当你看到DrawCall居高不下的时候第一反应应该是去检查是不是有大量Graphic在渲染顺序上被其他不同材质的元素隔开了是不是每个Text都用了不同的字体纹理是不是Image的材质球被意外替换成了不同的实例我那个朋友的项目就是典型每个条目的Image用了默认UI材质Text用了字体材质两者交替出现导致每个条目至少产生两个DrawCall。再加上条目之间没有共用图集几十个条目就是上百个DrawCall。后来把图标打进同一张图集文字统一字体DrawCall直接降到了个位数。这里要强调一个概念Graphic的material和texture不是随便设置的。Image组件会根据sprite是否打包进图集、是否使用自定义材质来决定最终提交给CanvasRenderer的材质和纹理。如果你在代码里直接改Graphic.material会打断批处理因为Unity会认为这是一个不同的材质实例。2.3 重建机制的触发源什么操作会让Graphic重新生成网格Graphic最容易被忽视但又最影响性能的部分就是它的重建机制。所谓重建就是Graphic重新计算顶点位置、UV、颜色然后重新提交给CanvasRenderer。这个过程在Profiler里表现为Canvas.BuildBatch或者Canvas.SendWillRenderCanvases的开销。哪些操作会触发重建我列几个最常见的修改RectTransform的尺寸或位置包括锚点和轴心修改Image的sprite、color、fillAmount修改Text的text、fontSize、color启用或禁用Graphic组件修改Canvas的scale或renderMode注意修改位置和尺寸也会触发重建这一点很多人不知道。因为Graphic需要根据新的RectTransform重新计算顶点坐标。所以如果你在Update里每帧修改一个UI元素的位置哪怕只是移动一个像素都会导致整个Canvas的网格重建。正确的做法是用CanvasRenderer的SetAlpha或者直接操作Transform的localPosition在某些情况下不会触发重建但取决于具体版本和设置。提示在Unity 2019之后的版本里UGUI对重建做了一些优化比如把位置变化和顶点变化分开处理但基本原则没变——频繁修改Graphic的几何相关属性一定会带来重建开销。3. 拆开Graphic的生命周期从OnEnable到OnPopulateMesh3.1 初始化阶段OnEnable里到底发生了什么当一个Graphic组件被启用时OnEnable会依次做几件事。首先它会去获取CanvasRenderer如果获取不到就报错。然后它会把自己注册到Canvas的willRenderCanvases回调里这样每帧渲染前Canvas会通知所有Graphic检查是否需要重建。接着它会调用SetAllDirty()把所有脏标记都置为true包括布局脏、顶点脏、材质脏。这里有个关键点SetAllDirty会触发一次完整的重建包括重新计算布局和重新生成网格。所以如果你在运行时频繁地启用禁用Graphic每次启用都会带来一次重建开销。我见过有人在做UI显隐时用SetActive(true/false)来切换如果这个UI元素很多切换瞬间就会卡一下。更好的做法是用CanvasGroup的alpha来控制显隐或者把Graphic的color的alpha设为0这样不会触发重建。3.2 脏标记体系LayoutDirty、VerticesDirty、MaterialDirty的区别Graphic内部维护了三个脏标记LayoutDirty、VerticesDirty、MaterialDirty。它们分别对应不同的重建范围。LayoutDirty表示布局需要重新计算比如RectTransform的尺寸变了需要重新确定子元素的位置。这个标记会触发LayoutRebuilder的重建影响范围可能包括整个布局层级。VerticesDirty表示顶点需要重新生成比如颜色变了、sprite变了、文字内容变了。这个标记会触发OnPopulateMesh重新生成网格数据。MaterialDirty表示材质或纹理需要重新设置比如sprite被打进不同的图集了、材质球被替换了。这个标记会触发CanvasRenderer的材质更新。理解这三个标记的区别很重要因为不同的修改操作会触发不同的脏标记。比如修改color只会触发VerticesDirty不会触发LayoutDirty修改RectTransform的sizeDelta会同时触发LayoutDirty和VerticesDirty。如果你能准确判断一个操作会触发哪些脏标记就能预估它的性能开销。3.3 OnPopulateMesh网格数据是怎么被填进去的OnPopulateMesh是Graphic最核心的方法它接收一个VertexHelper参数你在这个方法里往VertexHelper里添加顶点、三角形和UV。VertexHelper是一个辅助类它帮你管理顶点列表和索引列表避免你直接操作底层数组。默认的Graphic.OnPopulateMesh会生成一个简单的矩形网格使用RectTransform的rect作为范围。Image和Text都重写了这个方法Image会根据sprite的类型Simple、Sliced、Tiled、Filled生成不同的网格Text会根据文字内容生成每个字符的四边形。如果你要写自定义Graphic重写OnPopulateMesh是必须的。你需要在里面调用vh.Clear()清空旧数据然后调用vh.AddVert()和vh.AddTriangle()添加新数据。注意顶点数量不要超过65535因为UGUI默认使用16位索引缓冲超过这个数量会导致渲染异常。如果确实需要更多顶点可以考虑拆分成多个Graphic。注意在OnPopulateMesh里不要做复杂的计算比如字符串拼接、循环嵌套太深。这个方法会被频繁调用任何性能问题都会被放大。如果计算量大考虑缓存结果只在必要时重新计算。4. 材质与纹理Graphic如何决定最终渲染成什么样4.1 defaultGraphicMaterial与材质实例化的坑Graphic有一个默认材质defaultGraphicMaterial它是一个共享的UI/Default材质。当你没有给Graphic指定自定义材质时它就会用这个默认材质。这个材质是共享的所以所有用默认材质的Graphic可以合批。但如果你在代码里写了graphic.material new Material(...)就会创建一个材质实例这个实例和其他材质不共享导致批处理被打断。我见过有人在运行时给某个Image换材质来实现特效结果整个Canvas的DrawCall暴涨。正确的做法是使用MaterialPropertyBlock来修改材质属性或者提前创建好共享材质在多个Graphic之间复用。4.2 纹理与图集sprite打包对批处理的影响Image的sprite如果被打进了图集那么它的texture就是图集的纹理。多个Image如果使用同一张图集的sprite并且渲染顺序相邻就可以合批。如果sprite没有打包每个sprite就是一张独立的纹理无法合批。所以图集规划是UI性能优化的第一课。我通常会把同一界面用到的图标、背景、边框都打进同一张图集图集大小控制在1024x1024或2048x2048。如果图集太大加载和内存开销也会增加需要权衡。Text的纹理是字体纹理。动态字体在运行时会把用到的字符渲染到一张字体纹理上如果字符集很大字体纹理可能会被撑大甚至重建。所以对于大量文字建议使用静态字体或者TextMeshPro后者对字体纹理的管理更高效。4.3 自定义材质与Shader什么时候需要自己写默认的UI/Default Shader支持基本的纹理采样、颜色混合和裁剪。如果你需要特殊效果比如灰度、描边、模糊、溶解就需要自己写Shader和材质。写自定义UI Shader时要注意几点必须支持UI的裁剪Clip Rect否则在Mask或RectMask2D下面会显示异常必须处理顶点颜色因为Graphic会把color传递到顶点颜色里必须支持模板测试Stencil否则在Mask下面会穿透。我一般会基于UI/Default改保留它的裁剪和模板处理逻辑只修改颜色计算部分。这样能保证兼容性减少踩坑。5. 自定义Graphic实战从零写一个环形进度条5.1 为什么选择继承Graphic而不是MaskableGraphicMaskableGraphic继承自Graphic额外增加了对Mask和RectMask2D的支持。如果你写的组件需要被遮罩裁剪就应该继承MaskableGraphic。如果不需要继承Graphic就够了少一层开销。环形进度条通常用在技能冷却、加载进度等场景一般不需要被遮罩裁剪所以我选择继承Graphic。但如果你把它放在一个ScrollView里可能就需要被RectMask2D裁剪这时候继承MaskableGraphic更合适。5.2 顶点生成逻辑如何用三角形拼出一个圆环环形进度条的本质是一个圆环圆环可以拆分成若干个扇形每个扇形由若干个三角形组成。我的做法是把圆环分成N段每段对应一个角度范围然后计算内外圆上的顶点用三角形连接起来。具体步骤确定圆环的内半径和外半径以及起始角度和结束角度。把角度范围分成N份每份的角度为deltaAngle。对于每个角度计算内外圆上的顶点坐标。用两个三角形组成一个四边形连接相邻的两个角度对应的内外顶点。把顶点和三角形索引添加到VertexHelper里。顶点数量是2*(N1)三角形数量是6*N。N越大圆环越平滑但顶点也越多。一般N取36到72就够了对应每10度或5度一段。protected override void OnPopulateMesh(VertexHelper vh) { vh.Clear(); int segments 60; float deltaAngle 360f / segments; float outerRadius rectTransform.rect.width * 0.5f; float innerRadius outerRadius * 0.8f; for (int i 0; i segments; i) { float angle i * deltaAngle * Mathf.Deg2Rad; float cos Mathf.Cos(angle); float sin Mathf.Sin(angle); Vector2 outer new Vector2(cos * outerRadius, sin * outerRadius); Vector2 inner new Vector2(cos * innerRadius, sin * innerRadius); vh.AddVert(outer, color, new Vector2(1f, 1f)); vh.AddVert(inner, color, new Vector2(0f, 0f)); } for (int i 0; i segments; i) { int idx i * 2; vh.AddTriangle(idx, idx 1, idx 2); vh.AddTriangle(idx 1, idx 3, idx 2); } }这段代码生成的是一个完整的圆环。如果要实现进度效果可以根据fillAmount控制哪些段被绘制。比如只绘制前fillAmount*segments段后面的段不添加三角形。5.3 颜色与UV的传递让进度条支持渐变和纹理顶点颜色可以直接用Graphic的color也可以根据角度计算渐变。比如从起始角度到结束角度颜色从红色渐变到绿色。UV可以根据角度映射到一张纹理上实现纹理环绕效果。注意UV的坐标系UGUI的UV原点在左下角范围是0到1。如果你用纹理要确保纹理的wrap mode是Clamp或Repeat根据需求选择。5.4 性能考量顶点数量与重建频率的平衡环形进度条的顶点数量取决于segments。60段就是122个顶点120个三角形。这个数量很小性能开销可以忽略。但如果你的进度条每帧都在变化就会每帧触发重建。这时候可以考虑用Shader来实现进度效果只传递一个fillAmount参数不重建网格。用Shader实现的方式是在Shader里根据UV计算角度判断当前像素是否在进度范围内如果在就显示不在就透明。这样只需要修改材质的属性不需要重建网格。缺点是Shader的复杂度会增加而且需要处理抗锯齿。6. 那些年我在Graphic上踩过的坑6.1 修改color导致的意外重建有一次我在做一个按钮的点击反馈按下时把按钮的Image颜色调暗松开时恢复。逻辑很简单就是在Update里根据状态设置color。结果发现每次点击都会卡一下。排查后发现修改color会触发VerticesDirty导致整个Canvas的网格重建。如果Canvas里元素很多重建开销就很大。后来我改用CanvasRenderer.SetColor这个方法直接修改CanvasRenderer的颜色不会触发Graphic的重建。但要注意SetColor修改的是顶点颜色之外的乘算颜色效果和修改Graphic.color不完全一样。如果需要精确控制还是得用Graphic.color但要尽量减少修改频率。6.2 动态字体与Text重建的连锁反应Text组件在文字内容变化时会触发重建这个大家都知道。但很多人不知道的是动态字体在遇到新字符时会触发字体纹理的重建这个重建会影响所有使用该字体的Text。如果界面里有大量Text而且文字内容是动态变化的就可能出现连锁重建导致卡顿。我的做法是对于频繁变化的文字比如倒计时、分数使用预先烘焙好的字符集或者用TextMeshPro。TextMeshPro对字体纹理的管理更精细不会因为一个新字符就重建整张纹理。6.3 Mask与RectMask2D对Graphic的额外开销Mask组件会给子Graphic增加模板测试每个被Mask影响的Graphic都会多一次Stencil操作。RectMask2D则是在Shader里做裁剪开销相对小一些。但如果RectMask2D的范围很大覆盖了很多Graphic每个Graphic都要做裁剪计算累积起来也不可忽视。我一般会优先用RectMask2D只有在需要非矩形遮罩时才用Mask。另外Mask会打断批处理因为Mask本身也是一个Graphic它会插入一个不同的材质和模板状态。如果性能敏感尽量减少Mask的使用。6.4 嵌套Canvas与Graphic的更新隔离Canvas的更新是以Canvas为单位的一个Canvas里的任何Graphic重建都会导致整个Canvas的网格重新合并。所以如果界面很复杂可以考虑把频繁变化的部分拆到独立的子Canvas里。子Canvas的重建不会影响父Canvas这样可以隔离更新开销。但子Canvas也有代价每个Canvas都会产生额外的DrawCall因为不同Canvas之间不能合批。所以拆Canvas要适度不能为了隔离更新而拆得太碎。我的经验是把频繁变化的元素比如进度条、倒计时放在一个子Canvas里把静态的背景和装饰放在主Canvas里。7. 从Graphic出发的进阶思路7.1 用Graphic实现自定义图元不只是矩形和圆Graphic的OnPopulateMesh可以生成任意形状的网格不只是矩形和圆。你可以用它来画多边形、贝塞尔曲线、甚至简单的3D模型投影。我见过有人用Graphic实现了雷达图、折线图、热力图效果很好而且完全在UGUI体系内不需要额外的渲染管线。关键是要理解顶点和三角形的组织方式。任何复杂的形状都可以拆分成三角形只要你能计算出顶点的位置和UV就能用Graphic画出来。7.2 结合JobSystem与Burst加速网格生成如果网格生成的计算量很大比如有几千个顶点需要动态计算可以考虑用JobSystem和Burst来加速。把顶点计算放到Job里利用多核并行然后在主线程把结果填充到VertexHelper里。但要注意VertexHelper不是线程安全的不能在Job里直接操作。你需要先在Job里计算出顶点数组然后在主线程里遍历数组添加到VertexHelper。这样虽然多了一次拷贝但计算部分被加速了整体开销还是降低的。7.3 与TextMeshPro的对比什么时候该换阵营TextMeshPro本质上也是基于Graphic的但它对文字渲染做了大量优化比如Signed Distance Field字体、更高效的网格生成、更好的字体纹理管理。如果你在做大量文字渲染或者需要高质量的文字效果TextMeshPro是更好的选择。但TextMeshPro也有学习成本和兼容性问题。如果你的项目已经大量使用UGUI的Text迁移到TextMeshPro需要一定的工作量。我的建议是新项目直接用TextMeshPro老项目如果文字性能不是瓶颈可以暂时不迁移。7.4 一个容易被忽略的优化点Graphic的raycastTarget最后说一个和渲染无关但和性能相关的点Graphic的raycastTarget。这个属性默认是true意味着这个Graphic会接收射线检测。如果界面上有很多不需要点击的装饰性元素把它们的raycastTarget关掉可以减少射线检测的开销。我见过一个项目界面上有几百个Image全部开着raycastTarget每次点击都要遍历所有Graphic做射线检测开销很大。后来把不需要交互的元素的raycastTarget关掉点击响应明显变快。这个优化很简单但效果立竿见影。每次创建UI元素时养成习惯问自己一句这个元素需要接收点击吗不需要就关掉。提示raycastTarget的开关不会触发重建可以随时修改没有额外开销。我在实际项目里养成了一个习惯每次做完一个界面都会用Profiler看一眼Canvas的重建次数和DrawCall数量。如果重建次数很高就去检查是不是有频繁修改Graphic属性的代码如果DrawCall很高就去检查图集和材质的使用。这两个指标基本能反映UI的性能状况比盲目优化有效得多。
