Image.color与CanvasRenderer.SetColor修改UI组件颜色的本质差异及效率疑问

问题背景 #

平时我们修改Image组件颜色时，习惯直接修改它的Color属性，原理是修改网格顶点颜色，但这个操作会触发Canvas.BuildBatch，存在一定性能开销。

近期研读UGUI源码发现，当Button组件设为Color Tint类型时，点击触发的颜色渐变会通过协程修改CanvasRenderer组件颜色，而非直接修改Image的Color属性，相关源码如下：

public abstract class Graphic : UIBehaviour, ICanvasElement
{
    private readonly TweenRunner<ColorTween> m_ColorTweenRunner;

    // 点击时触发
    public virtual void CrossFadeColor(Color targetColor, float duration, 
        bool ignoreTimeScale, bool useAlpha, bool useRGB)
    {
        //...
        var colorTween = new ColorTween {duration = duration, 
            startColor = canvasRenderer.GetColor(), targetColor = targetColor};

        // 该回调会在协程中触发，修改CanvasRenderer组件的颜色
        colorTween.AddOnChangedCallback(canvasRenderer.SetColor);

        colorTween.ignoreTimeScale = ignoreTimeScale;
        colorTween.tweenMode = mode;

        // 启动协程
        m_ColorTweenRunner.StartTween(colorTween);
    }
}

想请教：这两种修改方式的本质差异是什么？直接修改CanvasRenderer.color是否更高效？

本质差异与性能分析 #

1. 底层逻辑核心区别 #

• 修改Image.Color：Image继承自Graphic，修改Color属性时，UGUI会标记该Graphic为「顶点数据脏了」（设置m_VertsDirty = true），下一帧会重新生成整个Graphic的网格顶点数据（把Color值应用到每个顶点的颜色通道），随后触发Canvas.BuildBatch——这个过程会重新计算当前Canvas下所有可合批元素的批次，把更新后的网格数据提交给GPU。
• 修改CanvasRenderer.color：CanvasRenderer是UGUI对接渲染管线的直接入口，它的color属性是作用于渲染状态的全局颜色遮罩，不会修改Graphic的网格顶点数据，只是在GPU绘制阶段给整个Graphic的纹理叠加一层颜色，相当于GPU层面的颜色混合操作，不需要重建网格，自然也不会触发Canvas.BuildBatch。

2. 性能对比：CanvasRenderer.color确实更高效 #

• 频繁修改Image.Color的话，每一次操作都会触发网格重建和Canvas合批重建，在UI元素较多的场景中，多次触发BuildBatch会带来明显的CPU开销，甚至可能引发卡顿。
• 而修改CanvasRenderer.color时，仅需修改一个渲染状态变量，GPU直接用该值做颜色叠加，全程不需要CPU重新计算网格或合批，性能开销极小——这也是UGUI官方在Color Tween逻辑中选择这种方式的核心原因，尤其适合Button点击渐变这类需要高频更新颜色的场景。

3. 适用场景的局限 #

虽然CanvasRenderer.color性能更优，但也有使用限制：

• 它是给整个Graphic加全局颜色遮罩，如果你的Graphic本身带有顶点颜色差异（比如自定义渐变效果的Graphic），使用CanvasRenderer.color会覆盖原有顶点颜色的差异化表现；而修改Image.Color是在保留原有顶点颜色逻辑的基础上叠加颜色。
• 如果需要让颜色变化被UI布局系统感知（比如某些依赖颜色状态的布局逻辑），只有修改Image.Color才会触发相关布局更新，CanvasRenderer.color的修改不会影响布局计算。

内容的提问来源于stack exchange，提问作者Ffly