前言

UnityEngine.Object 类作为 Unity 中所有内建对象的基类，可以在 Unity 中被任意引用。继承自 System.Object，并且重载了 ==、!= 和 bool 几个特殊的操作符。

问题

问题从一行错误日志开始。在最近的一个线上项目中收到这样一条错误上报:

MissingReferenceException: The object of type ‘GameObject’ has been destroyed but you are still trying to access it.
Your script should either check if it is null or you should not destroy the object.

定位到具体代码，大致如下:

1

Transform transform = gameObject?.transform;

当前 GameObject 已经被销毁仍然尝试读取其 transform，但是这里明明已经使用 ?. 操作符判定了，为什么还会出现这个问题？下面尝试模拟这种情况。

1
2
3
4

GameObject gameObject = new GameObject("go");
DestroyImmediate(gameObject);

Transform transform = gameObject?.transform;

运行上面的代码，确实抛出了一样的错误异常。难道是 ?. 操作符的问题？下面我们换一种方式来 check null，如下:

1
2
3
4
5
6
7
8

GameObject gameObject = new GameObject("go");
DestroyImmediate(gameObject);

Transform transform;
if (gameObject != null)
{
    transform = gameObject.transform;
}

运行这一段代码，没有错误异常抛出，说明 check null 成功。为什么 ?. 操作符会检验失败？带着疑问来深入看一下编译器为我们生成的部分 CIL 代码。

探究

在探究之前，首先补充一段关于 UnityEngine.Object 知识。在 Unity 中，所有实际的 UnityEngine.Object 的数据均存储在一段本地原生的对象空间中，与 CLR 无关；在 CLR 层中的 UnityEngine.Object 对象实际上是一个指向本地原生对象的指针，这类对象又被称为 “wrapper objects”。

原生对象的生命周期由 Unity 管理，在加载新场景、显式调用 Destroy 方法(当前帧的某个时刻执行)或调用 DestroyImmediate 方法(立即执行)时原生对象会被销毁。C# 中的 UnityEngine.Object 对象的销毁回收由 CLR 决定。因此就可能出现一种情况: 本地原生对象已经被销毁，但是由于 CLR GC 未发生，导致 C# 中的 UnityEngine.Object 对象未被回收。

了解了这个知识点，下面开始探究问题所在。

看看第一段使用了 ?. 操作符生成的的 CIL 代码指令:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

.locals init (
    [0] class [UnityEngine.CoreModule]UnityEngine.GameObject gameObject,
    [1] class [UnityEngine.CoreModule]UnityEngine.Transform transform
)
IL_0001: ldstr "go"
IL_0006: newobj instance void [UnityEngine.CoreModule]UnityEngine.GameObject::.ctor(string)
IL_000b: stloc.0
IL_000c: ldloc.0
IL_000d: call void [UnityEngine.CoreModule]UnityEngine.Object::DestroyImmediate(class [UnityEngine.CoreModule]UnityEngine.Object)

// check null 部分指令
IL_0013: ldloc.0
IL_0014: brtrue.s IL_0019

IL_0016: ldnull
IL_0017: br.s IL_001f

IL_0019: ldloc.0
IL_001a: call instance class [UnityEngine.CoreModule]UnityEngine.Transform [UnityEngine.CoreModule]UnityEngine.GameObject::get_transform()

IL_001f: stloc.1
IL_0020: ret

上面生成的 CIL 指令，从 IL_0001 到 IL_000d 主要是生成新的 GameObject(存在于 Managed Heap 中) 并将其引用存入 Record frame 的第 0 个变量处，然后调用 DestroyImmediate 方法销毁这个 GameObject。

接着就是 ?. 操作符部分的 CIL 指令(从 IL_0013 开始)。首先加载当前 Record frame 中的第一个变量值(这里是 GameObject 的引用)到 Evaluation stack 中，使用 brtrue.s 判断这个引用的对象是否为空，不为空则跳转到 IL_0019 处开始调用 get_transform 方法，为空则返回 null。这样看下来 ?. 操作符就是判断了当前 GameObject 引用对象是否为空，和普通 System.Object 对象 != null 处理类似。

那么绕过空检测出现错误异常的原因也就知道了。当我们调用 DestroyImmediate 方法销毁一个 GameObject 对象的时候，此时在底层对应的原生对象是被销毁了，但是其存在于 CLR 层的引用对象(方法结束后对象临时引用变量被释放销毁，存放于 Managed heap 中的 GameObject 对象等待 GC 释放)并未被销毁，若使用 ?. 操作符在 CLR 层面判断不为空，跳转到 get_transform 方法所在指令附近获取 transform，由于底层的 GameObject 已经被销毁所以底层抛出 ‘MissingReferenceException’ 异常。

那么为什么使用常规 != null 形式判空没出现这个问题了，再来看看这种方式生成的 CIL 代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

.locals init (
    [0] class [UnityEngine.CoreModule]UnityEngine.GameObject gameObject,
    [1] class [UnityEngine.CoreModule]UnityEngine.Transform transform,
    [2] bool
)
// 生成 GameObject 以及销毁 GameObject ...

// check null 部分指令
IL_0013: ldloc.0
IL_0014: ldnull
IL_0015: call bool [UnityEngine.CoreModule]UnityEngine.Object::op_Inequality(class [UnityEngine.CoreModule]UnityEngine.Object, class [UnityEngine.CoreModule]UnityEngine.Object)
IL_001a: stloc.2
IL_001b: ldloc.2
IL_001c: brfalse.s IL_0027

IL_001f: ldloc.0
IL_0020: callvirt instance class [UnityEngine.CoreModule]UnityEngine.Transform [UnityEngine.CoreModule]UnityEngine.GameObject::get_transform()
IL_0025: stloc.1

IL_0027: ret

前面的指令基本都相同，我们主要看看判空部分。首先加载了生成的 GameObject 以及 null，然后在 IL_0015 处调用了 UnityEngine.Object 类重载的 op_Inequality 操作符(operator !=)判断 GameObject 是否不为空，如果判定为空则跳转到 IL_0027 指令结束方法，否则从 IL_001a 处继续执行指令获取 transform。下面就来重点解读 UnityEngine.Object 重载的 != 操作符的实现部分。

首先看看源码:

1
2
3
4

public static bool operator !=(Object x, Object y)
{    
    return !Object.CompareBaseObjects(x, y);
}

具体的实现在 CompareBaseObjects 方法:

1
2
3
4
5
6
7
8
9
10
11
12
13

private static bool CompareBaseObjects(Object lhs, Object rhs)
{
    bool flag1 = (object) lhs == null;
    bool flag2 = (object) rhs == null;
    if (flag2 && flag1)
        return true;
    if (flag2)
        return !Object.IsNativeObjectAlive(lhs);
    if (flag1)
        return !Object.IsNativeObjectAlive(rhs);

    return lhs.m_InstanceID == rhs.m_InstanceID;
}

上面的方法用来比较两个 UnityEngine.Object 对象是否相等，lhs 和 rhs 分别代表操作符两边的参数:

• 若两边参数在 CLR 层均为 null，判定相等；

• 若右边参数在 CLR 层为 null，左边不为 null，根据左边参数 CLR 层所在对象对应的底层原生对象是否 Alive 返回比较结果；

• 若左边参数在 CLR 层为 null，右边不为 null，根据右边参数 CLR 层所在对象对应的底层原生对象是否 Alive 返回比较结果；

• 否则左右两边对象在 CLR 层对象均不为 null，比较它们的 m_InstanceID 是否相等。

在我们的测试代码中分别是 GameObject 对象和 null。通过前面的分析指导，调用 DestroyImmediate 方法销毁一个 GameObject 对象时仅底层对应的原生对象是被销毁了，但是其存在于 CLR 层的引用对象未被销毁；所以上面方法中 flag1 为 false，flag2 为 true，最终返回结果由 UnityEngine.Object 类的 IsNativeObjectAlive 方法决定，这个方法正是判断 CLR 层所在 GameObject 对应的原生对象是否处于 Alive 状态。

在测试代码中，调用了 DestroyImmediate 方法销毁了原生的对象，最终 CompareBaseObjects 方法返回 true，重载的 != 操作符返回 false。因此 get_transform 方法所在的指令不会被调用，从而不会出现错误异常。

!= 和 bool 操作符

!= 操作符同重载的 == 操作符逻辑刚好相反；bool 操作符具体实现也是调用 CompareBaseObjects 方法:

1
2
3
4

public static implicit operator bool(Object exists)
{
    return !Object.CompareBaseObjects(exists, (Object) null);
}

从上面源码可以看出 bool 操作符内部同样使用了 CompareBaseObjects 方法将判定对象与 null 比较，如果判定对象为 null 返回 false，否则返回 true。

总结

到这里应该清楚某些情况下出现错误异常的原因了，在 Unity 文档中关于 Object 有下面这样一句提及:

This class doesn’t support the null-conditional operator (?.) and the null-coalescing operator (??).

UnityEngine.Object 类重载了 ==、!= 以及 bool 操作符，对于这几类操作 Unity 会结合 CLR 层的对象以及其底层对应原生对象来得到比较结果。

所以对于 UnityEngine.Object 类(子孙类)类型相关变量使用 ?. 和 ?? 操作符一定要谨慎，有时显式的使用 null 判断或 bool 重载符对 UnityEngine.Object 往往更“安全”。

关于 MonoBehaviour 可序列化的域

对于 MonoBehaviour 可序列化的域，在 Editor 模式下就算这些域没有真正的被“赋值”，Unity 默认也会为其 CLR 层所在的 GameObject 对象默认设置上 “fake null” object (底层原生对象不会被赋值)，通过这样的小 track Unity 能够为开发者调试提供更多的有用信息。

参考

• Possible unintended bypass of lifetime check of underlying Unity engine object

• Custom == operator, should we keep it?

前言

作为研发的你工作中可能碰到过这样的场景：

某天，策划同学 J 想到一个能给玩家带来愉悦感的「送钱特效」，这是一个三维场景中很多金币模型带有曲线的飞跃效果；渲染在屏幕上时，金币模型还被要求能从屏幕的指定位置飞到屏幕的另一指定位置。第二天，美术同学 S 在三维场景中调出了最好看的金币模型渲染效果，剩下的…

当然剩下的就由作为研发的你来接手实现了。

简单实现这个需求

3D 模型渲染到已有的 Unity UI 上面，使用 Camera、Render Texture 和 Raw Image 来实现；脚本控制模型运动效果，Camera 来拍摄这些效果并渲染到 Render Texture 上，再利用 Raw Image 将 Render Texture 在 Unity UI 层展示出来。

通过上面操作，已经能将「送钱特效」渲染到屏幕上了。但是好像有一点被忽略了，如何保证「送钱特效」中金币飞跃的起始位置了？金币模型是在三维场景(世界空间)中，而屏幕上的位置属于二维场景(屏幕空间)，必须得将它们联系起来。

Screen Space (屏幕空间)到 World Space (世界空间)

在谈转换之前，首先需要了解几个知识点:

1. 当没有相机渲染 Canvas (Canvas 的 Render Mode 设置为 Screen Space - Overlay 或 Screen Space - Camera 且不设置相机)时:

   • Canvas 左下角位于世界空间下的原点处(Canvas 此模式下世界空间下 Z 坐标为 0)；

   • 位于 Canvas 中的 RectTransform 世界坐标就是其所在的屏幕坐标(X 和 Y 方向)，Z 方向世界坐标是其相对于父元素世界坐标偏移 localPosition.z (或 Pos Z)的值；

2. Canvas 的 Render Mode 设置为 Screen Space - Camera 并设置相机)时:

   • Unity 中一个 UI 单位不再是对应一个 Unity 单位；

   • Canvas 的 Pivot 处 X 和 Y 方向世界坐标和渲染 Camera X 和 Y 方向世界坐标相等；

   • Canvas 所在平面 Z 方向世界坐标由其设置的 Plane Distance 值和渲染 Camera 的 Z 方向世界坐标共同决定；

3. Canvas 的 Render Mode 设置为 World Space 时:

   • 此时会将 Unity UI 当做 3D 物体来渲染，Canvas 可以位于空间中任何位置；

   • 位于 Canvas 中的 RectTransform 世界坐标即可根据 Canvas 位置以及其 localPosition 得出；

上面三种情况下，Unity 中 UI 单位与 Unity 单位对应关系受 RectTransform 祖先元素缩放影响，具体表达式为:

有了上面的知识点，再来看看 Screen Space 到 World Space 的转换。

对于 Canvas 的 Render Mode 为 Screen Space - Overlay 或 Screen Space - Camera 且不设置相机 这种模式，Canvas 下 RectTransform 的世界坐标表达式为:

其中 World.Position 为 RectTransform 的世界坐标；Screen.Position 为 RectTransform 在屏幕上的坐标；Parent(n).LocalPosition 为 RectTransform 某一层祖先元素相对其父节点的坐标，PerUIUnitUnityUnit(n) 为这一层祖先元素一个 UI 单位对应的 Unity 单位的数目；Self.LocalPosition 是 RectTransform 自身相对父节点的坐标，PerUIUnitUnityUnit(Self) 为自身 RectTransform 一个 UI 单位对应的 Unity 单位的数目。

对于 Canvas 的 Render Mode 为 World Space，Canvas 下 RectTransform 的世界坐标表达式为:

其中 World.Position 为 RectTransform 的世界坐标；Parent(n).LocalPosition 为 RectTransform 某一层祖先元素相对其父节点的坐标，PerUIUnitUnityUnit(n) 为这一层祖先元素一个 UI 单位对应的 Unity 单位的数目；Self.LocalPosition 是 RectTransform 自身相对父节点的坐标，PerUIUnitUnityUnit(Self) 为自身 RectTransform 一个 UI 单位对应的 Unity 单位的数目；Canvas.Position 是 Canvas 在世界空间下的坐标。

对于 Canvas 的 Render Mode 为 Screen Space - Camera 并设置相机)，这种情况相对复杂一点。

首先需要明白在这种情况下，为什么一个 Unity 单位不再固定对应一个 UI 单位。当 Canvas 的 Render Mode 设置为这种模式时，Camera 需要保证在其正前方 Plane Distance 距离处的视锥体切面大小能够完全吻合 Canvas 平面大小；有了这点限制，Camera 的 Field Of View 以及 Canvas 的 Plane Distance 都可以影响 Unity 单位和 UI 单位的对应关系。

下面就来找出 Canvas 在这种渲染模式下 Unity 单位和 UI 单位的对应关系，如下图:

从上图可以看出，屏幕高度(UI 单位)和 Plane Distance 以及 Field Of View 之间存在三角函数关系，如下:

一个 Unity 单位和 UI 单位关系表达式为:

从上面的关系表达式中可以知道: 当屏幕分辨率(Canvas 尺寸大小)和 Camera 的 Field Of View 都固定时，Canvas 的 Plane Distance 越大，一个 Unity 单位对应的 UI 单位数越少，反之越多；当屏幕分辨率(Canvas 尺寸大小)和 Canvas 的 Plane Distance 都固定时，Camera 的 Field Of View 越大，一个 Unity 单位对应的 UI 单位数越少，反之越多。

知道了 Unity 单位和 UI 单位关系表达式，就能够得到 Canvas 中 RectTransform 在世界空间下的坐标表达式了，如下图是一个 Button Camera 拍摄切面图:

首先来计算 Canvas 的 Pivot 处的世界坐标，前面提到过这个坐标和 Camera 的世界坐标以及 Plane Distance 相关，具体表达式如下:

Canvas 的 Pivot 世界坐标最终表达式:

有了 Canvas 的世界坐标计算表达式和 Unity 单位和 UI 单位的对应关系，Canvas 下 RectTransform 的世界坐标计算表达式也就可以方便得到:

其中 CanvasPivot.Position 为上面计算得到的 Canvas Pivot 的世界坐标，Parent(n).LocalPosition 为 RectTransform 第 n 个祖先节点相对其父元素的坐标，RectTransform.LocalPosition 是 RectTransform 自身相对父节点的坐标，PerUnitPixels 是前面得到的 Unity 单位和 UI 单位的对应关系表达式。

最后将 RectTransform 祖先元素的缩放影响添加到上面公式中得到最终 Z 方向的世界坐标表达式:

上面的表达式是 Z 方向上的世界坐标，同理也可以求得 X 和 Y 方向的表达式。

RectTransform 世界坐标最终表达式如下:

下面使用上面的公式来计算 Canvas 下 Button 的世界坐标。Camera 世界坐标为 (0, 0, 0)、FOV 为 90，Canvas 设置 Plane Distance 100，屏幕分辨率为 (750 x 1334) 像素，Button 的 anchoredPosition(localPosition) 为 (0, 0, 100)，根据公式计算得到 Button 的世界坐标为 (0.0, 0.0, 115.0)。

为了验证这个结果的准确性，使用 RectTransformUtility 类的 ScreenPointToWorldPointInRectangle 方法根据同样的参数再来计算，代码如下:

1
2
3
4
5
6

RectTransformUtility.ScreenPointToWorldPointInRectangle(
    button.GetComponent<RectTransform>(),
    new Vector2(Screen.width / 2, Screen.height / 2),
    Camera.main,
    out Vector3 worldPoint
);

上面输出结果同样为 (0.0, 0.0, 115.0)。

在 Unity 的底层实现中，对于上面的从屏幕空间到世界空间的坐标转换，计算原理也是类似。

前言

在 Projects Settings - Time 设置中，有一个和 Fixed Timestep 并列的设置项 Maximum Allowed Timestep；当游戏中大量运用物理计算时候，这个设置项可能就会引起你的注意。

探讨

Maximum Allowed Timestep 作用

在游戏帧率很低的情况下这个值用来限制最坏的情况发生，同时它将物理模块的执行时间限定在设定值之中。

上面描述中有两个关键点，在弄清楚这两个关键点之前需要先深入了解一下关于物理模块(以 FixedUpdate 方法为例)在 MonoBehaviour 生命流水线中「占据」的阶段。

Physics 阶段

物理模块在整个 MonoBehaviour 生命周期中位于 Start 之后、输入事件检测之前；模块由 FixedUpdate、Animation update 和物理引擎计算组成。在每一帧中物理模块执行次数由设置的 Maximum Allowed Timestep 以及实际帧率决定。

下图是物理模块在整个 MonoBehaviour 生命周期中的位置:

从上图中可以看出，在帧主循环基础上 Physics 阶段还拥有一个自循环。

Unity 被设计为单线程，因此在每一帧中 Physics 阶段自循环一定有跳出该自循环的条件，这样才能够继续当前帧中的其他操作(如检测输入事件、渲染等)。那么这个条件是什么呢？下面从 FixedUpdate、Update 和 LateUpdate 三个方法来看看分析。

首先使用代码设置游戏帧率为 50FPS，其余设置默认。观察各个「Update」方法打印的日志，如下:

1
2

QualitySettings.vSyncCount = 0;
Application.targetFrameRate = 50;

从上图日志可以看出运行稳定时每帧间隔为 20ms 左右，FixedUpdate 方法基本都会在 LateUpdate 和 Update 方法之间执行一次。

接着讲游戏帧率修改为 10FPS，继续查看日志，如下图:

可以看出运行稳定时每帧间隔变成了 100ms 左右，FixedUpdate 方法此时会在 LateUpdate 和 Update 方法之间执行 5 次左右。后面再修改帧率为其它值，游戏运行稳定时 FixedUpdate 方法调用顺序和次数都呈现一个规律:

总是在 LateUpdate 和 Update 方法之间执行大约 $\frac{Time.deltaTime}{Fixed Timestep}$ 次。

上面提到了 Fixed Timestep，它是一个独立于帧率的用来指示物理模块执行的一个常量。通过这个值可以独立于帧率来驱动物理模拟，从而保证了不同帧率下物理模块计算的一致性。现在我们大概知道了 Physics 阶段的自循环大概是怎么实现的了，简单的模拟伪代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Stopwatch _stopwatch = new Stopwatch();

float _physicsTime = .0f;
float _fixedTimeStep = 0.02f;

_stopwatch.Start();
while(Running())
{
    float elapsedSeconds = _stopwatch.ElapsedMilliseconds / 1000.0f;
    while(_physicsTime < elapsedSeconds)
    {
        _physicsTime += _fixedTimeStep;
        DoPhysics();
    }

    DoInput();
    DoUpdate();
}

就像 MonoBehaviour 生命周期图中描述的那样，物理模块通过一个自循环来进行物理香相关计算，通过 Fixed Timestep 和当前帧间隔的时间来控制自循环次数。FixedUpdate 方法中的 Time.fixedDeltaTime 和 Time.deltaTime 的值也是 Fixed Timestep 设置的值。

下面再来看看最文章开始提到的两个关键点。

“最坏”情况是如何发生的？

通过上面对 Physics 阶段介绍知道，Unity 物理模块在主线程中也是和当前帧率有关联的。当帧率很低时，物理模块循环次数会变多，若此时每次物理模块计算量也很繁重，就会导致整个物理模块循环非常耗时，进而再次降低帧率。

Maximum Allowed Timestep 如何将物理模块的执行时间限定在设定值之中?

继续保持游戏帧率为 10FPS，对 Time 进行如下设置:

运行观察各个「Update」打印的日志情况，如下:

此时真实帧间隔 100ms 左右，Time.deltaTime 也和真实帧间隔几乎保持相同；FixedUpdate 方法执行顺序以及次数依旧满足之前伪代码的实现。接着将 Maximum Allowed Timestep 设置为 0.06s，再次运行观察日志:

可以看出设置了 Maximum Allowed Timestep 为 0.06s 之后，真实帧间隔依旧是 100ms 左右，但是 Time.deltaTime 固定在了 60ms，并且 FixedUpdate 方法执行次数变成了三次。这和上面伪代码的模拟好像有点出入。

再次将 Maximum Allowed Timestep 设置为 0.04s，运行后 Time.deltaTime 固定在 40ms，FixedUpdate 方法执行次数变成了两次。出现这些结果并不意外，因为此时正是 Maximum Allowed Timestep 设置的值在起作用。

在测试中帧率设置为 10FPS(每帧的时间间隔为 100ms)时，帧间隔时间大于设置的 Maximum Allowed Timestep 值。此时系统认为游戏帧率过低，如果继续使用当前帧间隔时间来自循环物理模块，假如此时每循环一次物理模块计算也很耗时，这必然会导致帧率进一步降低，“最坏”情况就发生了；因此通过 Maximum Allowed Timestep 来限制物理模块自循环次数，当真实帧间隔时间大于这个值时，将自循环次数降到大约 $\frac{Maximum Allowed Timestep}{Fixed Timestep}$ 次。这也就是 FixedUpdate 方法执行次数和上面伪代码的模拟有出入的原因。

所以，将 Maximum Allowed Timestep 控制也加入到上面模拟伪代码中:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

Stopwatch _stopwatch = new Stopwatch();

float _physicsTime = .0f;
float _fixedTimeStep = 0.02f;
float _maxAllowedTimestep = 0.06f;
int _maxAllowedPhysicsLoopCount = _maxAllowedTimestep / _fixedTimeStep;

_stopwatch.Start();
while(Running())
{
    int physicsLoopCount = 0;
    float elapsedSeconds = _stopwatch.ElapsedMilliseconds / 1000.0f;
    while(_physicsTime < elapsedSeconds && physicsLoopCount < _maxAllowedPhysicsLoopCount)
    {
        _physicsTime += _fixedTimeStep;
    physicsLoopCount++;
        DoPhysics();
    }

    // update frame delta time
    Time.deltaTime = Mathf.Min(Time.deltaTime, _maxAllowedTimestep);

    DoInput();
    DoUpdate();
}

上面的代码加入了 Maximum Allowed Timestep 控制，从而能够在帧率较低时使用它设置的值来控制物理模块的自循环次数，这样物理模块计算就会慢下来(等待渲染进度赶上)。当物理模块计算也比较耗时的时候，“最坏情况”也被削弱。

上面代码中间还有一行用来更新 Time.deltaTime，当帧间隔时间大于 Maximum Allowed Timestep 设置的值时，Time.deltaTime 被设置为 Maximum Allowed Timestep 的值，因此就出现了 Update 方法中的 Time.deltaTime 固定值的情况。

前言

Scroll Rect 也是常用 Unity UI 之一。当需要滚动显示大量内容时 Scroll Rect 组件就能实现滚动效果；若需要有滚动条类似的拖动滚动，Scroll Rect 配合 Scrollbar 就可以简单实现拖动滚动。

从一个问题说起

使用 Scroll Rect 时最典型的一个问题就是滚动嵌套，当 Scrll Rect 需要滚动的内容也是一个可滚动的 UI 元素，那么就有可能发生一些不愿看到的结果。

结合这个问题，下面将深入实现 Scroll Rect 内容滚动相关组件的源码，来剖析具体工作原理。

首先来看看 ScrollRect 组件。

回到 ScrollRect 类

ScrollRect 类继承自 UIBehaviour，因此它具有 Unity 完整的生命周期；同时还实现了很多接口，例如 ILayoutGroup 等，后面会依次分析每个实现接口的意义。下面首先来看看 ScrollRect 类中一些比较重要的成员变量。

ScrollRect 类的成员属性

对于 Scrollbar 后面会详细介绍，这里当 Scroll Rect 中使用时，有两个属性可以在 ScrollRect 组件设置面板调整:

• m_XXScrollbarVisibility 代表 Scrollbar 的可见性，它有三种模式:

  • Permanent - 永远显示 Scrollbar；

  • AutoHide - 当 Scroll Rect 不需要滚动(比如 Viewport 尺寸比 Content 的要大)时自动隐藏 Scrollbar，这种模式不会更新 Viewport 尺寸；

  • AutoHideAndExpandViewport - 当 Scroll Rect 不需要滚动(比如 Viewport 尺寸比 Content 的要大)时自动隐藏 Scrollbar，这种模式会更新 Viewport 尺寸，同时这种模式下 Scrollbar 以及 Viewport 的 RectTransform 的参数由 ScrollRect 自动计算。

• m_XXScrollbarSpacing 表示 Scrollbar 和 Viewport 之间的空间大小。

另外 ScrollRect 类中还有一个 ScrollRectEvent(UnityEvent) 类型的成员变量 m_OnValueChanged，通过它可以监听 Scroll Rect 滚动带来的位置更新。

ScrollRect 类实现了 IInitializePotentialDragHandler、IBeginDragHandler、IEndDragHandler、IDragHandler、IScrollHandler、ICanvasElement、ILayoutElement 和 ILayoutGroup 这些接口，下面就从这些接口着手分析其重要的方法。

Scroll Rect 的布局

ICanvasElement 接口和 Rebuild 方法

实现这个接口 Scroll Rect 能够接收到 Canvas 渲染更新时 Layout 重建的通知(具体是通过 CanvasUpdateRegistry 类的 PerformUpdate 方法来执行)以实现重新构建 Layout，ICanvasElement 接口中最重要的方法是 Rebuild，下面看看 ScrollRect 中对于这个方法的具体实现:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public virtual void Rebuild(CanvasUpdate executing)
{
    if (executing == CanvasUpdate.Prelayout)
    {
        UpdateCachedData();
    }
    if (executing == CanvasUpdate.PostLayout)
    {
        UpdateBounds();
        UpdateScrollbars(Vector2.zero);
        UpdatePrevData();
        m_HasRebuiltLayout = true;
    }
}

可以看出在 ScrollRect 类自身实现的 Rebuild 方法中仅仅会对 Layout 前(CanvasUpdate.Prelayout)以及 Layout 后(CanvasUpdate.PostLayout)的重建回调做处理。

对于 Layout 之前的通知仅仅是调用了自身类的 UpdateCachedData 方法，这个方法缓存了以后计算会用到的相关数据，比如水平滚动条所在的 RectTransform 成员变量 m_HorizontalScrollbarRect、在隐藏垂直方向 Scrollbar 后是否可以将 Viewport 在水平方向上展开控制变量 m_HSliderExpand 等，代码如下:

1
2
3
4
5
6
7
8
9
10
11

void UpdateCachedData()
{
    m_HorizontalScrollbarRect = m_HorizontalScrollbar == null ? null : m_HorizontalScrollbar.transform as RectTransform;

    bool viewIsChild = (viewRect.parent == transform);
    bool hScrollbarIsChild = (!m_HorizontalScrollbarRect || m_HorizontalScrollbarRect.parent == transform);
    bool allAreChildren = (viewIsChild && hScrollbarIsChild && vScrollbarIsChild);

    m_HSliderExpand = allAreChildren && m_HorizontalScrollbarRect && horizontalScrollbarVisibility == ScrollbarVisibility.AutoHideAndExpandViewport;
    m_HSliderHeight = (m_HorizontalScrollbarRect == null ? 0 : m_HorizontalScrollbarRect.rect.height);
}

其中对于 m_HSliderExpand 和 mVSliderExpand 的计算比较重要，这两个变量只有在为 Scroll Rect 设置了对应的 Scrollbar 并且 Scrollbar 的可见模式为 AutoHideAndExpandViewport 以及 Viewport 和 Scrollbar 都是 Scroll Rect 子元素时才被设置为 true，后面的 Viewport 展开计算中会经常用到这两个变量。

对于收到 Layout 完成之后的通知，会依次调用下面几个方法来更新对应的数据:

1. 首先调用 UpdateBounds 方法更新当前 Viewport 以及 Content 的 Bounds。方法中比较重要的有两部分，第一部分是调用 AdjustBounds 方法保证 Content 的 Bounds 不小于 Viewport 的 Bounds，只有在这个前提下 Scroll Rect 才能正确的滚动；另一点就是在内容滚动方式是 MovementType.Clamped 时，调整 Content 的 Bounds 的中心点位置在合适的位置(比如保证其 bottom 不高于 Viewport 的 bottom)，这样就能达到在 MovementType.Clamped 模式时 Content 滚动到 Viewport 边界就无法在滚动的要求。部分代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

protected void UpdateBounds()
{
    m_ViewBounds = new Bounds(viewRect.rect.center, viewRect.rect.size);
    m_ContentBounds = GetBounds();

    // Make sure content bounds are at least as large as view by adding padding if not.
    AdjustBounds(ref m_ViewBounds, ref contentPivot, ref contentSize, ref contentPos);
    m_ContentBounds.size = contentSize;
    m_ContentBounds.center = contentPos;

    if (movementType == MovementType.Clamped)
    {
        Vector2 delta = Vector2.zero;
        if (m_ViewBounds.max.x > m_ContentBounds.max.x)
        {
            delta.x = Math.Min(m_ViewBounds.min.x - m_ContentBounds.min.x, m_ViewBounds.max.x - m_ContentBounds.max.x);
        }
        // other code ...
        // Calculate delta y ...

        if (delta.sqrMagnitude > float.Epsilon)
        {
            contentPos = m_Content.anchoredPosition + delta;
            // other code ...
            AdjustBounds(ref m_ViewBounds, ref contentPivot, ref contentSize, ref contentPos);
        }
    }
}

2. 在收到 Layout 完成的通知调用 UpdateBounds 方法之后，紧接着就是执行 UpdateScrollbars 方法初始化 Scrollbar，包括其 handle bar 的长度(Viewport size / Content size)，以及 Scrollbar 的初始值(通过 horizontalNormalizedPosition 或 verticalNormalizedPosition 方法得到)。具体来看看 horizontalNormalizedPosition 方法代码:

1
2
3
4
5
6
7
8
9

get
{
    UpdateBounds();
    if ((m_ContentBounds.size.x <= m_ViewBounds.size.x) || Mathf.Approximately(m_ContentBounds.size.x, m_ViewBounds.size.x))
        return (m_ViewBounds.min.x > m_ContentBounds.min.x) ? 1 : 0;

    // Calculate the scrollbar value ...
    return (m_ViewBounds.min.x - m_ContentBounds.min.x) / (m_ContentBounds.size.x - m_ViewBounds.size.x);
}

可以看出当 Content Bounds 尺寸小于 Viewport Bounds 尺寸时，Scrollbar 的值为 1；否则相等时 Scrollbar 的值为 0；否则大于时会根据两个 Bounds 的 min 和 size 两个参数进行计算得到。

3. 最后执行的是 UpdatePrevData 方法，这个方法主要是在接下来要更新 ScrollRect 时缓存 ScrollRect 的一些数据，后面计算会用到。

看完了 ScrollRect 自身实现的 Rebuild 方法，是不是觉得有点懵? 收到 Layout 重新构建通知为什么只对 Layout 前(CanvasUpdate.Prelayout)以及 Layout 后(CanvasUpdate.PostLayout)的重建回调做处理，最重要的 Layout 过程(CanvasUpdate.Layout)回调不处理怎么进行布局了? 没错，ScrollRect 类自身实现的 Rebuild 方法确实并未直接处理 Layout 过程的回调，真正的布局是在 LayoutRebuilder 辅助类中完成的，下面看看详细分析。

我们知道通过 LayoutRebuilder 类来进行布局，首先需要将自身 RectTransdorm 注册到 LayoutRebuilder 中，然后 LayoutRebuilder 通过调用自身的 Initialize 方法内将目标 RectTransform 与自身实例绑定在一起，最后 LayoutRebuilder 会调用 CanvasUpdateRegistry 类的 TryRegisterCanvasElementForLayoutRebuild 方法将自身实例注册到 CanvasUpdateRegistry 类中(LayoutRebuilder 实现了 ICanvasElement 接口)，这样 Canvas 渲染更新时发出 Layout 重建的通知时，LayoutRebuilder 类的 Rebuild 方法会被回调，这里面才会对其绑定的 RectTransform 做真正的布局操作。

所以 ScrollRect 通过 LayoutRebuilder 辅助类进行布局，首先要做的就是将自身注册到 LayoutRebuilder 中，代码如下:

1

LayoutRebuilder.MarkLayoutForRebuild(rectTransform);

这行代码直接或间接的在 ScrollRect 类中被多次调用，比如改变 Viewport、Scrollbar 等操作以及执行 OnEnable 等方法。

OnEnable 和 OnDisable 方法

ScrollRect 类继承自 UIBehaviour，所以这两个方法都是 Unity 生命周期回调方法。首先来看看 OnEnable，代码如下:

1
2
3
4
5
6
7
8
9
10

protected override void OnEnable()
{
    if (m_HorizontalScrollbar)
        m_HorizontalScrollbar.onValueChanged.AddListener(SetHorizontalNormalizedPosition);
    if (m_VerticalScrollbar)
        m_VerticalScrollbar.onValueChanged.AddListener(SetVerticalNormalizedPosition);

    CanvasUpdateRegistry.RegisterCanvasElementForLayoutRebuild(this);
    SetDirty();
}

代码很简单，首先添加了 Scrollbar 位置改变时的回调，以便能够更新 Content 位置；然后向 CanvasUpdateRegistry 中注册了自身以能够收到 Layout 重建前和重建完成后的回调；最后调用了 SetDirty 方法注册自身或者父级 LayoutGroup 到 LayoutRebuilder 中，以便能够真正的布局当前 ScrollRect。

再来看看 OnDisable 方法，它所做的事情基本上和 OnEnable 相反，比如从 CanvasUpdateRegistry 中反注册自己，从 Scrollbar 位置改变时的执行事件中移除对自身的回调等等。

ILayoutElement 接口

ScrollRect 类实现 ILayoutElement 能够保证其所在的 UI 元素能够在 Auto Layout 系统下自动适配和布局，详见《Unity UI - 布局(一)》，因此 Scroll Rect 能够被 ILayoutController 控制布局。值得注意的一点是在实现的 ILayoutElement 接口方法中，对于 minWidth、preferredWidth 这些数值方法返回值都是 -1，因此在某些 ILayoutController 控制布局时若是单纯使用这些数值方法作为其对应的尺寸大小，特别需要注意可能会出现的一些问题。

ILayoutGroup 接口和 ScrollRect 类对其中的方法具体实现

ScrollRect 类同时还实现了 ILayoutGroup 接口，因此除了自身能够被 ILayoutController 控制布局，它还能控制子元素的布局；这里主要涉及到 SetLayoutHorizontal 和 SetLayoutVertical 方法。

1. SetLayoutHorizontal 方法主要计算 Viewport 的尺寸大小以及位置、Viewport 和 Content 的 Bounds 数据等。

这个方法中的代码比较长，首先第一步判断 m_HSliderExpand 或 m_VSliderExpand 的计算值(由 UpdateCachedData 方法中计算，表示是否支持在水平或垂直方向上允许 Viewport 扩展增加 Scrollbar 部分的尺寸大小)，如果为 true 那么首先就让 Viewport 尝试撑满父元素，然后来检测 Content 是否能够充满整个 Viewport，代码如下:

1
2
3
4
5
6
7
8
9
10
11

if (m_HSliderExpand || m_VSliderExpand)
{
    viewRect.anchorMin = Vector2.zero;
    viewRect.anchorMax = Vector2.one;
    viewRect.sizeDelta = Vector2.zero;
    viewRect.anchoredPosition = Vector2.zero;

    LayoutRebuilder.ForceRebuildLayoutImmediate(content);
    m_ViewBounds = new Bounds(viewRect.rect.center, viewRect.rect.size);
    m_ContentBounds = GetBounds();
}

这种情况下 Viewport 相关在 Unity 编辑器面板会出现如下提示:

从上图可以看出这时候 Viewport 的位置以及尺寸大小是由父节点的 ScrollRect 计算的，不可以手动修改。

计算完 Viewport 的布局相关信息，就会调用 LayoutRebuilder 类的 ForceRebuildLayoutImmediate 方法重新计算 Content 的布局信息看它是否能在没有 Scrollbar 的情况下充满 Viewport。

第二步就根据上一步得到的信息以及操作，判断 Content 充满 Viewport 的情况，首先检测的是垂直方向，代码如下:

1
2
3
4
5
6
7
8

if (m_VSliderExpand && vScrollingNeeded)
{
    viewRect.sizeDelta = new Vector2(-(m_VSliderWidth + m_VerticalScrollbarSpacing), viewRect.sizeDelta.y);

    LayoutRebuilder.ForceRebuildLayoutImmediate(content);
    m_ViewBounds = new Bounds(viewRect.rect.center, viewRect.rect.size);
    m_ContentBounds = GetBounds();
}

代码中，若垂直方向 Content 尺寸要比 Viewport 大(说明垂直方向需要滚动)，那么会给垂直方向的 Scrollbar 预留空间并缩小 Viewport 水平方向的尺寸大小，紧接着再次调用 LayoutRebuilder 类的 ForceRebuildLayoutImmediate 方法重新计算 Content 的布局信息。

第三步和第二步类似，计算水平方向的 Scrollbar 是否需要预留空间以及 Viewport 在垂直方向上是否需要缩小。

最后一步再次检测垂直方向 Scrollbar 没有生效的情况，若未生效就给垂直方向的 Scrollbar 预留空间并缩小 Viewport 水平方向的尺寸大小，代码如下:

1
2
3
4

if (m_VSliderExpand && vScrollingNeeded && viewRect.sizeDelta.x == 0 && viewRect.sizeDelta.y < 0)
{
    viewRect.sizeDelta = new Vector2(-(m_VSliderWidth + m_VerticalScrollbarSpacing), viewRect.sizeDelta.y);
}

2. 继续来分析 SetLayoutVertical 方法，这个方法是紧接着 SetLayoutHorizontal 方法被调用的。通过上面的分析我们知道 SetLayoutHorizontal 方法已经计算好了 Viewport 的布局信息、Viewport 和 Content 的 Bounds 数据等，也确定了是否需要启用 Scrollbar；在 SetLayoutVertical 方法中，主要的工作就是更新 Scrollbar 布局，所以它里面的代码也很简单，最重要的就是调用 ScrollRect 类自身的 UpdateScrollbarLayout 方法，这里我们直接分析 UpdateScrollbarLayout 方法，其代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

void UpdateScrollbarLayout()
{
    if (m_VSliderExpand && m_HorizontalScrollbar)
    {
        m_HorizontalScrollbarRect.anchorMin = new Vector2(0, m_HorizontalScrollbarRect.anchorMin.y);
        m_HorizontalScrollbarRect.anchorMax = new Vector2(1, m_HorizontalScrollbarRect.anchorMax.y);
        m_HorizontalScrollbarRect.anchoredPosition = new Vector2(0, m_HorizontalScrollbarRect.anchoredPosition.y);
        if (vScrollingNeeded)
            m_HorizontalScrollbarRect.sizeDelta = new Vector2(-(m_VSliderWidth + m_VerticalScrollbarSpacing), m_HorizontalScrollbarRect.sizeDelta.y);
        else
            m_HorizontalScrollbarRect.sizeDelta = new Vector2(0, m_HorizontalScrollbarRect.sizeDelta.y);
    }

    // Vertical scroll bar update code ...
}

上部分的代码中，若垂直方向上 Viewport 是可以展开的且设置了水平方向的 Scrollbar，则布局水平方向 Scrollbar。将其 anchorMin.x 设置为 0(位于 Scroll Rect 最左边)，anchorMax.x 设置为 1(位于 Scroll Rect 最右边)，anchoredPosition.x 设置为 0(Scrollbar 支点的水平坐标位于 Scroll Rect 中间)；若垂直方向需要 Scrollbar，则将水平方向的 Scrollbar 宽度设置为 Scroll Rect 宽度减去垂直方向滚动条需要的空间大小，否则直接将水平方向的 Scrollbar 宽度设置为 Scroll Rect 宽度。

计算设置垂直方向 Scrollbar 布局过程和上面类似，这两个过程 Scrollbar 的计算也是由 ScrollRect 控制，因此部分属性也不能在 Unity 编辑器中手动修改，如下图:

在 SetLayoutVertical 方法中计算设置完成 Scrollbar 布局后，还会更新一下 Viewport 和 Content 的 Bounds 信息。

Scroll Rect 如何滚动内容 - Event System 事件接口

前面看完了布局相关的接口方法，再来看看 ScrollRect 的滚动相关的分析，ScrollRect 类实现了一些列 Event System 中预定义的事件接口，下面就来一一来分析每个接口。

IInitializePotentialDragHandler 接口

实现这个接口，能够让 Event System 在分发「找到拖拽初始化对象」事件时，将自身所在 UI 元素作为事件待分发对象之一，如果确定该事件分发对象是自身，那么 ScrollRect 类中所实现的 OnInitializePotentialDrag 方法将会被回调。

ScrollRect 类对这个方法具体实现也很简单，仅简单地将拖拽速度变量 m_Velocity 初始化为 0。

IBeginDragHandler 接口

当拖拽对象开始发生拖拽时，实现的接口中的 OnBeginDrag 方法会被调用。ScrollRect 中 OnBeginDrag 方法部分代码如下:

1
2
3
4
5
6
7
8
9

public virtual void OnBeginDrag(PointerEventData eventData)
{
    UpdateBounds();

    m_PointerStartLocalCursor = Vector2.zero;
    RectTransformUtility.ScreenPointToLocalPointInRectangle(viewRect, eventData.position, eventData.pressEventCamera, out m_PointerStartLocalCursor);
    m_ContentStartPosition = m_Content.anchoredPosition;
    m_Dragging = true;
}

从上面的代码中可以看出，它首先调用了 ScrollRect 类的 UpdateBounds 方法更新 Viewport 以及 Content 的 Bounds；紧接着初始化了 m_PointerStartLocalCursor 和 m_ContentStartPosition 相关变量，并将 m_Dragging 设置为 true。

IEndDragHandler 接口

当拖拽对象开始拖拽结束时，实现的这个接口中的 OnEndDrag 方法会被调用，对于 ScrollRect 中的这个方法仅仅将 m_Dragging 设置为了 false。

IDragHandler 接口

当拖拽对象发生拖拽时，实现的这个接口中的 OnDrag 方法会被调用，ScrollRect 中具体的 OnDrag 方法代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public virtual void OnDrag(PointerEventData eventData)
{
    Vector2 localCursor;
    if (!RectTransformUtility.ScreenPointToLocalPointInRectangle(viewRect, eventData.position, eventData.pressEventCamera, out localCursor))
        return;

    UpdateBounds();

    var pointerDelta = localCursor - m_PointerStartLocalCursor;
    Vector2 position = m_ContentStartPosition + pointerDelta;
    Vector2 offset = CalculateOffset(position - m_Content.anchoredPosition);
    position += offset;
    if (m_MovementType == MovementType.Elastic)
    {
        if (offset.x != 0)
            position.x = position.x - RubberDelta(offset.x, m_ViewBounds.size.x);
        if (offset.y != 0)
            position.y = position.y - RubberDelta(offset.y, m_ViewBounds.size.y);
    }
    SetContentAnchoredPosition(position);
}

拖拽过程中，通过改变 Content 的位置从而实现了 Content 的滚动。下面来看看整个过程:

1. 首先调用 RectTransformUtility 类的静态方法 ScreenPointToLocalPointInRectangle 将当前屏幕上的坐标转换到 UI 元素的坐标系统下，并缓存至 localCursor 临时变量中；

2. 计算开始拖拽和当前拖拽回调发生的偏移量 pointerDelta，同时将这个偏移量累加到 Content 起始位置 m_ContentStartPosition 中得到新的 position；

3. 将上一步得到的新的 position 减去此时 Content 的位置(此次更新前的位置) anchoredPosition 得到的值作为参数，调用 ScrollRect 类本身的 CalculateOffset 方法来计算这次拖拽回调 Content 的「补偿偏移」，其中计算「补偿偏移」大致代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

internal static Vector2 InternalCalculateOffset(ref Bounds viewBounds, ref Bounds contentBounds, bool horizontal, bool vertical, MovementType movementType, ref Vector2 delta)
{
    Vector2 offset = Vector2.zero;
    if (movementType == MovementType.Unrestricted)
        return offset;

    Vector2 min = contentBounds.min;
    Vector2 max = contentBounds.max;
    if (horizontal)
    {
        min.x += delta.x;
        max.x += delta.x;

        float maxOffset = viewBounds.max.x - max.x;
        float minOffset = viewBounds.min.x - min.x;
        if (minOffset < -0.001f)
            offset.x = minOffset;
        else if (maxOffset > 0.001f)
            offset.x = maxOffset;
    }
    // Calculate vertical offset code ...

    return offset;
}

若当前 Scroll Rect 滚动模式为 Unrestricted 「补偿偏移」为 0，也就是说对于无限滚动模式 Content 的位置根据滚动的距离决定不需要任何补偿调整。若滚动模式是另外两种有限滚动模式(限制在 Viewport 内)，则会为此次滚动距离计算「补偿偏移」，水平方向「补偿偏移」计算过程如下: 首先将 Content Bounds 水平方向上的最小值和最大值分别加上此次应该累加的偏移量得到临时的 min 和 max；然后用 Viewport Bounds 水平方向上的最小值和最大值分别与 min 和 max 相减，得到“假设”移动 Content 后 Viewport Bounds 和 Content Bounds 水平方向上的两个差值 minOffset 和 maxOffset；若最左边得到 min 差值小于 0，说明 Content 水平方向上左边界已经超过了 Viewport 的左边界，此时对于 Content 在水平方向上的移动就应该在上一步得到的位置 position 基础上加上这个 minOffset(这个值为负数，即减去这段 minOffset 的距离)，来让 Content 水平方向上左边界不超过 Viewport 的左边界，对于又边界也是同样的计算过程。具体看下图会更清楚:

这就是计算水平方向上「补偿偏移」的过程，对于垂直方向也是类似的计算方式，得到「补偿偏移」后将这个偏移累加到第二步计算的位置上。

4. 接下来就是对于滚动模式为 Elastic 时的特殊处理，来实现拖拽过程中的弹性效果，代码如下:

1
2
3
4
5
6
7

if (m_MovementType == MovementType.Elastic)
{
    if (offset.x != 0)
        position.x = position.x - RubberDelta(offset.x, m_ViewBounds.size.x);
    if (offset.y != 0)
        position.y = position.y - RubberDelta(offset.y, m_ViewBounds.size.y);
}

主要就是调用了 ScrollRect 类方法 RubberDelta 对即将设置给 Content 的位置 position 进行了处理；RubberDelta 方法模拟了一条弹性曲线，使用「补偿偏移」offset 以及 Viewport Bounds 大小进行弹性位移的计算。

5. 最后一步调用 SetContentAnchoredPosition 方法为 Content 设置新位置 position。

IScrollHandler 接口

当鼠标滚轮滚动时，实现了这个接口中的 OnScroll 方法会被回调，ScrollRect 中具体的 OnScroll 方法代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

public virtual void OnScroll(PointerEventData data)
{
    // other code ...
    Vector2 delta = data.scrollDelta;
    delta.y *= -1;
    if (vertical && !horizontal)
    {
        if (Mathf.Abs(delta.x) > Mathf.Abs(delta.y))
            delta.y = delta.x;
        delta.x = 0;
    }
    // Calculate horizontal delta code ...

    if (data.IsScrolling())
        m_Scrolling = true;
    Vector2 position = m_Content.anchoredPosition;
    position += delta * m_ScrollSensitivity;
    if (m_MovementType == MovementType.Clamped)
        position += CalculateOffset(position - m_Content.anchoredPosition);

    SetContentAnchoredPosition(position);
    UpdateBounds();
}

上面计算过程也很简单，根据鼠标滚轮滚动的值来滚动 Content。

1. 如果开启了垂直方向滚动且关闭了水平方向的滚动，那么使用滚轮较大方向上的那个值作为最终垂直方向滚动的差值，水平方向上的滚动差值设置为 0，然后使用差值乘以滚动灵敏度 m_ScrollSensitivity 得到最终的滚动距离差值；

2. 如果滚动模式为 Clamped，也是首先计算「补偿偏移」使得 Content 边界不越界；这里和 OnDrag 方法中处理有点不同，仅仅在滚动模式为 Clamped 下加了这个保护而 Elastic 模式没有，原因在于在 OnDrag 方法中，虽然在 Elastic 模式也保证了 Content 边界不越界，但是后面会紧接着调用 RubberDelta 方法来模拟弹性效果，使得 Content 依旧会“假”越界，而在 OnScroll 方法中边界未做保护，就会导致滚轮滚动的距离实际就会设置为 Content 的距离，但是真正的弹性效果会在 LateUpdate 方法中实现(OnEndDrag 以及 OnScroll 的回弹效果都会在 LateUpdate 方法中处理，后面会分析到)。

3. 最后调用 SetContentAnchoredPosition 设置 Content 的新位置，并更新 Viewport 以及 Content 的 Bounds。

LateUpdate 方法

这个方法是 Unity 生命周期中的回调方法之一，在所有的 Update 方法执行完成之后该方法会被回调执行。ScrollRect 类重写了这个方法，主要用来做以下几件事情:

1. 实现在滚轮滚动时 Content 边界越界时可能会有的弹性拉伸效果、Content 的弹性回弹效果以及拖拽结束后的惯性滚动效果，代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

float deltaTime = Time.unscaledDeltaTime;
Vector2 offset = CalculateOffset(Vector2.zero);
if (!m_Dragging && (offset != Vector2.zero || m_Velocity != Vector2.zero))
{
    Vector2 position = m_Content.anchoredPosition;
    for (int axis = 0; axis < 2; axis++)
    {
        if (m_MovementType == MovementType.Elastic && offset[axis] != 0)
        {
            float speed = m_Velocity[axis];
            float smoothTime = m_Elasticity;
            if (m_Scrolling)
                smoothTime *= 3.0f;
            position[axis] = Mathf.SmoothDamp(m_Content.anchoredPosition[axis], m_Content.anchoredPosition[axis] + offset[axis], ref speed, smoothTime, Mathf.Infinity, deltaTime);
            if (Mathf.Abs(speed) < 1)
                speed = 0;
            m_Velocity[axis] = speed;
        }
        else if (m_Inertia)
        {
            m_Velocity[axis] *= Mathf.Pow(m_DecelerationRate, deltaTime);
            if (Mathf.Abs(m_Velocity[axis]) < 1)
                m_Velocity[axis] = 0;
            position[axis] += m_Velocity[axis] * deltaTime;
        }
        else
            m_Velocity[axis] = 0;
    }

    if (m_MovementType == MovementType.Clamped)
    {
        offset = CalculateOffset(position - m_Content.anchoredPosition);
        position += offset;
    }
    SetContentAnchoredPosition(position);
}

从上面的代码中可以看出，只有在 m_Dragging 为 false 时，这段代码才有可能被执行，也就是说只有当滚轮滚动操作时或者是拖拽结束后才有可能有滚轮滚动的弹性拉伸效果或回弹效果以及惯性结束停止滚动效果。

最开始调用 CalculateOffset 方法计算「补偿偏移」，注意这里传入的参数为 0，也就是仅用当前 Viewport 和 Content 的 Bounds 数据来计算而不需要累加偏移量。

如果滚动模式是 Elastic 且当前求得「补偿偏移」大于 0 时，那么计算弹性效果。首先来看看滚轮滚动使得 Content 到达边界处时，此时若滚轮继续处于滚动状态，那么会有弹性拉伸效果产生。通过之前的分析我们知道，滚轮滚动回调的 OnScroll 方法中，如果滚动模式为 Elastic 那么 Content 的位置是根据滚动计算得到的位移确定的(并未像 Clamped 模式一样做边界保护，有可能“越界”)，当发生“越界”之后来到当前的代码中 Content 的位置有会被以弹性拉伸的方式来纠正，具体就是调用 Mathf 类的 SmoothDamp 方法传入当前速度 m_Velocity、动画时间 smoothTime 等参数尝试让 Content 以阻尼效果的方式回到边界处(若是正处于 Scrolling 状态，这里的时间动画 smoothTime 会在弹性系数 m_Elasticity 基础上扩大三倍)，连续这样的过程就让滚轮滚动也能使 Content 产生了弹性拉伸的效果。再来看看拖拽结束或者是滚轮滚动结束让 Content 产生的回弹的情况，和刚刚说的滚轮拉伸效果一样，只不过这里的回弹动画时间 smoothTime 就是弹性系数 m_Elasticity。

滚动模式不是 Elastic 或者当前求得「补偿偏移」为 0 时，表示不需要弹性滚动，此时根据减速速率来计算停止滚动(带有惯性)。

否则如果既不需要弹性滚动也未设置惯性停止滚动，则将滚动速度 m_Velocity 设置为 0。

计算得到 Content 的新位置之后，接着对滚动模式为 Clamped 时限制了滚动边界，最后调用 SetContentAnchoredPosition 改变 Content 的位置。

2. 拖拽过程中，如果设置了需要停止滚动后以惯性停止，则会更新滚动速度，代码如下:

1
2
3
4
5

if (m_Dragging && m_Inertia)
{
    Vector3 newVelocity = (m_Content.anchoredPosition - m_PrevPosition) / deltaTime;
    m_Velocity = Vector3.Lerp(m_Velocity, newVelocity, deltaTime * 10);
}

3. 最后在 LateUpdate 方法中所做的就是更新 Scrollbar 相关信息，代码如下:

1
2
3
4
5
6
7
8

if (m_ViewBounds != m_PrevViewBounds || m_ContentBounds != m_PrevContentBounds || m_Content.anchoredPosition != m_PrevPosition)
{
    UpdateScrollbars(offset);
    UISystemProfilerApi.AddMarker("ScrollRect.value", this);
    m_OnValueChanged.Invoke(normalizedPosition);
    UpdatePrevData();
}
UpdateScrollbarVisibility();

上面的代码中首先调用了 ScrollRect 类自身的 UpdateScrollbars 方法计算 Scrollbar 相关信息，看看这个方法的水平方向上计算代码(垂直方向也是同样的方式计算):

1
2
3
4
5
6
7
8
9
10
11
12
13

private void UpdateScrollbars(Vector2 offset)
{
    if (m_HorizontalScrollbar)
    {
        if (m_ContentBounds.size.x > 0)
            m_HorizontalScrollbar.size = Mathf.Clamp01((m_ViewBounds.size.x - Mathf.Abs(offset.x)) / m_ContentBounds.size.x);
        else
            m_HorizontalScrollbar.size = 1;

        m_HorizontalScrollbar.value = horizontalNormalizedPosition;
    }
    // Calculate vertical scroll bar ...
}

Scrollbar 的大小值由 Viewport Bounds 尺寸减去当前滚动的「补偿偏移」量除以 Content Bounds 尺寸，计算结果为在 0-1 之间，结果值越大 Scrollbar 尺寸越大(为 1 时会充满整个 Scrollbar 区域)，因此在 Elastic 这种弹性“越界”模式下，当越界后若继续在某个方向上滚动随着「补偿偏移」越来越大，会看到 Scrollbar 在这个方向上的尺寸越来越小。

计算完 Scrollbar 的大小，紧接着调用 horizontalNormalizedPosition 方法计算 Scrollbar 的位置值，代码如下:

1
2
3
4
5
6
7
8
9
10

public float horizontalNormalizedPosition
{
    get
    {
        UpdateBounds();
        if ((m_ContentBounds.size.x <= m_ViewBounds.size.x) || Mathf.Approximately(m_ContentBounds.size.x, m_ViewBounds.size.x))
            return (m_ViewBounds.min.x > m_ContentBounds.min.x) ? 1 : 0;
        return (m_ViewBounds.min.x - m_ContentBounds.min.x) / (m_ContentBounds.size.x - m_ViewBounds.size.x);
    }
}

主要就是用 Viewport Bounds 的最小值和 Content Bounds 的最小值相减，除以 Content Bounds 尺寸和 Viewport Bounds 尺寸的差值得到最终 Scrollbar 的位置值。

执行完 UpdateScrollbars 方法，m_OnValueChanged 被执行来通知所有的观察者位置更新，接着调用 UpdatePrevData 更新缓存数据；最后调用 UpdateScrollbarVisibility 更新 Scrollbar 的显示。

到这里，整个 Scroll Rect 的滚动过程就分析完了，其滚动主要监听就是靠 Event System 中一些预制事件实时计算位置来实现。使用事件监听就会遇到令人头疼的问题，比如事件被拦截导致滚动失效，这也是本文最开始提到的一个问题，下面我们将来分析这个问题的发生过程以及解决方案。

回到最开始的问题 - 解决 Scroll Rect 中滚动嵌套出现的问题

在探讨这个问题之前，先了解 Event System 中事件分发的一些重要内容:

• Event System 中，某个事件一旦被一个对象拦截消费将不会向祖先节点上冒泡传递；若这个事件对象无法消费成功，那么事件会依旧像上寻找能够消费它的对象。因此若 Scroll Rect 某个子元素消费了其滚动所需的事件(如 IDragHandler 等)，那么将导致 Scroll Rect 无法滚动；但是若这个子元素消费了非 Scroll Rect 滚动所需事件(如 IPointerDownHandler 等)，那么 Scroll Rect 依旧能够拦截滚动所需事件来实现滚动效果。

• Unity UI 中检测事件接收对象主要靠 GraphicRaycaster 类完成，但它只识别 Graphic 作为检测对象，因此一个 ScrollRect 所在对象要想接收到滚动所需的预制事件，这个对象也必须绑定 Graphic 组件，或者其子节点有绑定 Graphic 组件但是子节点并未消费这些预制事件。

如果某个需求导致 Scroll Rect 滚动所需事件被子元素拦截并消费，Scroll Rect 如何才能继续保持接收这些事件来滚动了？有以下两中解决方案:

1. 在子元素消费的特定事件中强制调用当前 ScrollRect 对应的响应事件方法，比如在子元素处理的 OnDrag 方法中调用 ScrollRect 类的 OnDrag 方法，这样能够依旧保证 Scroll Rect 的滚动效果；

2. 第二种方式依然是在子元素消费的特定事件方法中处理，只不过这里不再强制调用 ScrollRect 对应的响应事件方法，因为这样显得代码太过于耦合，这种方法中在处理完子元素的逻辑后，手动进行一次 Event System 的事件分发对象检测操作，然后将事件再次分发下去。这种方法的代码大致如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

private void PassEvent<T>(PointerEventData eventData, ExecuteEvents.EventFunction<T> function) where T : IEventSystemHandler
{
    List<RaycastResult> results = new List<RaycastResult>();
    EventSystem.current.RaycastAll(eventData, results);

    for (int i = 0; i < results.Count; i++)
    {
        if (gameObject != results[i].gameObject)
        {
            GameObject go = ExecuteEvents.ExecuteHierarchy(results[i].gameObject, eventData, function);
            if (go != null)
                return;
        }
    }
}

上面的代码能够解决嵌套滚动问题，但是有个局限性就是鼠标位置移出其 Viewport，那么 RaycastAll 将检测不到任何可接收事件的对象，因此事件也将不能再继续传递。

如果 Content 很大很大，此时的鼠标明明还在其 Rect 内，为什么 Content 也无法再次被检测为事件接收对象？回答这个问题要从 Graphic.Raycast 说起，判断一个 Graphic 是否能够作为事件接收对象除了满足最基础的条件(Active 等属性设置)外，还有另一个重要条件就是调用 Graphic 自身的 Raycast 检测要合法，这个方法检测过程大致如下: 循环遍历这个 Graphic 所在对象以及其祖先节点对象，每一次遍历过程都需要满足其对象上绑定的所有的 ICanvasRaycastFilter 接口的 IsRaycastLocationValid 方法返回 true，这有所有的遍历成功返回 true，这个 Graphic 才能作为事件检测对象之一，详细分析见《Unity Raycasters 剖析》。

所以当鼠标移出 Scroll Rect 的 Viewport 时，就算鼠标还位于其子元素的范围内也无法在检测到这几个元素作为事件接收对象的原因也就水落石出了:

• 当判断 Content 元素时，对于其自身所有组件检测通过，但是当开始检测其父节点 Viewport 时，由于绑定了 Mask 组件，Maks 组件也是一个 ICanvasRaycastFilter，并且其具体 IsRaycastLocationValid 方法直接将鼠标点是否位于自身 Rect 范围内作为返回值；上面的情况中鼠标已经移出了 Viewport，所以 Content 检测不能作为事件接收对象。

• Content 元素检测失败，对于 Viewport 元素自然直接返回失败，它甚至还没到达 Graphic Raycst 这一步就已经被淘汰(GraphicRaycaster 会提前过滤)。

• 对于 ScrollRect 所在对象，由于根本没有绑定 Graphic 组件，直接淘汰。

注意: 上面的检测中 Mask 组件具体 IsRaycastLocationValid 方法实现最终调用了 RectTransformUtility 类的 RectangleContainsScreenPoint 方法直接判断点是否在 Rect 内；而 Image 组件的具体 IsRaycastLocationValid 方法主要调用 RectTransformUtility 类的 ScreenPointToLocalPointInRectangle 来判断(文档)，这个方法会判断当前 Image 的 RectTransform 所在整个平面能否被射线检测到碰撞，因此大部分情况是返回 true。

Scroll Rect 内容遮罩 - Mask 组件登场

Mask 组件除了能够限制拖动事件响应范围，另一个更大的作用就是遮罩显示 Content 的内容，更多关于这部分的内容读者可参考《Unity 遮罩“绘制”图》

Scrollbar 简单介绍

作为 Scroll Rect 可配置的一部分，Scrollbar 可以直接响应拖动从而来控制 Scroll Rect 内容的滚动。上面分析的时候也讲到了 Scrollbar 的 value 和 size 属性，除了这两个之外它还有很多其它属性，如 direction 控制 Scrollbar 的 value 增长方向等，更多请参考Unity Manual - Scrollbar。

参考

• Unity Manual - Scroll Rect

• Unity Scripting API - Bounds

• Unity UI - 布局(一)

前言

A Mask is not a visible UI control but rather a way to modify the appearance of a control’s child elements. the parent will be visible.

Mask 是一个不可见的用于控制子元素遮罩显示的一个组件，在 Unity UI 中分别有 Mask 和 RectMask2D 两种类型的 Mask 组件实现遮罩效果；这两个组件都有各自的使用场景，下面就来分析 Unity 中是如何应用这两个组件来为一副图像“绘制”遮罩效果。

IMaskable、IMaterialModifier、IClippable 和 IClipper

在分析这两个 Mask 组件之前，先来分别认识一下 IMaskable、IMaterialModifier、IClippable 以及 IClipper 接口。

IMaskable

实现了 IMaskable 接口的组件都可以被用来实现遮罩效果，它有一个方法 RecalculateMasking 用来计算当前元素及其子元素的 Mask。

IMaterialModifier

IMaterialModifier 接口通常用于一个 Graphic 在渲染之前修改其 Material，它也有一个方法需要实现 GetModifiedMaterial，在这个方法中可以自定义修改渲染所用 Material 的实现方式。一个典型的使用就是 Graphic 在渲染时，会获取其对象上的所有的 IMaterialModifier，然后依次调用 GetModifiedMaterial 方法修改当前渲染所用的 Material。部分代码如下:

1
2
3
4
5
6
7
8
9
10
11

public virtual Material materialForRendering
{
    get
    {
        GetComponents(typeof(IMaterialModifier), components);
        var currentMat = material;
        for (var i = 0; i < components.Count; i++)
            currentMat = (components[i] as IMaterialModifier).GetModifiedMaterial(currentMat);
        return currentMat;
    }
}

IClipper

实现了这个接口的组件能够接收到 Canvas 更新时裁剪的回调，它有一个需要实现的方法 PerformClipping 用于执行裁剪，这个方法在 Graphic Layout 重建之后以及在 Graphic 渲染重建之前执行。

IClippable

实现了这个接口的组件其所在的 UI 元素能够被父元素裁剪，这个父元素需绑定实现了 IClipper 接口的组件。

Mask

Mask 类继承自 UIBehaviour 类，因此它具有 Unity 完整生命周期回调，同时它实现了 ICanvasRaycastFilter 接口，所以也可作为 Unity Event System 中事件分发射线检测对象，还实现了 IMaterialModifier 接口，这样在当前对象上的 Graphic 被渲染的时候，就会通过 Mask 类中的 GetModifiedMaterial 方法来修改渲染所用的材质。

为对象绑定 Mask 组件，必须在同一个对象上绑定一个 Graphic，这是因为 Mask 组件依赖 Graphic 组件来实现遮罩。将 Mask 组件绑定到对象上，如下:

可以看到在 Unity 编辑器中有一个可编辑属性 Show Mask Graphic，这个属性对应了 Mask 类里面的 m_ShowMaskGraphic 变量，用来标记在遮罩渲染中是否输出遮罩所在的 Graphic。

下面从 Mask 类源码出发，来分析整个 Mask 组件实现遮罩效果的流程。首先看看类中的主要的成员变量:

再来看看类中的相关方法:

showMaskGraphic get/set 方法

用来获取或设置 m_ShowMaskGraphic 变量，当设置这个变量时，如果设置值改变会触发当前组件所在的 Graphic 重新构建操作，如下:

1
2
3
4
5
6
7
8
9
10

set
{
    if (m_ShowMaskGraphic == value)
        return;

    m_ShowMaskGraphic = value;
    if (graphic != null)
        // set material dirty & wait for rebuild ...
        graphic.SetMaterialDirty();
}

OnEnable 方法

在组件 OnEnable 的时候，回调用如下代码:

1
2
3
4
5
6
7

if (graphic != null)
{
    graphic.canvasRenderer.hasPopInstruction = true;
    graphic.SetMaterialDirty();
}

MaskUtilities.NotifyStencilStateChanged(this);

从代码中可以看出，首先设置了 Graphic 所在 CanvasRender 的 hasPopInstruction 值为 true，并标记 Graphic 可以被重新构建；紧接着调用了 MaskUtilities 类的 NotifyStencilStateChanged 方法通知当前对象的所有绑定了实现了 IMaskable 接口组件的子元素计算它们的遮罩，MaskUtilities 类是实现遮罩效果常用的一个工具类，里面的方法在用到的时候会具体分析，先来看看 NotifyStencilStateChanged 方法如下:

1
2
3
4
5
6
7
8
9
10
11
12
13

public static void NotifyStencilStateChanged(Component mask)
{
    // other code ...
    mask.GetComponentsInChildren(components);
    for (var i = 0; i < components.Count; i++)
    {
        // is IMaskable
        var toNotify = components[i] as IMaskable;
        if (toNotify != null)
            toNotify.RecalculateMasking();
    }
    // other code ...
}

代码很简单，通过遍历子元素上绑定的实现了 IMaskable 接口的组件，依次调用 RecalculateMasking 方法来计算遮罩相关数据。

OnDisable 方法

1. 在 OnDisable 方法中，首先所在 Graphic 调用了 SetMaterialDirty 方法标记 Graphic 可以被重新构建；

2. StencilMaterial 类是一个辅助类，管理用于实现遮罩效果的 Stencil Materil，其中具体的方法在用到时具体分析；第二步就是调用 StencilMaterial 类的 Remove 方法依次移除 m_MaskMaterial 和 m_UnmaskMaterial；

3. 最后又一次调用 MaskUtilities 类的 NotifyStencilStateChanged 方法通知当前对象的所有绑定了实现了 IMaskable 接口组件的子元素再次计算它们的遮罩数据。

IsRaycastLocationValid 方法

这是 ICanvasRaycastFilter 接口实现的一个方法，用于 Unity Event System 中事件分发射线检测过程，在这个方法内部实现最终调用了 RectTransformUtility 类的静态方法 RectangleContainsScreenPoint 来确定当前所在的 RectTransform 是否包含了所指的屏幕上的点。

GetModifiedMaterial 方法

最后就是核心方法 GetModifiedMaterial，它是实现遮罩的关键方法之一。

首先回顾一下一个 Graphic 重新构建的过程: 当可被重新构建标记之后，在 Canvas 的渲染过程中调用了 Graphic 的 Rebuild 方法，然后调用 UpdateMaterial 方法设置渲染 Graphic 用的 Material，此时获取 Material 如下:

1
2
3
4
5
6
7
8

get
{
    GetComponents(typeof(IMaterialModifier), components);
    var currentMat = material;
    for (var i = 0; i < components.Count; i++)
        currentMat = (components[i] as IMaterialModifier).GetModifiedMaterial(currentMat);
    return currentMat;
}

Mask 需要和 Graphic 组件(具体来说是 MaskableGraphic 组件)一起绑定在同一个对象上才能发挥作用。当这个 MaskableGraphic 重新构建时，上面的代码会被调用用来获取渲染所用的材质，代码中遍历了当前对象上绑定的实现了 IMaterialModifier 接口的组件，然后调用其 GetModifiedMaterial 方法修改渲染用的 Material；这样的话 MaskableGraphic 和 Mask 组件的 GetModifiedMaterial 方法都会依次被调用。

下面就来看看这两个组件中对 GetModifiedMaterial 方法的实现吧！

1. MaskableGraphic 类中的 GetModifiedMaterial 方法

一个 MaskableGraphic 可以同 Mask 组件一起绑定(如 Image 组件所在对象上绑定一个 Mask 组件)来实现遮罩效果，也可以作为一个单独的组件绑定在某个对象上，比如创建 Unity UI 中的 Image(Image 类继承自 MaskableGraphic)元素。在这两种不同情况下，GetModifiedMaterial 方法发挥的作用也不一样，具体来看看代码:

1
2
3
4
5
6
7
8

var toUse = baseMaterial;

if (m_ShouldRecalculateStencil)
{
    var rootCanvas = MaskUtilities.FindRootSortOverrideCanvas(transform);
    m_StencilValue = maskable ? MaskUtilities.GetStencilDepth(transform, rootCanvas) : 0;
    m_ShouldRecalculateStencil = false;
}

首先判断当前 MaskableGraphic 是否需要计算模板数据，需要就调用 MaskUtilities 类的 GetStencilDepth 计算模板深度 m_StencilValue；GetStencilDepth 方法代码很简单，就是遍历计算对象的父元素看是否有绑定 Mask 组件，如果则 m_StencilValue 模板深度值加一。

若当前 MaskableGraphic 上绑定有 Mask 组件，那么当前方法也就执行完成了，返回的修改后的材质就是传入的材质(这种情况是作为 Mask 发挥作用的 Graphic 对象)；

如果没有绑定 Mask 组件，那么会执行以下代码计算修改材质(这种情况常见场景是一个需要被遮罩的 Image，且位于 Mask 组件所在的对象之下):

1
2
3
4
5
6
7
8

Mask maskComponent = GetComponent<Mask>();
if (m_StencilValue > 0 && (maskComponent == null || !maskComponent.IsActive()))
{
    var maskMat = StencilMaterial.Add(toUse, (1 << m_StencilValue) - 1, StencilOp.Keep, CompareFunction.Equal, ColorWriteMask.All, (1 << m_StencilValue) - 1, 0);
    StencilMaterial.Remove(m_MaskMaterial);
    m_MaskMaterial = maskMat;
    toUse = m_MaskMaterial;
}

从代码中可以看出，如果当前 MaskableGraphic 所在对象没有绑定 Mask 组件(或处于未激活状态)且 m_StencilValue 大于 0(其父元素中有 Mask 组件)，就调用 StencilMaterial 类的 Add 方法修改传入的材质，这个方法流程如下:

• 首先检测当前渲染所用的 Shader 是否定义了用于模板测试的相关变量，如未定义则返回当前 Shder 不作任何修改；

• 如果模板测试所用变量都定义了，遍历 MaskableGraphic 类中对于当前需求材质缓存，若从缓存中找到对应材质直接返回这个材质；

• 否则就根据当前渲染的材质生成一个新的材质，这个新的材质包含模板测试相关的属性，并缓存。

第三步主要是设置了材质的 Shader 中模板测试相关数据，对应关系如下:

这样就得到了修改之后包含模板测试的材质，如果设置成功了模板测试的相关数据，Unity 视图中会呈现出来，如下图:

上面模板测试条件为:

满足上述条件的像素就会通过测试，否则该像素不会被渲染。模板测试(和深度测试)通过后，模板缓冲值不会作任何处理(因为此处设置的 Pass 为 StencilOp.Keep)。通过这段分析我们知道，位于 Mask 组件所在对象下的 MaskableGraphic，如果所用 Shader 满足条件则会进行模板测试(默认渲染 UI 的 Shader 就是满足这个条件的，稍后会分析这个 Shader)。

2. Mask 类中的 GetModifiedMaterial 方法

另一个GetModifiedMaterial 方法就在 Mask 类中。上面讲到渲染前 MaskableGraphic 和 Mask 类中的这个方法依次被调用来修改材质， 但是与 Mask 相呼应的 MaskableGraphic 的GetModifiedMaterial 方法并未对当前渲染材质做任何修改，所以主要修改任务就来到了 Mask 中。下面就来看看其实现:

首先计算模板深度值，并限制了最大模板深度不能超过 8 层，如下:

1
2
3
4
5
6
7

var rootSortCanvas = MaskUtilities.FindRootSortOverrideCanvas(transform);
var stencilDepth = MaskUtilities.GetStencilDepth(transform, rootSortCanvas);
if (stencilDepth >= 8)
{
    Debug.LogWarning("Attempting to use a stencil mask with depth > 8", gameObject);
    return baseMaterial;
}

紧接着如果当前 Mask 所在的模板深度为 0(父元素中没有任何 Mask 组件)，使用如下代码修改材质的 Shader:

1
2
3
4
5
6
7
8
9
10
11

var maskMaterial = StencilMaterial.Add(baseMaterial, 1, StencilOp.Replace, CompareFunction.Always, m_ShowMaskGraphic ? ColorWriteMask.All : 0);
StencilMaterial.Remove(m_MaskMaterial);
m_MaskMaterial = maskMaterial;

var unmaskMaterial = StencilMaterial.Add(baseMaterial, 1, StencilOp.Zero, CompareFunction.Always, 0);
StencilMaterial.Remove(m_UnmaskMaterial);
m_UnmaskMaterial = unmaskMaterial;
graphic.canvasRenderer.popMaterialCount = 1;
graphic.canvasRenderer.SetPopMaterial(m_UnmaskMaterial, 0);

return m_MaskMaterial;

上面的代码中，首先依旧是调用 StencilMaterial 类的 Add 方法获取设置模板测试相关数据后的材质；其中模板测试条件是所有来到模板测试的像素全部通过，且对应的模板缓冲值都被设置为 1；

在修改完渲染所用材质之后，还更新了一个名为 m_UnmaskMaterial 的材质，其模板测试条件是所有来到模板测试的像素全部通过，且对应的模板缓冲值都被设置为 0，这个材质被 CanvasRender 通过调用 SetPopMaterial 方法设置到 CanvasRender 中，用于当前 Mask 所在对象的全部子元素渲染完成之后，重置模板缓冲区(这里会增加一个 drawCall)。

这两个材质的模板测试参数 ReadMask 和 WriteMask 都被设置为了 255，默认不影响模板测试参考值的读取以及模板缓冲值的读取和写入。如下图:

回顾一下前面讲到的内容，当 MaskableGraphic 作为 Mask 组件所在对象的子元素时，若此时这个 Mask 组件对象的模板深度值为 0，那么 MaskableGraphic 的模板深度值就是 1(渲染 Shader 中模板测试的参考值也是 1)；由于父元素在子元素之前渲染(Unity UI 渲染顺序决定)，在 MaskableGraphic 渲染之时模板缓冲区某些像素对应的模板缓冲值已经被置为 1，而另一些可能是默认值 0，此时 MaskableGraphic 的像素就只有在模板缓冲值是 1 的地方才能通过测试进而有可能被渲染出来。

看完了 Mask 所在的模板深度为 0的情况，再来看看 Mask 嵌套的问题。此时更新材质代码如下:

1
2
3
4
5
6
7
8
9
10
11

int desiredStencilBit = 1 << stencilDepth;

var maskMaterial2 = StencilMaterial.Add(baseMaterial, desiredStencilBit | (desiredStencilBit - 1), StencilOp.Replace, CompareFunction.Equal, m_ShowMaskGraphic ? ColorWriteMask.All : 0, desiredStencilBit - 1, desiredStencilBit | (desiredStencilBit - 1));

// other code ...
m_MaskMaterial = maskMaterial2;

var unmaskMaterial2 = StencilMaterial.Add(baseMaterial, desiredStencilBit - 1, StencilOp.Replace, CompareFunction.Equal, 0, desiredStencilBit - 1, desiredStencilBit | (desiredStencilBit - 1));

m_UnmaskMaterial = unmaskMaterial2;
// other code ...

同样的这里计算了 m_MaskMaterial 和 m_UnmaskMaterial 两个材质，与前面计算过程类似，只是对应模板测试的参数有点不同。

对于 Stencil 参数的设置，来看看这个对比表格:

其中 m_StencilValue 为其组件所在的模板深度值。

从表格中可以看出，当 Mask 所在组件的模板深度值大于 0 时其材质 Shader 模板测试参数的计算方式以及同其他情况下参数的对比。下面通过一个 Mask 嵌套的示例来分析整个流程，如下图:

其中 MaskPanel (0) 和 MaskPanel (1) 都是绑定了 Mask 组件的对象，MaskableGraphic 是一个普通的 Image，根据上面分析的过程可以知道这三个对象所在的模板深度 m_StencilValue 从上到下分别为 0、1 和 2。通过上面的表格能计算出渲染时模板测试的各个参数，得到如下表格:

从表格中可以总结以下几点:

• 从第二层(Stencil value 为 1)开始往下，每层渲染模板测试的 ReadMask 都是上一层的模板测试参考值，这是为了模板测试时能够完整的读取到之前 Stencil buffer 的值；

• 从第二层(Stencil value 为 1)开始往下(不包括非 Mask 的 UI 元素)，其模板测试参数 WriteMask 都和模板测试参考值相同，这是为了能在模板测试通过时能够将当前模板测试参考值完整写入到 Stencil buffer 中；

• 从第二层(Stencil value 为 1)开始往下(不包括非 Mask 的 UI 元素)，用于 UnMask 的模板测试参数 ReadMask 都和模板测试参考值相同。这是因为在重置 Stencil buffer 的时候是从下往上一个接一个 Mask 所在的 Shader 来渲染进行，此时模板测试参数 ReadMask 和模板测试参考值相同能够保证模板测试通过且让 Stencil buffer 的值恢复到模板测试参考值；

• 从第二层(Stencil value 为 1)开始往下(不包括非 Mask 的 UI 元素)，用于 UnMask 的模板测试参数 WriteMask 与当前层 Mask 时模板测试参考值相同，用于 UnMask 的模板测试参考值与上一层 Mask 时模板测试参考值相同，综合这两个条件，在重置当前层的 Stencil buffer 的时候就能够将模板测试缓冲区的值重置到上一层 Mask 时模板测试参考值。

接着从上往下依次开始渲染，假设现在渲染的一块像素区域如下:

上图中每一个格子对应一个像素，初始状态每个像素上的 Stencil Buffer 值为 0，现在第一个 Mask 所在的 UI 元素 MaskPanel (0) 开始渲染(使用 UI-Default.shader)，渲染完成之后各个像素的 Stencil Buffer 值如下图:

从上图中可以看出，有一部分 Stencil Buffer 值如之前分析的那样被设置成了 1，但是不应该是根据模板测试参数所有的 Stencil Buffer 值都被设置成 1 吗？这里是因为在使用 UI-Default.shader 的时候，在模板测试之前会进行 Alpha 测试，部分像素在那一步就没有通过，因此还没来得及到模板测试就被 discard 了，所以会有部分像素的 Stencil Buffer 值为 0。

注意看上图中那些 Stencil Buffer 值被置为 1 的像素其颜色也输出了，这里 Mask 所在 Graphic 颜色能否输出就是之前所说的 Mask 类的 m_ShowMaskGraphic 决定的，当这个值被设置为 true，Shader 中的 ColorMask 会被设置为 ColorWriteMask.All，从而能输出所有颜色通道值，否则m_ShowMaskGraphic 被设置为 false 将不会有任何颜色通道值输出。

下面再来看看第二层 Mask 所在 MaskPanel (1) 的渲染，结果如下图:

计算过程大致如下: 将当前模板测试参考值和 Stencil Buffer 值都与 ReadMask 按位与操作后，如果这两个结果值相等则通过模板测试，紧接着若是深度测试也通过则将当前模板测试参考值与 WriteMask 进行按位与操作，得到的值写入 Stencil Buffer。

通过上述的过程，原来 Stencil Buffer 值为 1 的像素被设置成了 3；像素的颜色值能否输出也和自身 Mask 组件上的 m_ShowMaskGraphic 相关，若输出颜色通道值则最后像素颜色值根据 Shader 中 Blend 的设置(UI-Default.shader 默认 Blend SrcAlpha OneMinusSrcAlpha)进行混合。

最后来看看 MaskableGraphic 的渲染，结果如下图:

到这一步，就很简单了。如上图所示，Stencil Buffer 值都没有发生改变，但是像素颜色发生了变化，这一渲染中模板测试的过程如下: 当前模板测试参考值是 3，而上一步仅部分 Stencil Buffer 值计算设置为 3，所以在这部分像素模板测试通过，像素颜色通道值通过混合后输出为新的值；而上一步 Stencil Buffer 值为 0 的像素这里模板测试失败，因此被 discard 无法渲染，至此一个 MaskableGraphic 遮罩效果就实现了。

前面分析 Mask 类的 GetModifiedMaterial 方法时讲到过，这个方法除了修改用于 Mask 的材质，还会修改用于 UnMask 的材质，下面就来看看 UnMask 的过程。

首先是 UI 元素 MaskPanel (1) UnMask 时渲染情况，如下图:

从上图中可以看出，根据 MaskPanel (1) 元素 UnMask 所用 Shader 的模板测试相关参数和条件方式，将 Stencil Buffer 值为 3 的像素的 Stencil Buffer 值更新为了 1，这个过程如下:

UnMask 所在的 Shader 的模板参考值以及 Stencil Buffer 值与当前计算所用的 ReadMask 进行按位与操作，若结果相等则模板测试通过(假设深度测试也通过)，那么将当前使用的模板测试参考值和 WriteMask 进行按位与操作，得到的值写入 Stencil Buffer。

需要注意的是，UnMask 渲染流程中像素的颜色值没有发生任何变化，这是因为所有的 UnMask 使用材质的 Shader 中的 ColorMask 参数被设置为 0，因此不会输出任何颜色通道值。

然后是 UI 元素 MaskPanel (0) UnMask 时渲染情况，如下图:

这个过程和上一步类似，只是使用的模板测试参数和计算方式不一样。经过 UnMask 流程最终所有像素对应的 Stencil buffer 值全部重置为 0。这里再强调一下，这里每一次 UnMask 都会增加一个 drawCall，因此项目中尽可能注意少用或者不用 Mask 实现遮罩。如下图是 Frame Debug 中 MaskPanel (1) 和 MaskPanel (0) 两个元素 UnMask 渲染时参数:

Unity UI 默认 Shader

上面基本上分析完了遮罩实现的流程，部分 Shader 的知识点也有分析，下面再来看看 Unity UI 默认 Shader 代码，首先是属性定义

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Properties
{
    [PerRendererData] _MainTex ("Sprite Texture", 2D) = "white" {}
    _Color ("Tint", Color) = (1,1,1,1)

    _StencilComp ("Stencil Comparison", Float) = 8
    _Stencil ("Stencil ID", Float) = 0
    _StencilOp ("Stencil Operation", Float) = 0
    _StencilWriteMask ("Stencil Write Mask", Float) = 255
    _StencilReadMask ("Stencil Read Mask", Float) = 255

    _ColorMask ("Color Mask", Float) = 15

    [Toggle(UNITY_UI_ALPHACLIP)] _UseUIAlphaClip ("Use Alpha Clip", Float) = 0
}

上面的代码中除了定义常规的纹理、颜色等属性之外，还有用于模板测试的一些变量。
接下来看看模板测试的代码，如下:

1
2
3
4
5
6
7
8

Stencil
{
    Ref [_Stencil]
    Comp [_StencilComp]
    Pass [_StencilOp]
    ReadMask [_StencilReadMask]
    WriteMask [_StencilWriteMask]
}

代码中主要定义了模板测试参考值 Ref、参考值与 Stencil buffer 值比较函数 Comp、模板测试(和深度测试)通过对 Stencil buffer 值的处理方式 Pass、写 Stencil buffer 值时的写入(按位与)掩码、模板测试参考值和 Stencil buffer 值读取(按位与)掩码 ReadMask。

接着就是渲染管线部分配置，如下:

1
2
3
4
5
6

Cull Off
Lighting Off
ZWrite Off
ZTest [unity_GUIZTestMode]
Blend SrcAlpha OneMinusSrcAlpha
ColorMask [_ColorMask]

这里设置了 ZTest 方式、混合模式、ColorMask 等配置。

然后是顶点着色器和片元着色器的代码:

1
2
3
4
5
6
7
8
9
10

v2f vert(appdata_t v)
{
    v2f OUT;
    // other code ...
    OUT.worldPosition = v.vertex;
    OUT.vertex = UnityObjectToClipPos(OUT.worldPosition);
    OUT.texcoord = TRANSFORM_TEX(v.texcoord, _MainTex);
    OUT.color = v.color * _Color;
    return OUT;
}

顶点着色器代码很简单，主要就是顶点变换、UV 坐标校正以及顶点颜色计算。下面主要来看看片元着色器部分代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

fixed4 frag(v2f IN) : SV_Target
{
    half4 color = (tex2D(_MainTex, IN.texcoord) + _TextureSampleAdd) * IN.color;

    #ifdef UNITY_UI_CLIP_RECT
    color.a *= UnityGet2DClipping(IN.worldPosition.xy, _ClipRect);
    #endif

    #ifdef UNITY_UI_ALPHACLIP
    clip (color.a - 0.001);
    #endif

    return color;
}

代码中首先对纹理进行采样，然后有分两种情况对像素进行处理:

• 如果是 UNITY_UI_CLIP_RECT 就使用 UnityGet2DClipping 函数判断当前点是否在遮罩区域 _ClipRect 内，如果在这个方法就返回 1，否则返回 0；所以最终输出颜色的 Alpha 也就跟当前像素是否在遮罩区域类有关，在遮罩区域内 Alpha 值保持原来的值输出，否则 Alpha 值为 0。这种方式用于 RectMask2D 遮罩使用，下面会分析到。

• UNITY_UI_ALPHACLIP 这种方式就是我们分析的 Mask 遮罩实现的关键之一。Mask 组件所在的 MaskableGraphic 渲染时，如果某个像素纹理采样计算之后得到的 Alpha 值小于 0.001，那么在这里会使用 clip 函数 discard 这个像素，这也就是为什么之前分析的时候讲到可能会有部分像素所在的 Stencil buffer 值为初始值 0 的原因。这样也就实现了用纹理 Alpha 值来控制遮罩。

RectMask2D

RectMask2D 和 Mask 相似，其主要区别在于 RectMask2D 直接实现矩形遮罩效果(将子元素显示区域控制在一个矩形框内)。

RectMask2D 类继承自 UIBehaviour 类，同样它具有 Unity 完整生命周期回调，同时它实现了 ICanvasRaycastFilter 接口，所以也可作为 Unity Event System 中事件分发射线检测对象，还实现了 IClipper 接口用于更新裁剪相关信息。下面就来分析一下 RectMask2D 类的代码。

OnEnable 方法

还是从 OnEnable 方法开始，首先调用 ClipperRegistry 类 Register 方法将自己注册，这样在 Canvas 执行更新时，自身就能收到回调从而调用 PerformClipping 方法；紧接着调用 MaskUtilities 类的 Notify2DMaskStateChanged 方法通知子元素重新计算裁剪相关的参数信息。

比如一个 MaskableGeaphic 元素位于 RectMask2D 下(MaskableGeaphic 实现了 IClippable 接口)，当调用 Notify2DMaskStateChanged 方法时 MaskableGeaphic 的 RecalculateClipping 方法会被回调，从而 MaskableGeaphic 的父 RectMask2D 元素会被更新(具体是 MaskableGeaphic 的 RecalculateClipping 方法又调用其自身的 UpdateClipParent 方法来寻找最合适的父 RectMask2D 元素，找到后调用之前父 RectMask2D 的 RemoveClippable 方法将自身移除，然后调用新父 RectMask2D 的 AddClippable 将自身添加到 RectMask2D 中)。

OnDisable 方法

这个方法首先清除相关数据，然后从 ClipperRegistry 中反注册自己，最后再次调用 MaskUtilities 类的 Notify2DMaskStateChanged 方法通知子元素重新计算裁剪相关的参数信息。

IsRaycastLocationValid 方法

这个方法和 Mask 中的相同，这里不再分析。

AddClippable 方法

将一个 IClippable 添加到自身的跟踪列表中，用于后续的裁剪计算等。

RemoveClippable 方法

从自身的 IClippable 跟踪列表中移除一个 IClippable，代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13

public void RemoveClippable(IClippable clippable)
{
    // other code ...
    clippable.SetClipRect(new Rect(), false);

    MaskableGraphic maskable = clippable as MaskableGraphic;

    if (maskable == null)
        m_ClipTargets.Remove(clippable);
    else
        m_MaskableTargets.Remove(maskable);
    // other code ...
}

从代码中可以看出在移除之前，首先调用了 IClippable 的 SetClipRect 方法使得这个 IClippable 不再计算 Rect 裁剪。比如 MaskableGeaphic 的 SetClipRect 就调用了 canvasRenderer.DisableRectClipping() 来禁用裁剪。

PerformClipping 方法

当 Canvas 执行更新 ClipperRegistry 类的 Cull 方法在 Layout Rebuild 之后、在 Graphic Rebuild 之前被调用，从而 RectMask2D 的 PerformClipping 被回调。下面就来分析这个方法的执行过程:

首先如果 m_ShouldRecalculateClipRects 为 true，那么执行如下代码计算当前 RectMask2D 所在元素的所有父 RectMask2D 元素(包括自身):

1

MaskUtilities.GetRectMasksForClip(this, m_Clippers);

接着调用 Clipping 类的 FindCullAndClipWorldRect 方法计算裁剪的矩形区域 clipRect。代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

public static Rect FindCullAndClipWorldRect(List<RectMask2D> rectMaskParents, out bool validRect)
{
    // no RectMask2D return empty Rect, validRect is 'false'

    Rect current = rectMaskParents[0].canvasRect;
    float xMin = current.xMin;
    float xMax = current.xMax;
    float yMin = current.yMin;
    float yMax = current.yMax;
    for (var i = 1; i < rectMaskParents.Count; ++i)
    {
        current = rectMaskParents[i].canvasRect;
        if (xMin < current.xMin) xMin = current.xMin;
        if (yMin < current.yMin) yMin = current.yMin;
        if (xMax > current.xMax) xMax = current.xMax;
        if (yMax > current.yMax) yMax = current.yMax;
    }

    validRect = xMax > xMin && yMax > yMin;
    if (validRect)
        return new Rect(xMin, yMin, xMax - xMin, yMax - yMin);
    else
        return new Rect();
}

上面的代码很简单，就是遍历上一步寻找到的所有的 RectMask2D 元素，然后通过调用 RectangularVertexClipper 的 GetCanvasRect 方法获取这个 RectMask2D 元素在 Canvas 空间下的 Rect，最终保留所有 RectMask2D 的重叠区域来作为矩形裁剪区域(如果是合法的) clipRect。

接着判断上一步计算得到的重叠矩形裁剪区域 clipRect 是否和根 Canvas 所在矩形区域重叠，如果 Canvas Render Mode 是 RenderMode.ScreenSpaceXX 且 clipRect 和根 Canvas 所在矩形区域不重叠，那么将不会渲染其内容。代码如下:

1
2
3
4
5
6
7
8
9

RenderMode renderMode = Canvas.rootCanvas.renderMode;
bool maskIsCulled = (renderMode == RenderMode.ScreenSpaceCamera || renderMode == RenderMode.ScreenSpaceOverlay) && !clipRect.Overlaps(rootCanvasRect, true);

if (maskIsCulled)
{
    // set an invalid rect to allow calls to avoid some processing ...
    clipRect = Rect.zero;
    validRect = false;
}

最后就设置 IClippable 跟踪列表中子元素的裁剪区域。

• 如果当前计算的 clipRect 和上次的裁剪矩形区域不相等，那么执行以下代码:

1
2
3
4
5
6
7
8
9
10

foreach (IClippable clipTarget in m_ClipTargets)
{
    clipTarget.SetClipRect(clipRect, validRect);
}

foreach (MaskableGraphic maskableTarget in m_MaskableTargets)
{
    maskableTarget.SetClipRect(clipRect, validRect);
    maskableTarget.Cull(clipRect, validRect);
}

上面的代码中调用 IClippable 的 SetClipRect 方法设置 ClipRect。这里以 MaskableGraphic 为例，最终调用的代码是 canvasRenderer.EnableRectClipping(clipRect)，也就是渲染这个 MaskableGraphic 的 CanvasRender 会启用 Rect Clip 并设置渲染 Shader 中的 _ClipRect 变量的值，这样当渲染执行的时候就能够实现矩形遮罩效果。

对于 MaskableGraphic 还有一步，就是调用其 Cull 方法更新 CanvasRender 的 cull 值。

• 如果当前计算的 clipRect 和上次的裁剪矩形区域相等但是 m_ForceClip 为 true，那么强制调用 SetClipRect 方法设置 ClipRect。这里有一点小不同是对于最后 MaskableGraphic 的 Cull 方法的调用，仅在当前 UI 元素有任何影响几何更新的变动时(CanvasRender 的 hasMoved 被标记为 true) Cull 方法才会被调用。

• 最后如果上面两种情况都不满足，那么就只会对绑定了 MaskableGraphic 组件的子元素执行 Cull 方法更新 CanvasRender 的 cull 值(这个元素所在 CanvasRender 的 hasMoved 需标记为 true)。

至此 RectMask2D 实现遮罩的流程代码也就分析完了。

分析完 RectMask2D 的重要代码部分，可以看出其和 Mask 的不同之处在于 RectMask2D 并未使用模板测试来计算遮罩，因此相比之下 RectMask2D 会少一个 drawCall，因此相比使用 Mask 性能会好一些。但是 RectMask2D 实现遮罩效果被限制在一个矩形区域内，相比 Mask 遮罩就显得没有那么灵活，所以具体使用何种方式实现遮罩视项目需求而定。

参考

• Unity Manual - Mask

• UI-Default.shader

• Unity Manual - RectMask2D

前言

CanvasGroup 组件用来调整一组 UI 元素的部分属性，这个组件的出现就是为了方便开发者实现一些批量更新操作，而不用单独修改多个 UI 元素的属性。

Alpha

调整当前 group 下面所有 UI 元素的透明度，UI 元素自身的透明度值不会改变，但是最终的透明度是当前设置的 Alpha 和 UI 元素透明度乘积。

Interactable

设定当前 group 下的 UI 元是否响应输入事件(可以交互)。

对于这个配置，我们以 Button 为例来分析这个属性是如何生效的。对于 Button 组件来说，当它响应自定义绑定的函数 OnClick，是在接收到 EventSystem 发送的 Press 事件，代码如下:

1
2
3
4
5
6
7
8

private void Press()
{
    if (!IsActive() || !IsInteractable())
        return;

    UISystemProfilerApi.AddMarker("Button.onClick", this);
    m_OnClick.Invoke();
}

从代码中可以看出，当 Button 组件不是激活状态或者是不响应交互状态，那么就不会执行回调函数，这里我们主要看 IsInteractable() 方法。

Button 类继承自 Selectable 类，它没有覆写IsInteractable() 方法，所以看Selectable 类中该方法的实现:

1
2
3
4

public virtual bool IsInteractable()
{
    return m_GroupsAllowInteraction && m_Interactable;
}

该方法实现很简单，当 CanvasGroup 组件的 Interactable 为 true 且自身的 Interactable 设置也为 true，那么当前的 Button 就能响应交互事件。

那么 CanvasGroup 组件的 Interactable 配置是如何赋值到 Button 组件的 m_GroupsAllowInteraction 成员变量中的了？Selectable 类继承自 UIBehaviour 类，因此当有 CanvasGroup 组件配置更新时，OnCanvasGroupChanged（) 方法会被回调(仅能够影响这个组件的 Canvas Group 更新才会收到回调，比如父节点或自身节点上的 Canvas Group 更新)，正是在这个方法里面，CanvasGroup 组件的 Interactable 配置被更新到了 Button 组件的 m_GroupsAllowInteraction 变量中。代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

protected override void OnCanvasGroupChanged()
{
    var groupAllowInteraction = true;
    Transform t = transform;
    while (t != null)
    {
        t.GetComponents(m_CanvasGroupCache);
        bool shouldBreak = false;
        for (var i = 0; i < m_CanvasGroupCache.Count; i++)
        {
            if (!m_CanvasGroupCache[i].interactable)
            {
                groupAllowInteraction = false;
                shouldBreak = true;
            }
            // do 'ignoreParentGroups' code...
        }
        if (shouldBreak)
            break;
        // other code...
    }

    // 更新 CanvasGroup 的 Interactable 到 m_GroupsAllowInteraction
    if (groupAllowInteraction != m_GroupsAllowInteraction)
    {
        m_GroupsAllowInteraction = groupAllowInteraction;
        OnSetProperty();
    }
}

Block Raycasts

UI 元素是否接收射线检测，在 Event System 中检测事件拦截对象时使用。

这里还是以 Button 组件为例分析。在 Event System 射线检测拦截事件对象这一步时，对于 UI 元素的检测会使用到 Graphic 的 Raycast(Vector2 sp, Camera eventCamera) 方法，其中就根据这个值判断了射线检测是否成功，如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

var filter = components[i] as ICanvasRaycastFilter;
if (filter == null)
    continue;

var raycastValid = true;
var group = components[i] as CanvasGroup;

if (group != null)
{
    // other code... 
    raycastValid = filter.IsRaycastLocationValid(sp, eventCamera);
}
// other code...

if (!raycastValid)
{
    ListPool<Component>.Release(components);
    return false;
}

由于 Button 类及其祖先类都没有实现 ICanvasRaycastFilter 接口，而 CanvasGroup 类实现了；当在 Button 对象上添加 CanvasGroup 组件，raycastValid 结果就由 CanvasGroup 类的 IsRaycastLocationValid() 方法决定，CanvasGroup 类中的 IsRaycastLocationValid() 方法返回值就是设置的 Block Raycasts，所以当 Block Raycasts 设置为 true，则会通过射线检测。当然在上面只是 Graphic 类中射线检测代码的不部分，要通过完整的检测还包括其它条件判断以及整个节点链的测试通过等，具体可阅读 Unity Raycasters 剖析 一文。

Ignore Parent Groups

忽略祖先节点对象中 CanvasGroup 组件的设置。

如果当前 CanvasGroup 所在对象的父节点或是祖先节点也绑定了 CanvasGroup 组件，那么它们的 CanvasGroup 组件设置也会影响当前对象的行为。

这里我们接着以 Button 射线检测为例，看看 Graphic 类中的射线检测另一部分代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

var t = transform;
var components = ListPool<Component>.Get();
bool ignoreParentGroups = false;

while (t != null)
{
    t.GetComponents(components);
    for (var i = 0; i < components.Count; i++)
    {
        // other code...
        var filter = components[i] as ICanvasRaycastFilter;
        if (filter == null) continue;

        var raycastValid = true;
        var group = components[i] as CanvasGroup;
        if (group != null)
        {
            if (ignoreParentGroups == false && group.ignoreParentGroups)
            {
                ignoreParentGroups = true;
                raycastValid = filter.IsRaycastLocationValid(sp, eventCamera);
            }
            else if (!ignoreParentGroups)
                raycastValid = filter.IsRaycastLocationValid(sp, eventCamera);
        }

        if (!raycastValid) return false;
    }
    t = continueTraversal ? t.parent : null;
}
// other code...
return true;

当 Button 对象绑定了 CanvasGroup 组件并且设置其 Ignore Parent Groups 为 true，那么上面代码中变量 raycastValid 的值就只由当前 CanvasGroup 组件设置的 Block Raycasts 值决定；否则如果设置的 Ignore Parent Groups 为 false，那么变量 raycastValid 的值会一层层向上冒泡去求得。

所以 Ignore Parent Groups 这个配置会忽略祖先节点的 CanvasGroup 组件配置。

前言

Canvas 是所有 UI 组件被布局和渲染的空间，这些 UI 组件都必须位于 Canvas 子节点。在 Unity 编辑器中，我们可以方便的进行 Canvas UI 编辑。

一个 Canvas 系统通常包含以下几个组件:

• Canvas 组件(Canvas 对象的基础组件)

• CanvasScaler 组件(控制所有 UI 元素的缩放)

• GraphicRaycaster 组件(用于 Event System 中的射线检测)

接下来，我们就一起来看看每个组件的分工与作用。

先来简单介绍 Canvas 组件

Canvas 组件(类)继承自 Behaviour 类，因此它可以被 enable 或 disable，同时它继承了祖先类的属性和方法。在其内部包含一些属性，可以在 Unity 编辑器中直接设置。这些属性配置用来描述 Canvas 系统是如何运作的，如下:

这里主要说明一下 Render Mode 这个属性，用来设置 UI 的渲染方式，有 Screen Space-Overlay、Screen Space-Camera和 World Space 三个值可以设置。

• Screen Space-Overlay

这种模式设置让所有 UI 直接显示在屏幕的最上方(包括 Camera 渲染的场景图像)。Canvas 通过缩放来适配不同的屏幕分辨率，当屏幕尺寸改变或分辨率改变，会自动重新计算并布局。

• Screen Space-Camera

这种模式和 Screen Space - Overlay 有点相似，不同的是在这种模式下需要设定一个 Camera，所有的 UI 元素由该 Camera 渲染(如果未指定 Render Camera，就会以 Screen Space - Overlay 模式去渲染)。这种模式下 Canvas 朝向 Camera，通过 Plane Distance 可以调整 Canvas 和 Camera 的距离。当屏幕尺寸、分辨率或 Camera 的视锥体大小发生变化，Canvas 都会通过改变自身的 scale 去自动适配。如果场景中有 3D 物体并且离 Camera 近，那么 3D 物体会渲染在 Canvas 前面，反之 Canvas 会渲染在 3D 物体的前面。

• World Space

这种模式下，Canvas 被当成世界空间下一个普通的 3D 对象去渲染，所以它既可以渲染在某些对象的前面，也可以渲染在某些对象的后面。和 Screen Space-Camera 模式的区别是 Canvas 不需要再朝向 Camera，Canvas 可以通过设置自身的不同属性调整位置、大小、角度等。

Canvas 组件(类)中，还有一些其他属性，但是它们不可以在编辑器中配置，例如 scaleFactor 属性就是 Canvas 自适应会用到的一个变量，使用它来缩放整个 Canvas 以使其适配屏幕。还有更多属性的作用与介绍请参考 Unity Scripting API - Canvas，这里不再一一介绍。

Canvas 如何自动适配了？

上面讲到，在 Render Mode 设置为 Screen Space-Overlay 和 Screen Space-Camera 时，当屏幕尺寸、分辨率变换 Canvas 都会自动重新计算来进行自动适配，那么适配工作是如何进行的了？

• Screen Space-Overlay

在这种模式下，Canvas 所在的 Rect Transform 的宽高分别为 400 和 400，Scale 均为 1，当前游戏屏幕设定的分辨率也是 400*400，因此 Canvas 的宽高在这种模式下就会自动跟随物理分辨率自动设置。

• Screen Space-Camera

在这种模式下，首先来看看 Canvas 的配置以及计算得到的适配结果:

图中 Rect Transform 的 Width 和 Height 的值分别为 400 和 400，Scale 的三个值都被计算 0.05；Canvas 的 Plane Distance 被设置为 10，并添加了一个 Render Camera。

当前游戏屏幕设定的分辨率为 400*400，所以 Canvas 宽高都被设置为 400 很好理解(布满屏幕)，但是这里的 Scale 为什么都被计算成了 0.05 了？

带着疑问，再来看看 Render Camera 的一些配置:

其中 Projection 为 Perspective (透视投影)，Field of View 设置为 90 度，Target Display 中的值就是设置的 400*400 的屏幕。

根据上面的配置以及视锥体和三角函数，其实可以计算得到 Canvas 的真实高度为:

由于 Target Display 的宽高比例为 1:1，因此 Canvas 的宽就等于高:

对 Canvas 进行缩放就得到了真实的宽高，所以缩放系数:

带入数字计算得到 Canvas 的 Scale 就是 0.05(当 Camera 投影方式设置为 Orthographic，也可使用对应的参数去计算)。

CanvasScaler 起到了什么作用？

对于多分辨率的适配问题，究竟什么样的适配才算得上完美，也许依游戏不同适配的要求也有所区别。在 Unity 中，适配的时候我们常常离不开 CanvasScaler 这个组件，它用来帮助我们的游戏“适应”不同尺寸的屏幕。

The Canvas Scaler component is used for controlling the overall scale and pixel density of UI
elements in the Canvas. This scaling affects everything under the Canvas, including font sizes and image borders.

如官方文档所说，Canvas Scaler 用来控制 Canvas 下所有 UI 元素的缩放以及像素密度，它的缩放比例会影响 Canvas 下所有的元素。

CanvasScaler 组件在编辑器中也有很多可以配置的属性，首先最重要的就是 UI Scale Mode，有三种模式可以设置，用来控制 UI 元素在 Canvas 下是如何缩放的(当 Canvas 的 Render Mode 设置为 Screen Space-xx 时这三种模式能够生效)。下面就结合源码分别来分析一下究竟是如何进行缩放的了？

Constant Pixel Size

设置为这种模式时，所有 UI 元素的位置和大小都保持为原来的像素大小，但是会根据设置的 Scale Factor 缩放。若一个 Canvas 没有绑定 CanvasScaler 组件(上一部分讲到的情况)，其适配过程就是使用这种模式。

在这种模式下，有两个参数可以手动配置: Scale Factor 和 Reference Pixels Per Unit。在 CanvasScaler 类的 Handle() 方法中，使用 HandleConstantPixelSize() 对这两个配置进行使用，代码如下:

1
2
3
4
5

protected virtual void HandleConstantPixelSize()
{
    SetScaleFactor(m_ScaleFactor);
    SetReferencePixelsPerUnit(m_ReferencePixelsPerUnit);
}

其中 m_ScaleFactor 就是配置项 Scale Factor，m_ReferencePixelsPerUnit 就是配置项 Reference Pixels Per Unit。SetScaleFactor 方法和 SetReferencePixelsPerUnit 方法就是设置当前 Canvas 的这两个值。

1. 配置 Scale Factor 后，Canvas 组件中的属性 scaleFactor 也被更新为设置的这个值，然后用这个缩放系数来缩放 Canvas 下所有的 UI 元素。

例如屏幕大小为 400*400，Scale Factor 设置为 2，Canvas 为了适配屏幕的宽高就会通过公式 $ScreenSize \div Scale Factor$ 计算得到宽高值为都 200，同时 Canvas 下所有的 UI 元素也都被缩放 2 倍。

2. Reference Pixels Per Unit 配置就是 Canvas 组件中的成员变量 referencePixelsPerUnit，表示每个 Unity 单位包含的屏幕(UI)像素。这个参数需要与 Sprite 设置下的 Pixel Per Unit(每 Unity 单位中包含多少个 Sprite 像素) 一起使用。

在 Image 组件的源码中我们就可以看到这样的使用，代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

public float pixelsPerUnit
{
    get
    {
        float spritePixelsPerUnit = 100;
        if (activeSprite)
            spritePixelsPerUnit = activeSprite.pixelsPerUnit;

        if (canvas)
            m_CachedReferencePixelsPerUnit = canvas.referencePixelsPerUnit;

        return spritePixelsPerUnit / m_CachedReferencePixelsPerUnit;
    }
}

public override void SetNativeSize()
{
    if (activeSprite != null)
    {
        float w = activeSprite.rect.width / pixelsPerUnit;
        float h = activeSprite.rect.height / pixelsPerUnit;
        rectTransform.anchorMax = rectTransform.anchorMin;
        rectTransform.sizeDelta = new Vector2(w, h);
        SetAllDirty();
    }
}

在上面的代码 pixelsPerUnit 方法中，spritePixelsPerUnit 被设置为了 Sprite 的 pixelsPerUnit，m_CachedReferencePixelsPerUnit 被设置成了 Canvas 的 referencePixelsPerUnit(这个值就是我们再 Canvas Scaler 中配置的值)。最后这里的计算返回的 pixelsPerUnit 为 spritePixelsPerUnit / m_CachedReferencePixelsPerUnit。

再看看 SetNativeSize，这个方法用来设置 Image 使其更加 pixel-perfect (更加清晰)，设置后 Image 的 rectransform.sizedelta 就有可能和 Sprite 的尺寸相等。将 Sprite 转换到 Unity 单位下:

然后将 Sprite 由 Unity 单位尺寸转换为屏幕 UI 尺寸:

即

比如: Sprite 的原始尺寸为 400400，Pixel Per Unit 为 100，那么 Sprite 在 Unity 中的大小就是 44 个单位；Canvas Scaler 的 Reference Pixels Per Unit 为 100(一个 Unity 单位对应屏幕 UI 100 个像素)，因此最后 Sprite pixel-perfect 的尺寸就是 400*400。

在 Constant Pixel Size 模式下，所有的 UI 元素的大小和位置都使用屏幕像素来指定计算。通过 Scale Factor 指定缩放系数，Reference Pixels Per Unit 用来指定每 Unity 单位又会以多少像素渲染在屏幕上。

Scale With Screen Size

使用这种模式，UI 元素能够根据参考分辨率以及配置的参数达到自适应(计算最合适的 Scale Factor)不同分辨率屏幕的目的。首先还是先看一下这种模式下可以配置的一些参数:

1. Reference Resolution - 参考分辨率，通常为设计所用的分辨率。

2. Reference Pixels Per Unit - 这个值在 Constant Pixel Size 模式下讲过，计算方式都相同，这里不再讲解。

3. Screen Match Mode - 屏幕适配模式，当屏幕分辨率的比例和参考分辨率的比例不同时，就会根据这个参数来计算 Scale Factor(缩放系数，其实在比例相同的时候也会使用以下配置计算，只是对于下面不同的设置值计算结果都相同)。它有以下几个值:

   • Match Width or Height - 在这种屏幕适配模式下，Canvas 会根据某个方向(Width、 Height 或他们中间的某个值)单独(混合)的计算缩放系数来适配；

     • Match - 通过改变这个值(0-1 之间。0 是代表 Width、1 是代表 Height)计算缩放系数。

   • Expand - 设置为这个值的时候 Canvas 会水平或垂直展开以缩放，Canvas 的大小永远不会比参考分辨率小；

   • Shrink - 设置为这个值的时候 Canvas 会水平或垂直裁剪以缩放，Canvas 的大小永远不会比参考分辨率大。

下面看看具体是如何计算 Scale Factor 来达到以上的适配要求。在 Handle() 方法中，如果 Scale Mode 是 Scale With Screen Size，会使用 HandleScaleWithScreenSize() 计算 Scale Factor，代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

protected virtual void HandleScaleWithScreenSize()
{
    // get screen size...

    float scaleFactor = 0;
    switch (m_ScreenMatchMode)
    {
        case ScreenMatchMode.MatchWidthOrHeight:
        {
            float logWidth = Mathf.Log(screenSize.x / m_ReferenceResolution.x, kLogBase);
            float logHeight = Mathf.Log(screenSize.y / m_ReferenceResolution.y, kLogBase);
            float logWeightedAverage = Mathf.Lerp(logWidth, logHeight, m_MatchWidthOrHeight);
            scaleFactor = Mathf.Pow(kLogBase, logWeightedAverage);
            break;
        }
        case ScreenMatchMode.Expand:
        {
            scaleFactor = Mathf.Min(screenSize.x / m_ReferenceResolution.x, screenSize.y / m_ReferenceResolution.y);
            break;
        }
        case ScreenMatchMode.Shrink:
        {
            scaleFactor = Mathf.Max(screenSize.x / m_ReferenceResolution.x, screenSize.y / m_ReferenceResolution.y);
            break;
        }
    }

    // set scale factor & reference pixels per unit
}

• ScreenMatchMode.MatchWidthOrHeight

在这个设置下，在对数空间计算 scaleFactor 值。通过代码可以看出，首先将所在的屏幕宽度与参考分辨率宽度比例转换到对数空间，高度比例也转换到对数空间，然后在对数空间下通过 Match 的配置对宽度比例和高度比例进行插值得到对数空间下的 scaleFactor，最后在将对数空间下的 scaleFactor 转换回原始空间下(对数空间下计算有更好的表现)。

根据上面的代码，可以得到 scaleFactor 计算公式。

对数空间下屏幕宽度和参考分辨率的宽度比例:

对数空间下屏幕高度和参考分辨率的宽度比例:

最终 scaleFactor 等于:

由此可以看出当 Match 设置为 0 (在最左边)时，带入公式计算得

scaleFactor 就是屏幕宽度与参考分辨率宽度比例，这种情况下高度对 Canvas 缩放没有任何影响。同理如果 Match 设置为 1 (拖到最右边)，那么 scaleFactor 就是屏幕高度与参考分辨率高度比例。

那么在什么情况下设置为这个值比较好了？当你的游戏发布后可能面对的分辨率千奇百怪(比各种如 Android 手机)，这个时候 Screen Match Mode 设置为 ScreenMatchMode.MatchWidthOrHeight，通过按宽度、高度或是混合宽度高度来计算缩放系数，以尽可能达到各种分辨率屏幕适配。朝着一个方向缩放，能够保证这个方向上位置布局不会出现问题，但是另一个方向会根据适配屏幕适配这个要求去拉伸；这时也许设置一个混合值 Match 可以更好的达到适配缩放显示效果。

• ScreenMatchMode.Expand

通过上面代码可以看出，当 Screen Match Mode 设置为 ScreenMatchMode.Expand 时，最终得到的 scaleFactor 是屏幕分辨率与参考分辨率宽高比中较小的一个，然后根据 scaleFactor 计算 Canvas 的宽高的公式为:

假如上面计算的到的 scaleFactor 是 screenSize.x / m_ReferenceResolution.x (宽的分辨率比例小)，则有:

带入计算 Canvas 的公式得到 Canvas 宽高分别为:

可以看到 Canvas 的宽就是参考分辨率的宽，高度是一个计算值。根据计算 scaleFactor 的不等式以及不等式的基本性质可以得到:

因此最终得到的 Canvas 的高度不小于参考分辨率的高度；又因为缩放后 Canvas 的宽是参考分辨率的宽，因此当 Screen Match Mode 设置为 ScreenMatchMode.Expand 时，缩放后的 Canvas 的大小永远不会比参考分辨率小。

Q: 放大流程到底是怎么样的？

A: 首先此时的参考分辨率的长宽都使用缩放系数放大，但是这只能满足较小的那个方向的适配，对于较大比例方向，Canvas 还需要进行拉伸扩大以适配屏幕。

Q: 那么什么情况下使用这个设置比较好了？

A: 由于此种情况下得到的 Canvas 的尺寸肯定是大于或等于参考分辨率的，因此适合屏幕分辨率两个方向都大于参考分辨率的情形；当屏幕的分辨率比参考分辨率要大，说明这种情况下需要的 UI 元素进行放大处理最好，因此 Screen Match Mode 设置为 ScreenMatchMode.Expand。

Q: 为什么此时要使用分辨率宽度比和高度比中较小的一个(这个比例就是 UI 元素的放大比例)？

A: 取小的比例合适是因为对布局来说更安全(元素放大导致的遮挡问题)。比如如果取了比较大的那个比例值作为 Canvas 的缩放系数，那么 UI 元素在水平和垂直两个方向上都会使用该比例进行放大处理，此时只是满足了较大比例的那个方向的适配，对于较小比例方向，Canvas 还需要通过缩小以适配屏幕，此时被放大的 UI 元素由于 Canvas 被缩小而位置发送变化就极有可能彼此遮挡；但是取较小比例时这种情况就不会发生，因为对于参考分辨率来说首先 Canvas 两个方向都以这个小的比例放大，此时不会遮挡，然后对于比例较大的方向通过拉伸适配屏幕，拉伸让这个方向上的元素彼此离得更远了，更不会遮挡。

• ScreenMatchMode.Shrink

用同样的计算方式也可得到在设置 ScreenMatchMode.Shrink 时，计算得到的 scaleFactor 是屏幕分辨率与参考分辨率宽高比中较大的一个，因此缩放后的 Canvas 的大小永远不会比参考分辨率大(证明过程和上面类似)。

Q: 缩小流程到底是怎么样的？

A: 首先此时的参考分辨率的长宽都使用缩放系数缩小，但是这只能满足较大比例的那个方向的缩小适配(比例越大这里缩小的像素就越小)，对于较小比例方向就缩小还不能达到适配屏幕的目的，因此 Canvas 还需要缩小。

Q: 那么什么情况下使用这个设置比较好了？

A: 由于此种情况下得到的 Canvas 的尺寸肯定是小于或等于参考分辨率的，因此适合屏幕分辨率两个方向都小于参考分辨率的情况；当屏幕的分辨率比参考分辨率要小，说明这种情况下需要的 UI 元素进行缩小处理最好，因此 Screen Match Mode 设置为 ScreenMatchMode.Shrink。

总结一下，当 Canvas Scaler 的 UI Scale Mode 设置为 Scale With Screen Size 时自适应屏幕的几种情况:

1. 屏幕分辨率比例和参考分辨率相同，但是比参考分辨率大。这种情况下，Canvas 尺寸保持参考分辨率的大小，但会缩放(大)来适配屏幕，UI 也会被放大。

2. 屏幕分辨率比例和参考分辨率相同，但是比参考分辨率小。在这种情况下，Canvas 尺寸同样也会保持参考分辨率的大小，但会缩(小)放来适配屏幕，UI 也会被缩小。

3. 屏幕分辨率比例和参考分辨率不同。在这种情况下，如果屏幕分辨率都两个方向都大于参考分辨率，使用 Expand 较好；如果屏幕分辨率两个方向都小于参考分辨率，使用 Shrink 更能达到自适应目的；当设置为 Match Width Or Height 时，可以通过调节 Match 参数来计算最佳缩放系数以自适应，这种方式最为灵活。

Constant Physical Size

使用这种模式，UI 元素的位置和大小信息都是用物理单位来表示。同样它也可以配置一些参数:

1. Physical Unit - 指定的武力单位。

2. Fallback Screen DPI - 设置的默认 DPI。

3. Default Sprite DPI - 设置的默认 Sprite DPI。

4. Reference Pixels Per Unit，同 Constant Pixel Size 中这个参数的设置。

在回到代码中，看到 HandleConstantPhysicalSize 方法，这个方法同样会计算 Scale Factor，代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

protected virtual void HandleConstantPhysicalSize()
{
    float currentDpi = Screen.dpi;
    float dpi = (currentDpi == 0 ? m_FallbackScreenDPI : currentDpi);
    float targetDPI = 1;
    switch (m_PhysicalUnit)
    {
        case Unit.Centimeters: targetDPI = 2.54f; break;
        case Unit.Millimeters: targetDPI = 25.4f; break;
        case Unit.Inches:      targetDPI =     1; break;
        case Unit.Points:      targetDPI =    72; break;
        case Unit.Picas:       targetDPI =     6; break;
    }

    SetScaleFactor(dpi / targetDPI);
    SetReferencePixelsPerUnit(m_ReferencePixelsPerUnit * targetDPI / m_DefaultSpriteDPI);
}

从代码中可以看到计算 Scale Factor 和 Reference Pixels Per Unit 都是使用 DPI 去计算的，targetDPI 根据使用的 Physical Unit 不同而不同。

World Space

当 Canvas 的 Render Mode 设置为 World Space，Canvas Scaler 用来控制 UI 元素的像素密度。

参考

• Unity Canvas
• Unity CanvasScaler

Event System 是 Unity 提供的内部 GameObject 响应输入(如键盘输入、鼠标输入、触摸输入等)事件的一种实现，它由多个组件组成，协同工作来实现整个事件通信。

组成 Event System 的组件包括:

• EventSystem 组件(本文内容)

• Input Modules

• Raycasters

EventSystem 组件

EventSystem 组件主要实现以下功能:

• 控制哪个 GameObject 被选中响应事件

• 控制选择使用哪一种 Input Module(同一时刻只有一个 Input Module 能处于激活状态)

• 管理 Raycasting

• 管理更新 Input Module

在 Unity 编辑器中，可以直接为场景添加 EventSystem 组件(一个场景通常只包含一个 EventSystem 组件)。可以直接设置一些属性以达到自定义需求，如下:

除了上面三个可以在编辑器中编辑的属性之外，还有很多其他特性，如: m_HasFocus 可以用来表示当前 EventSystem 是否处于拥有焦点状态，如果当前没有获得焦点，诸如 Input Module 相关的更新和激活方法不会被调用，事件处理方法 Process() 也不会进行。

EventSystem 组件也是一个 MonoBehaviour，因此它具有完整的 Unity 生命周期。除了有一些生命周期相关的回调，它也有一些其它比较重要的方法。

void UpdateModules() 方法

这个方法作用就是重新计算当前 m_SystemInputModules 中的 Input Modules，保证 m_SystemInputModules 中的 Input Module 都是出于激活状态的。这个方法会在 BaseInputModule 类的 OnEnable() 和 OnDisable() 方法中被调用，以注册或反注册对应的 Input Module。

void SetSelectedGameObject(GameObject selected, BaseEventData pointer) 方法

设置当前被选中的对象，属性 m_CurrentSelected 会被赋值为被选中的 GameObject。设置过程中，会给之前选中的对象发送 ExecuteEvents.deselectHandler 事件，给被设置的对象发送 ExecuteEvents.selectHandler 事件。这个方法会在需要设置 Selected 对象的时候被调用，如 InputField 组件接收到 Pointer Down 事件时，就会将其对应的 GameObject 设置为 Event System 当前选中对象(m_CurrentSelected)。方法代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public void SetSelectedGameObject(GameObject selected, BaseEventData pointer)
{
    if (m_SelectionGuard)
        return;

    m_SelectionGuard = true;
    if (selected == m_CurrentSelected)
    {
        m_SelectionGuard = false;
        return;
    }

    ExecuteEvents.Execute(m_CurrentSelected, pointer, ExecuteEvents.deselectHandler);
    m_CurrentSelected = selected;
    ExecuteEvents.Execute(m_CurrentSelected, pointer, ExecuteEvents.selectHandler);
    m_SelectionGuard = false;
}

void RaycastAll(PointerEventData eventData, List raycastResults) 方法

这个方法用来进行射线检测得到可以拦截事件的对象。方法实现很简单，使用 RaycasterManager 中的所有处于激活状态的 BaseRaycaster 进行检测，得到响应事件的对象。这个方法会在 PointerInputModule 类的 GetTouchPointerEventData 和 GetMousePointerEventData 方法中被调用，用于创建对应的可被分发拦截处理的具体事件。

bool IsPointerOverGameObject(int pointerId) 方法

用来判断指定 ID 的 Pointer 是否还在 EventSystem 的那个对象上。方法内部最终调用 PointerInputModule 类的 IsPointerOverGameObject 方法，在 PointerInputModule 类的方法实现也很简单，就是根据 pointerId 获取对应的 PointerEventData，然后判断如果 PointerEventData 中 pointerEnter 对应的 GameObject 不为空，这说明这个 ID 对应的 Pointer 还在 EventSystem 的对象上。

void Update() 方法

1. 首先调用了 TickModules() 去更新当前 Event System 中的所有的 Input Modules （调用了对应 Input Module 的 UpdateModule() 方法），这样 Input Module 中的 m_LastMousePosition 和 m_MousePosition 就得到了更新；

2. 如果当前 m_CurrentInputModule 不为空，就将当前 Event System 中挂载所有的 Input Modules 中的第一个可用且处于激活状态的 Input Module 设置给 m_CurrentInputModule；

3. 如果从来没有设置过 m_CurrentInputModule，就将挂载所有的 Input Modules 中的第一个可用 Input Module 设置给 m_CurrentInputModule；

4. 最后就会调用 Input Module 组件的 Process() 方法处理输入并产生事件、拦截处理事件。

上面的第二步和第三步中设置 m_CurrentInputModule 会调用 ChangeEventModule 方法。如果是切换 Input Module，则会反激活上一个 Input Module；还会激活当前要设置的 Input Module。代码如下:

1
2
3
4
5
6
7
8
9
10
11
12

private void ChangeEventModule(BaseInputModule module)
{
    if (m_CurrentInputModule == module)
        return;

    if (m_CurrentInputModule != null)
        m_CurrentInputModule.DeactivateModule();

    if (module != null)
        module.ActivateModule();
    m_CurrentInputModule = module;
}

void OnDisable() 方法

在这个方法中，主要就是将当前的 Input Module (m_CurrentInputModule) 反激活，调用了对应 InputModule 的 DeactivateModule() 方法。

前言

Input Modules 是 Event System 组成的一部分，负责产生抽象事件并分发事件到 GameObject 处理；在代码架构上它也是 Event System 中处理大部分业务逻辑的地方，可以高度配置化。不同的 Input Module 可以映射外部不同的硬件输入至 Unity Event System 中转化成能处理的事件，并管理这些事件的状态。Unity 中内置了 Standalone Input Module 和 Touch Input Module(已经被标记为 obsolete，现在由 Standalone Input Module 一并处理)。

本篇文章就来剖析 Input Modules 在 Unity 中的实现。

BaseInputModule

BaseInputModule 是所有关于 Input Module 类的最上层抽象类，它包含一些通用的成员变量(如 List<RaycastResult> m_RaycastResultCache 用于存储射线检测时的结果)和方法(如 abstract void Process()` 定义了 Input Module 的处理事件行为)。

BaseInputModule 是一个 MonoBehaviour 组件，所以当挂载在某个 GameObject 上运行时也会拥有 Unity MonoBehaviour 的生命周期。BaseInputModule 覆写了 OnEnable 和 OnDisable 方法，如下:

1
2
3
4
5
6

protected override void OnEnable()
{
    base.OnEnable();
    m_EventSystem = GetComponent<EventSystem>();
    m_EventSystem.UpdateModules();
}

1
2
3
4
5

protected override void OnDisable()
{
    m_EventSystem.UpdateModules();
    base.OnDisable();
}

在 enable 和 disable 的时候，都调用了 EventSystem 的 UpdateModules 方法去更新当前 EventSystem 中处于可用状态的 BaseInputModules。

BaseInputModule 是一个抽象类，因为它其中定义了唯一的一个抽象方法 Process，如下:

1

public abstract void Process();

这个方法就是不同 Input Module 子类实现具体事件抽象产生、分发的地方。

在 BaseInputModule 类还有一个比较重要的方法 HandlePointerExitAndEnter，用来处理当 pointer 的移出或进入某个 GameObject 时候，发送 enter 或 exit 事件，方法定义如下:

1

void HandlePointerExitAndEnter(PointerEventData currentPointerData, GameObject newEnterTarget);

方法具体实现中，首先检测是否需要处理退出。当没有 newEnterTarget 或者当前的 currentPointerData 的 pointerEnter 被清除，则给当前 currentPointerData 中所有的 hovered 对象发送 exit 事件并清除所有 hovered 对象；此时如果 newEnterTarget 不为空，说明是进入了新的 GameObject 对象，否则则将当前的 currentPointerData 的 pointerEnter 也置空并退出。代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13

if (newEnterTarget == null || currentPointerData.pointerEnter == null)
{
    for (var i = 0; i < currentPointerData.hovered.Count; ++i)
        ExecuteEvents.Execute(currentPointerData.hovered[i], currentPointerData, ExecuteEvents.pointerExitHandler);

    currentPointerData.hovered.Clear();

    if (newEnterTarget == null)
    {
        currentPointerData.pointerEnter = null;
        return;
    }
}

紧接着判断是否事件是否是在同一个 target 上面，如果是则返回。否则需要处理事件对象切换过程中事件的产生和分发，如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

if (currentPointerData.pointerEnter == newEnterTarget && newEnterTarget)
    return;

GameObject commonRoot = FindCommonRoot(currentPointerData.pointerEnter, newEnterTarget);

if (currentPointerData.pointerEnter != null)
{
    Transform t = currentPointerData.pointerEnter.transform;

    while (t != null)
    {
        if (commonRoot != null && commonRoot.transform == t)
            break;

        ExecuteEvents.Execute(t.gameObject, currentPointerData, ExecuteEvents.pointerExitHandler);
        currentPointerData.hovered.Remove(t.gameObject);
        t = t.parent;
    }
}

currentPointerData.pointerEnter = newEnterTarget;
if (newEnterTarget != null)
{
    Transform t = newEnterTarget.transform;

    while (t != null && t.gameObject != commonRoot)
    {
        ExecuteEvents.Execute(t.gameObject, currentPointerData, ExecuteEvents.pointerEnterHandler);
        currentPointerData.hovered.Add(t.gameObject);
        t = t.parent;
    }
}

上面的代码中，当当前进入的对象(newEnterTarget)和上次进入的对象(currentPointerData.pointerEnter)不同的时候，首先调用 FindCommonRoot 寻找它俩的共同父节点(commonRoot)，对从上次进入的对象到 commonRoot 之间所有的对象节点(不包括 commonRoot)依次发送 exit 事件；对从 newEnterTarget 到 commonRoot 之间所有的对象节点(不包括 commonRoot)依次发送 enter 事件。

除了上面介绍的几个(抽象)方法之外，BaseInputModule 类还有一些静态辅助方法和一些虚方法。静态辅助方法如: FindFirstRaycast 获取射线检测的第一个结果；方法 DetermineMoveDirection 可以根据输入值确定当期那的移动方向；FindCommonRoot 方法返回两个对象第一个共同拥有的节点。虚方法如: GetAxisEventData 根据输入数据产生一个 AxisEventData(可复用)；GetBaseEventData 方法用于复用当前实例的 m_BaseEventData。

PointerInputModule

PointerInputModule 继承自 BaseInputModule 类，它里面定义了一些常用的事件相关的成员变量和方法。类 StandaloneInputModule 和 TouchInputModule 继承自该类。

在成员变量中，有一个 m_PointerData 成员变量如下:

1

protected Dictionary<int, PointerEventData> m_PointerData = new Dictionary<int, PointerEventData>();

这个成员变量是当前 Input Module 中的事件的生产者的 ID 以及事件数据对象 PointerEventData 之间的一个映射。

在 PointerInputModule 类中，有几个比较重要的方法:

bool GetPointerData(int id, out PointerEventData data, bool create) 方法

用来根据某个事件生产者的 ID 获取 m_PointerData 映射的事件对象，返回 true 表示为该 ID 创建了一个新的事件，否则返回 false。

PointerEventData GetTouchPointerEventData(Touch input, out bool pressed, out bool released) 方法

根据一个 Touch 生成一个点击事件 PointerEventData，同时指定当前帧是否有按下(pressed)、释放(released)操作。如何根据一个 Touch 事件就确定当前是否有按下和释放操作了？下面就来看看该方法具体的实现。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

PointerEventData pointerData;
var created = GetPointerData(input.fingerId, out pointerData, true);

pointerData.Reset();

pressed = created || (input.phase == TouchPhase.Began);
released = (input.phase == TouchPhase.Canceled) || (input.phase == TouchPhase.Ended);

if (created)
    pointerData.position = input.position;

if (pressed)
    pointerData.delta = Vector2.zero;
else
    pointerData.delta = input.position - pointerData.position;

pointerData.position = input.position;

pointerData.button = PointerEventData.InputButton.Left;

if (input.phase == TouchPhase.Canceled)
{
    pointerData.pointerCurrentRaycast = new RaycastResult();
}
else
{
    eventSystem.RaycastAll(pointerData, m_RaycastResultCache);

    var raycast = FindFirstRaycast(m_RaycastResultCache);
    pointerData.pointerCurrentRaycast = raycast;
    m_RaycastResultCache.Clear();
}
return pointerData;

在该方法中，首先使用上面介绍过的 GetPointerData 方法去获取一个 PointerEventData，如果该 PointerEventData 是新创建的或者当前处理的 Touch 的 TouchPhase 等于 TouchPhase.Began (触摸开始阶段)，则 pressed 置为 true 表示按下；如果 TouchPhase 等于 TouchPhase.Canceled (触摸被动结束)或 TouchPhase.Ended (触摸主动结束)，则 released 被置为 true 表示释放。

紧接着，设置 PointerEventData 的相关信息。

• 如果是新创建的事件实例，则 PointerEventData 的 position 就是 Touch 的 position；

• 如果当前帧被判定为有按下操作，则与上一帧的事件点击位置的变化量 delta 为 0，否则事件点击位置变化量就是 input.position - pointerData.position；

• 接着更新 position 为 Touch 的 position；鼠标按键 button 被置为 PointerEventData.InputButton.Left;

• 最后是为当前事件关联的射线检测结果 pointerCurrentRaycast 设置值，如果当前处理的 Touch 的被动中断(input.phase == TouchPhase.Canceled)，pointerCurrentRaycast 被设置为一个新的 RaycastResult，如没有被中断则调用 EventSystem 的 RaycastAll 方法进行射线检测，并将射线检测的第一个结果作为 pointerCurrentRaycast 的值。

设置结束，返回该 PointerEventData。

MouseState GetMousePointerEventData(int id) 方法

用于获取当前的 MouseState。在分析这个方法之前，先来看看再 PointerInputModule 类中定义的三个内部类。

• MouseButtonEventData 类

  这个类中包含一个 PointerEventData.FramePressState 类型的 buttonState 变量，表示当前帧 button press 的状态。它是一个枚举类型，有 Pressed(按下)、Released(释放)、PressedAndReleased(按下且释放)和 NotChanged(状态同上一帧没有变化)四个值；类中还包含另一个 PointerEventData 类型的变量 buttonData，代表着当前关联事件数据对象。该类中也定义了 bool PressedThisFrame() 和 bool ReleasedThisFrame() 两个方法判断当前帧中 button 是否被按下和是否被释放。

• ButtonState 类

  ButtonState 类更加单，仅包含两个成员变量: PointerEventData.InputButton 类型的成员变量 m_Button 以及 MouseButtonEventData 类型的 m_EventData。

• MouseState 类

  MouseState 包含一个 ButtonState 列表，用于同时管理多个 ButtonState。可以使用 bool AnyPressesThisFrame() 和 bool AnyReleasesThisFrame() 方法来判断当前帧是否有 button 被按下或被释放。

看完这几个简单的内部类，再回到 GetMousePointerEventData 方法。这个方法生成 PointerEventData 的过程同 GetTouchPointerEventData 方法相似，不同的是其 position 赋值是当前类(继承自 BaseInputModule)的 input 所在的 mousePosition 值，而 GetTouchPointerEventData 方法中使用的是 Touch 的 position；另一处不同是在当前方法中，会生成三个 PointerEventData 分别给 InputButton 中的 Left、Right 和 Middle 对应的三个 ButtonState 使用，生成好的数据会赋值给当前类的 m_MouseState 变量。

virtual void ProcessMove(PointerEventData pointerEvent) 方法

虚方法 ProcessMove 用于处理“移动”事件，当在一个 GameObject 上产生按下事件并且没有释放则会产生“移动”事件。该方法代码很简单，如果此时 Cursor.lockState 处于 CursorLockMode.Locked 状态，那么目标移动对象会被置为空，否则被设置为当前射线检测得到的对象；移动过程中需要 BaseInputModule 类的 HandlePointerExitAndEnter 方法检测是否需要改变事件 hover 的对象。

virtual void ProcessDrag(PointerEventData pointerEvent) 方法

“移动”事件处理完之后，紧接着虚方法 ProcessDrag 处理“拖拽”事件。代码如下:

如果当前 PointerEventData 还不是处于 dragging 并且可以开始拖拽，则为 PointerEventData 的 pointerDrag 发送 ExecuteEvents.beginDragHandler 事件。

1
2
3
4
5
6

if (!pointerEvent.dragging
    && ShouldStartDrag(pointerEvent.pressPosition, pointerEvent.position, eventSystem.pixelDragThreshold, pointerEvent.useDragThreshold))
{
    ExecuteEvents.Execute(pointerEvent.pointerDrag, pointerEvent, ExecuteEvents.beginDragHandler);
    pointerEvent.dragging = true;
}

在开始拖拽之前，将所有有关 press 的状态删除，同时清除 selection。如下:

1
2
3
4
5
6
7
8
9
10

if (pointerEvent.pointerPress != pointerEvent.pointerDrag)
{
    ExecuteEvents.Execute(pointerEvent.pointerPress, pointerEvent, ExecuteEvents.pointerUpHandler);

    pointerEvent.eligibleForClick = false;
    pointerEvent.pointerPress = null;
    pointerEvent.rawPointerPress = null;
}
// 发送拖拽事件
ExecuteEvents.Execute(pointerEvent.pointerDrag, pointerEvent, ExecuteEvents.dragHandler);

在 PointerInputModule 类中，除了上面的几个比较重要的方法，还有一些简单的辅助方法或者其他方法，如 DeselectIfSelectionChanged 用来在 Selection 改变的时候反注册 Event System 的 Selected GameObject (最终调用的也是 EventSystem 的 SetSelectedGameObject 方法)；再比如 ClearSelection 用来清除当前所有缓存的 PointerEventData 中的 Selection(发送 ExecuteEvents.pointerExitHandler 事件，清空 hovered)。

到这里可能会感觉全是干涩的代码分析，没有应用到真正的 Event System 的流程中。那么接下来，就从 StandaloneInputModule 类开始，看看一个具体的 Input Module 是如何工作的以及再来看看上面讲到过的方法具体的应用。

Standalone Input Module

这种模式是为类似鼠标、控制器等硬件(也包括触摸设备)的输入抽象设计的。根据不同的输入，将会转换成为 Unity 内不同的抽象事件被分发出去，然后被拦截处理。

当产生事件时，自定义配置的 Raycaster 将会计算拦截事件的元素对象；同时，对于 Navigation events，也可以设置要检测的名称。StandaloneInputModule 类有以下属性可以自定义配置:

• Vertical / Horizontal 轴用于键盘/控制器的导航性事件

• Submit / Cancel button 用来发送 submit 和 cancel 事件

• 事件和事件之间有超时机制，每秒中最多有 Input Actions Per Second 个事件

究竟 Standalone Input Module 是如何应用到 EventSystem 流程中的了？前面在解析 BaseInputModule 类时提到过，在 OnEnable 方法中会将当前绑定的 Input Module 组件和 EventSystem 关联起来(通过 EventSystem 类的 UpdateModules 方法)；然后在 EventSystem 每一帧更新中，都会调用 Input Module 的 Process() 方法，这样 Input Module 就开始运作起来。

void Process() 方法

StandaloneInputModule 类覆写了 Process() 方法，并在其中实现了各类事件的处理。所以接下来就从 StandaloneInputModule 类的 Process() 入手开始分析。

首先是处理当前被 Selected 对象的 Update 事件，代码如下:

1

bool usedEvent = SendUpdateEventToSelectedObject();

SendUpdateEventToSelectedObject() 方法首先判断当前 EventSystem Selected 的对象是否为空，不为空则获取当前事件数据 m_BaseEventData，然后发送 ExecuteEvents.updateSelectedHandler 事件供拦截处理，返回结果表示当前的事件数据 m_BaseEventData 是否被使用。

然后使用 ProcessTouchEvents() 方法处理 Touch 事件，方法返回 true 表示处理了 Touch 事件；

该方法主要是处理 Touch 事件。对于当前 Input 中的每个 Touch 事件，都会执行以下操作: 首先调用 PointerInputModule 中的 GetTouchPointerEventData 方法根据 Touch 事件获取一个 PointerEventData，并判断当前 Touch 的状态是 pressed 还是 released 状态。接着调用 ProcessTouchPress 方法处理 Touch 按下，下面就来看看处理 Touch press 的过程: 具体下来就有 press 和 release 两大块的实现。

• press 处理

如果方法传入参数 pressed 为 true，表示当前事件是新创建或 Touch phase 处于 TouchPhase.Began 阶段，所以需要处理 press 相关的事件。在处理 press 中，首先初始化了当前 PointerEventData 的相关值，接着调用了 PointerInputModule 中的 DeselectIfSelectionChanged 方法检测是否需要删除当前 EventSystem 的 Selected 对象(比如点击了新的对象，就会删除旧的 Selected 对象，然后由当前的 press 决定新的 Selected 对象)。处理 press 包含如下几个阶段:

1. 如果当前 PointerEventData 的 pointerEnter 对象和射线检测的对象不是同一个，那么就会调用 BaseInputModule 类的 HandlePointerExitAndEnter 方法给射线检测到的对象及其祖先发送 ExecuteEvents.pointerEnterHandler 事件。

2. 处理完 pointer enter，紧接着处理 pointer down 事件；从当前射线检测到的对象开始搜寻能处理 ExecuteEvents.pointerDownHandler 事件的对象。代码如下:

1

var newPressed = ExecuteEvents.ExecuteHierarchy(currentOverGo, pointerEvent, ExecuteEvents.pointerDownHandler);

3. 若未能处理 press，接着寻找能处理 click 事件的对象。代码如下:

1
2

if (newPressed == null)
    newPressed = ExecuteEvents.GetEventHandler<IPointerClickHandler>(currentOverGo);

4. 得到 newPressed 对象之后，接着对 PointerEventData 相关属性赋值。然后开始处理 ExecuteEvents.initializePotentialDrag 事件，代码如下:

1
2
3
4

pointerEvent.pointerDrag = ExecuteEvents.GetEventHandler<IDragHandler>(currentOverGo);

if (pointerEvent.pointerDrag != null)
    ExecuteEvents.Execute(pointerEvent.pointerDrag, pointerEvent, ExecuteEvents.initializePotentialDrag);

到这里，press 阶段相关的事件就处理完毕。接下来就是 release 相关部分的实现。

• release 处理

如果方法传入参数 released 为 true，表示当前 Touch 已经被系统中断或已经结束，所以需要处理 release 相关会触发的事件。

1. 对 press 的对象进行 ExecuteEvents.pointerUpHandler 事件处理。代码如下:

1

ExecuteEvents.Execute(pointerEvent.pointerPress, pointerEvent, ExecuteEvents.pointerUpHandler);

2. 紧接着寻找是否有处理 pointer click 事件的对象，如果有且该对象是当前 PointerEventData 的 pointerPress，那么就处理 ExecuteEvents.pointerClickHandler 事件；否则如果当前 PointerEventData 的 pointerDrag 不为空且正在拖拽中，就处理 ExecuteEvents.dropHandler 事件。

1
2
3
4
5
6
7
8
9
10

var pointerUpHandler = ExecuteEvents.GetEventHandler<IPointerClickHandler>(currentOverGo);

if (pointerEvent.pointerPress == pointerUpHandler && pointerEvent.eligibleForClick)
{
    ExecuteEvents.Execute(pointerEvent.pointerPress, pointerEvent, ExecuteEvents.pointerClickHandler);
}
else if (pointerEvent.pointerDrag != null && pointerEvent.dragging)
{
    ExecuteEvents.ExecuteHierarchy(currentOverGo, pointerEvent, ExecuteEvents.dropHandler);
}

3. 最后根据相应条件处理结束拖拽(ExecuteEvents.endDragHandler)和退出(ExecuteEvents.pointerExitHandler)事件。

1
2
3
4

if (pointerEvent.pointerDrag != null && pointerEvent.dragging)
    ExecuteEvents.Execute(pointerEvent.pointerDrag, pointerEvent, ExecuteEvents.endDragHandler);

ExecuteEvents.ExecuteHierarchy(pointerEvent.pointerEnter, pointerEvent, ExecuteEvents.pointerExitHandler);

到这里，release 相关部分也完成了。

处理完 Touch press 相关事件后，然后根据 released 状态，如果为 false (未释放)则继续调用 ProcessMove 和 ProcessDrag 方法分别处理移动和拖拽事件(这两个事件的处理是直接使用 PointerInputModule 类中的方法，上面已经讲解过)，如果已经 released 就将得到的 PointerEventData 从当前的 Input Module 中的 m_PointerData 移除。最后返回是否处理了至少一个 Touch 事件。

上图示 Touch 事件处理流程

如果 Touch 事件处理失败并且检测到了鼠标事件，那么就使用 ProcessMouseEvent() 方法处理鼠标事件；

ProcessMouseEvent() 方法用来处理所有的鼠标事件，它内部调用了重载的 ProcessMouseEvent(int id) 方法处理。鼠标事件的处理过程中，首先调用 PointerInputModule 类的 GetMousePointerEventData 方法(上面分析过该方法)获得 MouseState 对象；然后根据得到的 MouseState 对象调用 ProcessMousePress 方法处理鼠标左键的按下，同样下面就来看看处理鼠标 press 的过程: 具体下来也是 press 和 release 两大块的实现。

• 鼠标 press 处理和 Touch press 处理时使用 ProcessTouchPress 方法内部实现基本一致，但有一点不同就是: 在进行检测是否需要删除当前 EventSystem 的 Selected 对象之后，紧接着不会调用 BaseInputModule 类的 HandlePointerExitAndEnter 方法给射线检测到的对象及其祖先发送 ExecuteEvents.pointerEnterHandler 事件(这一步被移至 release 阶段处理)。

• release 处理也和 Touch 处理时 ProcessTouchPress 方法中 release 阶段一致，只不过在该阶段最后一步，鼠标事件 enter 和 exit 会被重新刷新。因此在鼠标事件的 press 处理中，在 release 阶段最后一步，当前射线检测到的对象及其祖先对象才会收到 ExecuteEvents.pointerEnterHandler 事件，上一个触发鼠标事件的对象(如不为空)及其相关祖先对象才会接收到 ExecuteEvents.pointerExitHandler 事件。

处理完鼠标左键 press，接下来就调用 PointerInputModule 类的 ProcessMove 方法处理移动事件，前面讲到过 ProcessMove 方法调用 BaseInputModule 类的 HandlePointerExitAndEnter 方法，从而当前射线检测的对象会接收到 ExecuteEvents.pointerExitHandler 事件。

处理完移动事件，最后就是处理鼠标左键的拖拽事件，调用 PointerInputModule 类的 ProcessDrag 方法处理。这个方法之前分析过，这里不再讲解。

到这里鼠标左键处理完毕，接着使用同样的方法对鼠标右键和中间键进行 press 和 drag 处理(不需要进行 move 事件处理)。最后在 ProcessMouseEvent 方法中处理的就是滚轮事件，代码如下:

1
2
3
4
5

if (!Mathf.Approximately(leftButtonData.buttonData.scrollDelta.sqrMagnitude, 0.0f))
{
    var scrollHandler = ExecuteEvents.GetEventHandler<IScrollHandler>(leftButtonData.buttonData.pointerCurrentRaycast.gameObject);
    ExecuteEvents.ExecuteHierarchy(scrollHandler, leftButtonData.buttonData, ExecuteEvents.scrollHandler);
}

当 scrollDelta 不近似为 0 时，就发送 ExecuteEvents.scrollHandler 事件。

上图示 Mouse 事件处理流程

Touch / 鼠标事件处理完毕后，紧接着如果当前需要处理 Navigation 事件。

因为在处理 Touch / 鼠标事件时会改变当前 Selected 对象，所以要先处理 Touch / 鼠标事件，然后按需处理Navigation 事件。

首先处理 Navgation 中当前 Selected 对象的 Move 事件，代码如下:

1
2

if (!usedEvent)
    usedEvent |= SendMoveEventToSelectedObject();

在上面处理 ExecuteEvents.updateSelectedHandler 事件时，如果收到事件的对象没有使用 BaseInputModule 中的事件 m_BaseEventData，那么就开始对当前 EventSystem Selected 的对象处理 move 事件，调用 SendMoveEventToSelectedObject() 方法，这个方法代码主要就是处理 move 事件。