46.Canvas.BuildBatch与Layout.Rebuild性能分析
46.1 题目
一个 UI 界面打开时明显卡顿，Profiler 里看到 Canvas.BuildBatch 和 Layout.Rebuild 很高，你会怎么分析？
46.2 深入解析
Canvas.BuildBatch
含义：Canvas 正在重新构建渲染批次，UI 在重新整理如何渲染出来。
触发条件：
| 操作 | 说明 |
|---|---|
| 显隐 UI | SetActive 开关 UI 元素 |
| 修改属性 | 图片、文字、颜色、透明度变化 |
| 层级变化 | 修改渲染顺序、父子关系 |
| 批量刷新 | 大量元素同时变化 |
| 大 Canvas | 一个 Canvas 中有频繁变化的元素 |
Layout.Rebuild
含义：UI 布局系统正在重新计算布局，UI 在重新排版。
触发条件：
| 操作 | 说明 |
|---|---|
| 文本变化 | 文字内容改变导致尺寸变化 |
| 尺寸变化 | RectTransform 宽高改变 |
| 层级变化 | 父子关系调整 |
| 布局组件 | LayoutGroup、ContentSizeFitter 等 |
| 强制刷新 | LayoutRebuilder.ForceRebuildLayoutImmediate |
分析思路
第一步：判断是尖峰还是持续
| 情况 | 特征 | 可能原因 |
|---|---|---|
| 打开瞬间尖峰 | 只在首帧高 | 批量生成节点、初始化文本、激活对象 |
| 持续多帧高 | 多帧都有消耗 | 逻辑不断标脏 UI、Layout 滥用 |
尖峰情况分析
可能原因：
- 打开界面时批量生成大量节点
- 初始化时修改大量文本和尺寸
- 激活大量对象导致布局重建和批次重建叠加
优化方向：
- 分帧创建 UI 元素
- 预先创建好节点池，只做显隐
- 延迟初始化非关键元素
持续情况分析
可能原因：
- Layout 滥用：多层 LayoutGroup 嵌套、ContentSizeFitter 过多
- 频繁标脏：循环里改 UI、每帧更新文本
- 强制刷新：调用 ForceRebuildLayoutImmediate
- Canvas 过大：静态和动态元素混在一起
优化方向：
- 减少 LayoutGroup 嵌套层级
- 拆分 Canvas：静态元素和动态元素分开
- 避免循环中修改 UI
- 用缓存替代实时计算
定位方法
逐项排查：
- 关闭布局组件，观察性能变化
- 拆分 Canvas，隔离问题区域
- 减少首帧生成数量
- 检查是否有每帧修改 UI 的逻辑
Profiler 定位：
- 展开 Canvas.BuildBatch 查看具体耗时
- 检查 Layout.Rebuild 调用堆栈
- 对比打开前后的差异
46.3 答题示例
Canvas.BuildBatch：UI 重新整理渲染批次，显隐、改属性、改层级都会触发。
Layout.Rebuild：UI 重新计算布局，改文本、改尺寸、布局组件会触发。
分析思路：先判断是尖峰还是持续。尖峰优先怀疑打开时批量操作；持续则检查 Layout 滥用、循环改 UI、Canvas 过大。
优化方向：分帧创建、预创建节点池、减少 LayoutGroup 嵌套、拆分 Canvas 静态动态、避免循环改 UI。
46.4 关键词联想
- Canvas.BuildBatch
- Layout.Rebuild
- UI 批次重建
- 布局计算
- LayoutGroup
- ContentSizeFitter
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 785293209@qq.com
