如果你已经被某个页面卡得抓狂，又发现帧率曲线在那个UI界面附近直接“断头”，那多半不是渲染压力上去了，而是某个被低估的家伙在后台悄悄地干活——不是GPU在猛跑，是CPU在反复重建Canvas。我做过的一个模拟项目里，一个排行榜界面滚动掉帧掉到怀疑人生，优化完以后帧率翻了一倍还多，罪魁祸首就是标题里提到的这两个词：Canvas重建和脏标记。
这篇文章是《Unity 卡顿·帧率保卫战》系列的第五篇，专门聊UI卡顿里那些最隐形的成本。我不打算从头讲UGUI怎么画图，而是直接围绕“Canvas为什么会重建”“脏标记在什么情况下会传染”“怎么用工具把源头揪出来”来展开。内容适合已经写过一阵子UGUI、遇到过界面掉帧但不知道该从哪下手的开发者，也适合想搞清楚UI优化底层逻辑的进阶选手。
1. 从一帧UI的完整旅程看Canvas重建的成本
很多人觉得UI卡顿是GPU渲染跟不上，实际上绝大多数UI卡顿都是CPU端的问题。在Unity里，一个UI元素从状态改变到最终上屏，走过的链路比你想象的长得多。Canvas重建只是这条链路上最吃CPU的部分，但要理解它到底贵在哪，得先把整条链路捋清楚。
1.1 一条UI批处理渲染链路到底发生了什么
简单说，UGUI的事件链是这样的：当某个UI组件被标记为需要更新后，Canvas会在渲染帧的合适时机检查脏标记，把所有需要重建的UI元素重新生成几何数据，再把它们合并成批次，提交给GPU绘制。
这里面最关键的点是，UI元素本身不保存“最终画面”，它只保存自身的矩形坐标、顶点数据、颜色和材质信息。一旦位置变了、文字变了、图片换了，或者层级关系动过，原本缓存的顶点数据就失效了，需要重新计算一遍。
我把这个过程拆成三段：
- 布局阶段（Layout Rebuild）：计算UI元素的矩形位置和尺寸。这阶段会沿着层级往下递归，只要有父节点注册了布局脏标记，整棵子树都可能跟着重新计算。
- 几何阶段（Graphic Rebuild）：根据RectTransform的最终数值，重新生成网格顶点、UV、颜色、三角形索引。图片、文字、描边效果都在这里产生。
- 提交阶段（Batch/Geometry Upload）：重建出来的顶点数据需要上传到GPU侧，并重新做批次合并。这一步产生的开销通常在Profiler里显示为Canvas.SendWillRenderCanvases或者类似的入口。
很多人盯着第三个阶段看，觉得批次合并是万恶之源，却忽略了前两个阶段才是脏标记真正狂暴的地方。因为批次合并至少还有规律可循，而布局和几何重建往往是一场“整个子树陪你一起重算”的连锁反应。
1.2 Canvas重建和“重新渲染”不是一回事
这里有个很重要的区分：Canvas重建不等于整个UI重新渲染。真正渲染还是在GPU上按帧执行的，而重建意味着CPU侧要重新生成“画的指令数据”。如果把UI比作一块手绘黑板，渲染是照着黑板抄一遍，重建则是把黑板上的粉笔字全部擦掉、重新画一遍内容。
“重新画一遍内容”到底有多贵，取决于黑板上有多少东西。不是每个UI元素重建成本都一样，Image组件可能只需要重新生成四个顶点和两个三角形，而Text组件要重新走一遍字符布局、字体贴图采样、顶点生成，费用完全是两个量级。如果是带有描边或者阴影效果的文本，那一套操作还会再翻几倍。
Canvas重建的CPU开销还会直接影响帧率，因为它发生在主线程上。主线程一旦被重建拖住，渲染线程、游戏逻辑都得一起等着。这就是为什么UI界面一旦发生频繁重建，整个游戏的帧率都会跟着波动。
1.3 一块Canvas内部，重建是分批的
一块Canvas可能挂了几十个UI元素，但Unity不会每次把所有元素都重建。只有被打上脏标记的元素才会进入重建队列，其他元素继续用缓存的顶点数据。这个机制本身是合理的，可坑也藏在里面——脏标记的传播范围和频率，往往远超你的预期。
Unity对Canvas的更新粒度是“Canvas”级别，而不是“单个RectTransform”级别。意思是，同一个Canvas下哪怕只有一个元素标记了脏，整块Canvas的批次合并结果都可能要重新生成。虽然几何数据只有那一个元素重建，但合并批次时周围元素的状态照样会被重新检查一遍。
所以“UI卡顿”发生的时候，你要关注的不是某个元素重建一次有多贵，而是它有多少次触发了重建，以及它在哪块Canvas里倒了大霉。
提示：判断一块Canvas是否频繁重建，最快的方法是看Profiler里Canvas.SendWillRenderCanvases的调用耗时和触发频率。如果这个入口频繁出现且耗时抖动明显，基本可以断定这块Canvas正在经历脏标记风暴。
2. 谁在偷偷设置脏标记：从UI状态变化到重建的传导链路
脏标记这个词听起来挺硬核，其实理解起来不难。它就是UGUI内部用来登记“谁需要重新生成数据”的一个标记位。可难就难在，这个标记并不是只在“你改了UI”的时候才出现，很多你不经意的操作都会把它一并带上。
2.1 脏标记从哪来：所有导致“数据失效”的行为
我先列一下你会主动触发脏标记的场景：
- 修改RectTransform的尺寸（sizeDelta、rect的width/height）
- 修改位置（anchoredPosition、localPosition）
- 修改Image的sprite、color、fillAmount
- 修改Text的text内容、fontSize、fontStyle、lineSpacing
- 启用/禁用某个UI对象（SetActive）
- 修改Canvas或CanvasGroup的层级属性
- 在运行期动态添加或删除UI子节点
这些操作发生时，UGUI会调用对应的SetDirty方法，把这个UI元素以及它的父级布局节点统统登记一遍。
单纯看这个列表，你会觉得“那我不改UI不就行了”。真正麻烦的地方在于，SetActive、改父节点、文字变化这些都特别容易出现在游戏逻辑里。比如一个角色血条每帧刷新数字，一个排行榜列表在滚动时动态填充条目，或者一个弹窗打开关闭时切了一堆子物体，都会成片地设置脏标记。
2.2 Layout脏标记的放大效应：父节点比子节点更“贵”
我刚开始排查UI卡顿的时候，注意力全放在Text和Image身上，忽略了一个真相：现代UI里，很多元素都泡在各种LayoutGroup里面，比如HorizontalLayoutGroup、VerticalLayoutGroup、GridLayoutGroup、ContentSizeFitter。这些组件会在布局脏标记被设置时，做一次完整的子节点遍历和尺寸计算。
当一个子元素的尺寸变化了，它会把“需要重新布局”的脏标记一路往上抛给它的父LayoutGroup，父LayoutGroup再重新计算所有子元素的位置和尺寸。如果你的界面层级有三层LayoutGroup嵌套，那一块小小的血条数值变化，可能引发三层递归布局计算。
更狠的是，如果你在运行期动态修改了某个文字条目的内容，而这个条目又被ContentSizeFitter控制着尺寸，那么ContentSizeFitter会把尺寸变化继续传递给上层的LayoutGroup，最终可能导致整块面板里的所有元素都重新摆放一遍。
我实测过一组场景：有一个面板上有十条信息条目，每条都套着HorizontalLayoutGroup + ContentSizeFitter，初始界面这种结构没问题；但当每帧刷新其中一条的文本时，整块面板的布局重建频率直接飙升，帧耗从2ms涨到12ms级别。这说明布局重建的成本是“子树放大”的，不是单个元素本身的成本。
2.3 Graphic脏标记的级联效应：网格数据与批处理缓存的连锁失效
如果说Layout脏标记让布局计算重来一遍，那Graphic脏标记就是让网格数据和批次缓存全部作废。每个Graphic组件都有一份缓存好的顶点数据，只有标记为脏时才会重新生成。听起来很安全，可批次合并不管你这份缓存还有效没有——只要同一Canvas下有任何一个Graphic脏了，批处理的合并结果就可能整体失效。
Unity做批次合并时，是按照Canvas下所有Graphic组件的渲染顺序、材质ID、纹理ID、层级深度来分组的。某个Graphic一旦重建，它所在的合并组就有可能发生变化，Unity不得不重新检查周围Graphic的状态。即便它们本身的顶点数据没变，也要重新参与一次合并计算。
这就是“被低估”的地方：一个角落里小小的图标变了颜色，可能导致整块Canvas的批处理信息重新生成。尤其是当你的UI全部放在同一块Canvas下面时，这种互相拖累的现象会被放大得很厉害。
我还见过一种更隐蔽的场景：一张大图每隔几秒切换一次透明度做闪烁特效，结果整块Canvas下的所有UI批次全部震荡，虽然每个元素的数据没变，但Canvas.SendWillRenderCanvases的耗时飙升得很离谱。这就是脏标记加上批处理缓存失效的连锁反应。
2.4 脏标记的“传染性”：父节点活动状态切换最容易引发全屏重建
最后再补一个最容易翻车的场景：SetActive。UI对象的SetActive操作不只影响它自己，还会影响整个父Canvas的渲染状态。运行时启用一个隐藏的弹窗，或者隐藏一个常驻面板，都会让Canvas判断自己是否需要重新收集所有子节点信息。
有些项目喜欢把一整屏UI挂在同一个Canvas下，然后通过开关子节点来实现界面切换。这种做法在较少节点的界面上看不出毛病，但在上百个节点的界面上，每次开关都会让那块Canvas的批处理系统全部重来一次。我见过一个登录界面切到主界面时卡了超过100ms的极端情况，就是因为主界面整个Canvas下挂了几百个节点，切换时全部参与了状态更新。
3. 用Frame Debugger和Profiler按图索骥：一次典型卡顿的完整排查链路
这段是我在实际项目里最有价值的一段经验。框架和原理讲了半天，不如直接演示一下“当我怀疑是Canvas重建导致卡顿时，我会按什么顺序做排查”。这套链路我走过很多遍，针对UI卡顿的准确率非常高。
3.1 锁定卡顿现场：滚动列表掉帧的复现路径
我拿之前踩过的坑来复盘。当时做一个社交模块的排行榜界面，数据量不大，一共五十条排名记录，但每条记录包含头像、昵称、数值和排名变化箭头。界面里还有一个常驻的“我的排名”面板，固定在右上角。
问题的现象是：用手指拖动列表时，帧率在55帧和30帧之间剧烈波动，松手后恢复流畅。复现很简单，把列表拖一个来回就能看到明显掉帧。我当时第一反应是滚动列表的复用机制写得太烂，每条Item都在运行期动态创建，但检查完以后发现复用逻辑没有问题，于是转向Canvas侧排查。
3.2 用Frame Debugger确认重叠修复和批次生成情况
第一步，打开Window > Analysis > Frame Debugger（低版本Unity叫Frame Debugger）。在Enable后暂停到拖动列表的那一帧，逐条翻Draw Call记录。
这一步的核心目标有两个：一是确认当前帧的UI是否被拆成了多个批次（尤其是那些应该能合批却被拆开的元素），二是看Canvas的批次重建是否频繁出现在相邻帧之间。Frame Debugger能看到每个Draw Call对应的Canvas渲染命令，如果拖动过程中相邻帧的Draw Call数量和内容一直在变，说明Canvas重建非常活跃。
排行榜列表头部、背景、滚动条、右上角面板这些区域的元素，在我那个项目里全部挂在同一个Canvas下。Frame Debugger里能看到一个很明显的现象——滚动列表的每一条Item都生成了独立的Draw Call，说明它们中间隔着一些破坏合批的元素。往下翻之后，发现每一条Item都带有独立的边角框和头像圆角处理，材质状态不一致，导致合批失败。
但这不是掉帧的关键，因为Draw Call数量最多也不到一百个，不至于把CPU拖到30帧。真正关键的是，列表滚动时每条Item的尺寸和位置都在变化，这些变化意味着每帧都在设置Graphic脏标记，进而推动整块Canvas的批处理流程整体更新。
3.3 用Profiler定位重建时间与触发源
第二步，打开Profiler，切到CPU Usage模块，勾选Hierarchy视图，把线程切到Main Thread。复现拖动列表的动作，同时录制十几秒的数据。
录制完后看Main Thread的耗时曲线，找到掉帧区间的热点函数。在Unity 2020+版本里，UI相关的重建入口名称比较明确，主要看这两个名字：
- Canvas.SendWillRenderCanvases：这个入口代表UI准备提交渲染数据，里面包含了重建和合批的主要耗时。
- Canvas.BuildBatch：批次构建的实际执行点，耗时高说明合并批次或网格上传跟着涨了。
我的Profiler记录里，上述两个入口在掉帧区间出现了明显的尖峰，单个帧的耗时加起来超过20ms，相当于这一帧完全被UI卡住了。再往下钻取，能看到重建内部的堆栈，分别指向Text的网格生成和RectTransform尺寸计算。
这里有个技巧：Profile里的UI重建堆栈，会把具体重建的是哪个组件列出来。Unity的Profiler里可以展开Canvas.SendWillRenderCanvases的子树，查看Graphic.Rebuild和Layout.Rebuild的调用来源。比如你会看到某一条Text组件的Rebuild耗时极高，这就直接定位到了“哪个元素的重建成本最贵”。
3.4 用对比实验隔离脏标记来源
定位到元凶以后，还需要确认脏标记到底是谁在设置。因为Profiler告诉你的是“某元素重建了”，不一定告诉你“为什么它每帧都重建”。这时候就需要做对比实验。
我当时的做法是：把“我的排名”面板单独挪到另一块Canvas下，并且把面板内的元素全部设为不随列表滚动更新。结果一样没解决问题，说明病根不在这个常驻面板上。接着我改成在列表滚动期间停止刷新前十名的头像框特效，再测一次——掉帧幅度立刻下降。继续锁定后发现，排行榜前十名的条目里，每条都带有一个“排名变化箭头”，那个箭头每帧都在做颜色渐变动画，导致对应的Graphic每帧都被设置脏标记。
这就解释了为什么列表Item一旦复用，前面十条的动画箭头就能把整块Canvas的批处理拖垮。十个小箭头的动画，看着微不足道，但它们所在的Canvas是整块大Canvas，重建时把周围所有元素全部牵扯了进来。
提示：对比实验的思路就是“控制变量”。当你怀疑某个元素可能引发脏标记时，直接从界面里移除它跑一遍测试，如果掉帧消失，说明它就是源头；如果掉帧还在，再继续缩小范围。这个方法虽然笨，但在UI排查里极其有效。
4. 优化实操：怎么把Canvas重建从“全屏灾难”变成“局部阵痛”
找到病根之后，剩下的工作就是怎么动刀。这一节我会把优化手段按收益从高到低列出来，每一条都标清楚适用场景和注意事项。优化不是单纯地“减少Draw Call”，而是管控脏标记的传播范围、频率和重建成本。
4.1 动静分离：把常驻UI和动态UI拆到不同Canvas
这是所有UI优化手段里收益最大、实施成本最低的一条。所谓动静分离，就是让“几乎不变”的元素和“频繁变化”的元素各归各的Canvas，阻断脏标记和批处理失效的传染路径。
我那个排行榜项目最后就是按这个思路改的。整块界面被拆成三块：
- 背景、标题、页签、底部按钮这些静态元素，放进一块静态Canvas，除了打开关闭几乎不会变。
- 列表区域单独建一块Canvas，列表Item的创建、回收、位移都在里面发生。
- “我的排名”面板和顶部常驻信息单独放一块Canvas，确保它不跟着滚动列表一起折腾。
这样改完之后，静态Canvas的批处理信息几乎永远不需要重建，滚动列表的脏标记只影响列表Canvas自己，顶部面板也不会每帧被列表拖累。帧率从30帧回到了接近58帧，拖动过程非常稳定。
需要提醒的是，Canvas拆多了也不是好事。每块Canvas都会增加一次渲染提交和深度排序的开销，拆得太碎反而会让Draw Call增加。经验上，同屏Canvas数量控制在不超过三到四块比较合理，除非有特殊原因。
4.2 管住RectTransform和LayoutGroup：让布局重建少发生
布局重建往往是脏标记里面最贵的部分，因为它是递归的。优化布局重建主要从两个方向下手：一是减少触发频率，二是降低单次布局计算成本。
降低触发频率的核心是别让尺寸频繁变化。比如动态文本频繁改内容时，如果没有必要实时同步宽度，就别开ContentSizeFitter，改成固定宽度+裁剪文本。这样文本内容变化时不会向上层LayoutGroup传递尺寸变化，布局重建的传播链就被截断了。
降低单次布局成本的方法包括：
- 把LayoutGroup从频繁变动的子树里挪出来，让它们管住静态区域就行。
- 减少LevelGroup的层级嵌套深度，尽量把嵌套的LayoutGroup拍平。
- 如果列表Item的尺寸是固定的，优先用固定尺寸的RectTransform，别做运行期尺寸计算。
还有一个容易被忽略的点：RectTransform的anchoredPosition和sizeDelta修改，都会触发布局脏标记。就算你没有主动把它挂到任何LayoutGroup下面，它自身的位置变化也会让Graphic重建。所以列表滚动时频繁修改Item的位置，本质上每帧都在做一次位置驱动的重建，这个不可避免，但至少要保证它影响的范围是局部的。
4.3 手动接管UI更新：让动画不依赖每帧SetDirty
最彻底的控制方式，是让一部分UI动画不再走UGUI的脏标记机制。比如颜色渐变动画、透明度闪烁、缩放动画这类“看起来有变化，但不需要每帧重新生成顶点数据”的效果，可以考虑直接用材质属性或shader来做。
常见的做法包括：
- 透明度/颜色渐变改用MaterialPropertyBlock或Tween调CanvasGroup，而不是每帧修改Image的color。
- 缩放动画尽量用RectTransform的localScale，但要注意localScale变化同样会产生脏标记。如果非常在意，可以考虑用shader做一个假缩放，或者用专门的UI动画系统绕开常规重建路径。
- 图片切换动画如果只是Alpha淡入淡出，优先用CanvasGroup替代Image.color，因为CanvasGroup的透明度变化在批处理层面上不会重建内部网格数据，代价更小。
我做过一个实验：把一排按钮的悬停高亮效果从“每帧SetDirty改颜色”改成“只有悬停进出时修改一次颜色”，重建次数立刻少了一大截。很多时候UI卡顿来自“不必要的每帧更新”，而不是UI本身有多复杂。
4.4 合批与重建的平衡：不要把Canvas拆到失去意义
很多教程喜欢强调合批的重要性，这个没错，但UI优化的终极目标不是把所有元素都合到一个批次。合批的前提是材质相同、纹理相同、层级连续、中间没有破坏者。为了强行合批，把所有UI塞进一个Canvas，实际上会放大脏标记的影响范围，这是捡了芝麻丢西瓜。
合理的做法是：以“脏标记传播范围最小化”为第一优先级，以“同批次内合批效果好”为第二优先级。动态区域和静态区域分开Canvas之后，每块Canvas内部再去追求合批质量。这样既能享受合批的渲染优势，又不会让动态元素拖垮静态元素。
4.5 实测数据：同一界面的优化前后对比
下面这组数据来自我做的排行榜界面优化实测，可能不够权威，但方向很有参考价值。测试机型是某中端Android设备，界面节点总数150个左右，滚动列表同时可见10条Item。
| 优化项 | 优化前 | 优化后 |
|---|---|---|
| Canvas数量 | 1块 | 3块 |
| 主线程UI耗时（峰值） | 22ms | 8ms |
| UI重建触发帧数（1秒内） | 60帧全部触发 | 约30帧触发 |
| 同屏Draw Call数 | 45左右 | 38左右 |
| 平均帧率 | 32帧 | 57帧 |
| 掉帧频次 | 频繁 | 偶发 |
从这个表可以看出，UI重建的优化对帧率的提升是最直接的。Draw Call数并没有大规模下降，但卡顿问题基本消失，原因在于CPU端的主线程压力被大幅释放了。这也是我反复强调的：UI卡顿要先钉死CPU端的重建问题，再去看GPU端的合批问题。
5. 容易被漏掉的边缘场景：文字组件、列表复用与CanvasGroup
最后补几个我在实际项目里反复中招的边缘场景。它们不属于那一类“一看就性能爆炸”的写法，但累积起来，杀伤力一点也不小。
5.1 动态文本的隐性重建成本
Text组件是UGUI里重建成本最高的组件之一。每改一次text内容，它要做字符解析、字体纹理索引、顶点生成，如果还开了Rich Text那工作量还要加码。
有一种坑是：你的text内容其实没变，但因为逻辑代码里每帧都执行“text.text = xxx”，Unity照样会把它标记为脏。就算赋值内容完全相同，只要调用到了text的setter，它就会走一遍的脏标记判断。
解决办法很简单：赋值前先比较一下字符串是否相同，或者维护一个本地缓存，只在内容真正变化时才设置text属性。这个优化看着很基础，但在开发后期能省下大量的无效重建成本。
5.2 列表Item复用时的“残留脏标记”
使用ScrollRect时，Item的复用逻辑如果处理不当，会在复用瞬间同时触发多个脏标记。比如一棵Item里包含头像、昵称、等级框、按钮等多个Graphic，复用时一次性改了它们的sprite、text、size，结果整棵Item的每个组件都在同一帧被标记为脏，重建成本集中爆发。
优化手段是给Item的各个组件预先分配一个“显示的最终状态”，复用时一次性全部设置好，避免在子节点上反复Toggle SetActive。尤其是不要用SetActive控制Item里每个小元素的显示，尽量用CanvasGroup控制显隐，或者让隐藏组件常驻，只在需要时调整位置/内容。
5.3 CanvasGroup的隐藏用法与重建成本
CanvasGroup是一个很神奇的存在。它的alpha变化不会触发Graphic重建，但它的blockRaycasts和interactable变化会影响UI事件系统的响应，不会直接触发重建。所以很多UI显隐切换可以用CanvasGroup替代SetActive来做，能明显减少脏标记的产生。
但要注意，CanvasGroup的alpha是“整组”生效的，它会影响它下所有Graphic的最终颜色混合，但不会为每个Graphic重新生成顶点数据。这一点在UI切换动画里特别管用。我常用的技巧是：淡入淡出动画一律用CanvasGroup或Animation驱动alpha，而不是逐帧改Image.color。按百分比降低重建频率，对整个界面卡顿的缓解作用很可观。
5.4 运行时动态创建UI节点的隐藏风险
如果游戏逻辑里存在运行期动态Instantiate UI节点的情况，尤其是频繁实例化/销毁弹窗内容，那每一帧都可能引起父Canvas的重建。这不是优化问题，而是设计问题。成熟的做法是预创建一个对象池，把弹窗、列表Item、飘字等UI元素全部池化复用，彻底避免运行期Instantiate/Destroy带来的脏标记涟漪。
池化以后，Item进入列表时只改内容和显示状态，虽然也会造成重建，但比创建销毁驱逐强多了。而且池化还能顺手控制“哪些Item内的组件在复用批次中会被同时重建”，方便批量规划好重建频次。
6. 优化做完之后，怎么验证没把界面搞坏
UI优化的最后一步，不是看Profiler数字变得多好看，而是确认界面表现没有副产物。我见过有人为了降重建帧数把Canvas拆了一堆，结果透明弹窗层级错乱、描边文字破碎、点击事件穿透，问题比优化前还多。
验证维度我一般按下面这张表过一遍：
| 检查项 | 具体观察点 |
|---|---|
| 视觉一致性 | 拆分Canvas后，透明度叠加、遮罩区域、UI层级顺序是否保持一致 |
| 点击响应 | 常驻按钮、弹窗按钮、列表Item的点击区域是否还正确 |
| 动态效果 | 淡入淡出动画、悬停高亮、滚动跟随是否流畅且不掉帧 |
| 内存与加载 | 新增Canvas带来的额外内存和加载成本是否可接受 |
| 多分辨率适配 | 不同屏幕宽高比下，拆分后的布局是否仍然正常 |
做验证时，记得把性能Profile和Bug记录分开执行。先确认功能正常，再盯性能数据。千万不要在一堆功能Bug还没有修完的情况下去调性能曲线，那样只会被无效数据带偏。
还有一点：UI优化的结果要经得起“长时间挂机”的考验。很多UI卡顿问题不是出现在刚打开界面的时候，而是出现在“界面被反复打开关闭三十次以后”。因为动态创建的节点如果没有正确销毁，脏标记会越积越多，最终触发大面积重建。做验证时，至少要让界面开关循环跑到五十次以上，再回看一次Profiler。
7. 写在最后：我对脏标记控制的一点个人体会
做UI优化做久了，我发现一个规律：优化Canvas重建的关键，从来不是“不要用UI”“把UI都砍掉”，而是搞清楚“谁在什么时机碰了UI数据”。脏标记不可怕，可怕的是它的传播范围和触发频率失控。你没法避免游戏运行时有动态变化，但你能做到的是让每一次变化的成本都留在最小范围内。
我自己现在接手一个Unity项目，第一件事就是打开主界面看一眼所有UI是否都在一块Canvas下面。如果是，我基本能预判这个项目一旦界面复杂化就会出现卡顿；如果不是，我会再看动态区域有没有和静态区域混在同一块Canvas里。这套检查习惯帮我避开了很多暗坑，也让“UI卡顿”从一个玄学问题变成了可量化、可定位、可修复的工程问题。
希望这篇文章能帮你少走点弯路。下回如果你的界面突然掉帧，先别急着怀疑GPU，按这个思路把Canvas和脏标记查一遍，大概率能直接抓到那个躲在角落里偷偷重建的元凶。
