Ryuu 的个人博客

一个计算机初学者

发表于 更新于 分类于 本文字数： 265 阅读时长 ≈ 1 分钟

简述

单例 (Singleton) 模式提供一个可以全局访问的实例，并保证该类仅有一个实例。

设计模式类型：创建型

实现

1.懒汉 多线程不安全

1
2
3
4
5
6
7
8
9
10
11
12
13
public class Singleton {
    private static Singleton instance;

    private Singleton() {
    }

    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

2.懒汉 多线程安全

1
2
3
4
5
6
7
8
9
10
11
12
13
public class Singleton {
    private static Singleton instance;

    private Singleton() {
    }

    public static synchronized Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

3.双检锁

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class Singleton {
    private volatile static Singleton singleton;

    private Singleton() {
    }

    public static Singleton getSingleton() {
        if (singleton == null) {
            synchronized (Singleton.class) {
                if (singleton == null) {
                    singleton = new Singleton();
                }
            }
        }
        return singleton;
    }
}

4.饿汉

1
2
3
4
5
6
7
8
9
10
public class Singleton {
    private static final Singleton instance = new Singleton();

    private Singleton() {
    }

    public static Singleton getInstance() {
        return instance;
    }
}

5.静态内部类

1
2
3
4
5
6
7
8
9
10
11
12
public class Singleton {
    private static class SingletonHolder {
        private static final Singleton INSTANCE = new Singleton();
    }

    private Singleton() {
    }

    public static Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }
}

6.枚举

1
2
3
public enum Singleton {
    INSTANCE;
}

选择

不建议使用 1 和 2

不考虑继承问题使用 6 枚举

单例是派生类，确定会使用，建议使用 4 饿汉

单例是派生类，且不确定单例是否会使用，考虑 3 双检锁 或 5 静态内部类

发表于 更新于 分类于 本文字数： 2.7k 阅读时长 ≈ 10 分钟

委托是类

委托是类，C# 提供了 delegate 关键字，使得用户能简单的声明委托。编译器及 CLR 做了大量的工作来隐藏委托的复杂性。[1]

1
internal delegate void FeedBack(int value);

编译器为如上的委托声明定义一个完整的类：

1
2
3
4
5
6
7
8
9
10
11
12
internal class FeedBack : System.MulticastDelegate
{
    // 构造器(Constructor)
    public FeedBack(object @object, IntPtr method);
    
    // 委托调用 [2]
    public virtual void Invoke(int value);

    // 委托异步调用
    public virtual IAsyncResult BeginInvoke(int value, AsyncCallback asyncCallback, object @object);
    public virtual void EndInvoke(IAsyncResult result);
}

可使用 ILDasm.exe 打开生成的程序集，查看这个自动生成的类。

编译器定义了 FeedBack 类，其派生自 FCL (Framework Class Library) 中的 System.MulticastDelegate 类 (所有的委托都派生自 MulticastDelegate，MulticastDelegate 派生自 Delegate)。

MulticastDelegate

所有的委托都派生自 MulticastDelegate，所以它们继承了 MulticastDelegate 的字段、属性与方法。在这些成员中，有三个非公共字段是最重要的：

字段 类型 说明
_target (Delegate 类的字段) System.Object 若委托对象包装静态方法时，此字段为 null
若委托对象包装实例方法时，此字段引用回调方法需要操作的对象 (实例方法所在的对象)
_methodPtr (Delegate 类的字段) System.IntPtr 根据平台而定的整数类型 (所以上文 ILDasm 中的显示是 native int)，CLR 使用它标记需要回调的方法
_invocationList System.Object 此字段通常为 null。构造委托链时，引用一个委托数组

委托的构造器有两个参数，一个是对象引用 (System.Object)，另一个则是根据平台而定的整型 (System.IntPtr)。C# 编译器构造委托时，会分析源码以确定引用的对象及方法。对象引用被传给构造器的 object 参数，标识方法的特殊 IntPtr 值 (从 MethodDef 或 MemberRef 元数据 token 获得) 被传给构造器的 method 参数。对于静态方法，为 object 参数传递 null。构造器将这两个实参分别保存于 _target 及 _methodPtr。此外，构造器将 _invocationList 设为 null。

委托链/多播

委托链是委托对象的集合。

合并

调用 Delegate.Combine(Delegate a, Delegate b) 方法对两个委托进行合并。

1
fbChain = (Feedback)Delegate.Combine(fbChain, fb1);

移除

调用 Delegate.Remove(Delegate source, Delegate value) 方法对两个委托进行合并。

1
fbChain = (Feedback)Delegate.Remove(fbChain, fb1);

原理

详情请参阅 Reference Source。

Combine

  • 若一个委托为 null

    返回非 null 委托

  • 若两个委托为 null

    返回 Combine 的第二个参数 (当然返回的也是 null)

  • 若都不为 null

    进行委托合并

    1. 判断两委托类型是否相同，不同则抛出 ArgumentException
    2. 合并两个委托对象中的委托 (包括委托链中的委托) (Object[] : resultList) (使用 for 遍历实现)
    3. 统计两个委托对象中的委托数 (int: invocationCount) (委托链不为空则统计委托链中的委托)
    4. 根据 resultList 及 invocationCount 构建新的委托对象并返回

Remove

注意，若 Remove 的目标为委托链，则该委托链需为当前操作委托对象委托链的连续子列表。[3]

  • 若指定需要去除的委托为空，直接返回当前委托
  • 若指定需要去除的委托不为空，在当前委托及其委托链中寻找目标委托或目标委托链，剔除并返回
    • 结果是委托链则构建新委托并返回
    • 结果是单一委托则直接返回该委托

不要定义过多的委托

Microsoft 在刚开始开发 .NET Framework 的时候引入了委托的概念。开发人员在 FCL 中添加类时，凡是有回调方法的地方都定义了新的委托类型。随时间的推移，他们定义的委托越来越多。仅在 MSCorLib.dll 中，就有接近 50 个委托类型，例如：

1
2
3
4
5
6
7
public delegate void TryCode(Object userData);
public delegate void WaitCallback(Object state);
public delegate void TimerCallback(Object state);
public delegate void ContextCallback(Object state);
public delegate void SendOrPostCallback(Object state);
public delegate void ParameterizedThreadStart(Object obj);
...

以上的示例委托，实际上都是一样的：这些委托引用的方法都是获取一个 Object 返回 void。没有必要定义这么多委托，定义一个就够了。

现在的 .NET Framework 支持泛型 (C# 2.0 版本引入)，只需要几个泛型委托，就能表示多达16个参数的方法：

  • 从无参，到至多16个参数，返回值为 void 的 Action 委托：

    1
    2
    3
    4
    5
    public delegate void Action(); // (这个不是泛型委托)
    public delegate void Action<in T>(T obj);
    public delegate void Action<in T1, in T2>(T1 arg1, T2 arg2);
    ...
    public delegate void Action<in T1, ... , in T16>(T1 arg1, ... , T16 arg16);

  • 从无参，到至多16个参数，返回值为 TResult 的 Func 委托：

    1
    2
    3
    4
    public delegate TResult Func<out TResult>();
    public delegate TResult Func<in T, out TResult>(T arg);
    ...
    public delegate TResult Func<in T1, ... , in T16, out TResult>(T1 arg1, ... , T16 arg16);

建议尽量使用以上的委托类型，而不是定义更多的委托类型。这样能减少系统中的类型数量，简化代码。

但若需使用 ref 或 out 关键字以传递引用的方式传递参数，可能不得自定义委托：

1
delegate void Foo(ref int bar);

event 关键字

event 关键字用于在发布类 (publisher class) 中声明事件。这是一种特殊的多播委托，仅能从声明事件的类或结构（发布类）中对其进行调用，否则产生编译器：event 的委托仅能作为 += 或 -= 的左值 (除非在其声明的类或结构中)。 如果其他类或结构订阅该事件，则在发布类引发该事件时，将调用其事件处理程序方法。 有关详细信息和代码示例，请参阅事件和委托。

1
public event Action action;

EventHandler

EventHandler 委托是一个预定义的委托，专门表示不生成数据的事件的事件处理程序方法。 

1
public delegate void EventHandler(object? sender, EventArgs e);

如果事件生成数据，则必须使用泛型 EventHandler 委托类。

1
public delegate void EventHandler<TEventArgs>(object? sender, TEventArgs e);

委托的简化语法

Combine 与 Remove 的简化

C# 为委托重载 += 调用 Combine ，重载 -= 调用 Remove ，简化了委托链的构造。[4]

1
2
3
4
action1 = (Action) Delegate.Combine(action1, action2);
action1 += action2;
Delegate.Remove(action1, action2);
action1 -= action2;

不需要显式构造委托对象

仅仅是为了指定委托地址就构建一个对象显得有些奇怪，实际上构建委托对象是 CLR 的要求，该对象是包装器，可保证被包装的方法只能以类型安全的方式调用。C# 简化了委托的构建过程，不需要用户显示的使用 new 关键字进行委托的构造。

  • 未显式构造委托对象：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    public static void Main(string[] args)
    {
        Action action = PrintAction;
        action.Invoke();
    }

    private static void PrintAction()
    {
        Console.WriteLine("Action");
    }

  • 显式构造委托对象：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    // DON'T DO THIS
    public static void Main(string[] args)
    {
        Action action = new Action(PrintAction);
        action.Invoke();
    }

    private static void PrintAction()
    {
        Console.WriteLine("Action");
    }

对比显式构造与非显式构造的 IL code，他们都会构造一个 Action 委托实例。

不需要定义回调方法 (使用 lamdba 表达式)

不需要因构造委托而定义一个方法：

1
2
3
4
5
6
7
8
9
10
11
public static void Main(string[] args)
{
    Action action = PrintAction;
    action.Invoke();
}

// NOT NEED
private static void PrintAction()
{
    Console.WriteLine("Action");
}

可以使用 lamdba 表达式简化回调：[5]

1
2
3
4
5
public static void Main(string[] args)
{
    Action action = () => Console.WriteLine("Action");
    action.Invoke();
}

局部变量不需要手动包装到类中即可传递给回调方法

有时可能希望回调代码引用类中定义的其他成员或方法中的局部参数：

1
2
3
4
5
6
7
8
9
10
11
internal class Program
{
    private static int bar = 21;

    public static void Main(string[] args)
    {
        int foo = 21;
        Action action = () => Console.WriteLine(foo + bar); // Closure allocation: 'foo' variable
        action.Invoke();
    }
}

实际上 lamdba 表达式主体的代码在一个单独的方法中 (CLR 的要求)。C# 通过自动辅助类实现闭包 (closure) [6]。在辅助类中，为需要传递给回调的每个值都定义一个字段。将回调方法定义为其实例方法。

构建回调方法实际上也构造了辅助类实例，使用方法中的局部变量的值初始化该实例中的字段，最后构造委托对象并绑定到该辅助对象的实例方法。

委托与反射

开发者可以在不知道回调方法的原型时使用回调。使用 MethodInfo.CreateDelegate，可在编译期不知道委托的所有必要信息的情况下创建委托：

1
2
3
4
// 构造包含静态方法的委托
public virtual Delegate CreateDelegate (Type delegateType);
// 构造包含实例方法的委托 (target 引用 this 实参)
public virtual Delegate CreateDelegate (Type delegateType, object? target);

创建完成后可用 Delegate.DynamicInvoke(Object[]) 调用它们：

1
2
// 调用委托并传递参数
public object? DynamicInvoke (params object?[]? args);

使用反射 API 获取引用了回调方法的 MethodInfo 对象，调用 CreateDelegate 构造委托 (如果是实例方法则需要传递 target 参数，指定其 this 参数)。

使用 DynamicInvoke 方法对委托对象的回调方法进行调用。DynamicInvoke 可传递一组参数，其在内部保证传递的参数与回调方法期望的参数兼容，兼容则调用回调方法，否则抛出 ArgumentException。若参数数不匹配，则抛出 TargetParameterCountException。

示例：

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
internal class Foo
{
    public static void StaticMethod() => Console.WriteLine(42);

    public void NonStaticMethod() => Console.WriteLine(42);

    public static void MethodWithPara(int num) => Console.WriteLine(num);

}

internal class Program
{
    public static void Main(string[] args)
    {
        Foo delegateReflectionTest = new Foo();
        MethodInfo nonStaticMethodInfo = delegateReflectionTest.GetType().GetMethod("NonStaticMethod");
        Delegate delegate1 = nonStaticMethodInfo?.CreateDelegate(typeof(Action), delegateReflectionTest);
        delegate1?.DynamicInvoke();
        MethodInfo staticMethodInfo = delegateReflectionTest.GetType().GetMethod("StaticMethod");
        Delegate delegate2 = staticMethodInfo?.CreateDelegate(typeof(Action));
        delegate2?.DynamicInvoke();
        MethodInfo methodInfoWithPara = delegateReflectionTest.GetType().GetMethod("MethodWithPara");
        Delegate delegate3 = methodInfoWithPara?.CreateDelegate(typeof(Action<int>));
        delegate3?.DynamicInvoke(42);
        }
    }
}

参阅

Ildasm.exe(IL 反汇编程序)

一般，该工具位于 NETFX 4.7.2 Tools 中

C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\x64\ildasm.exe

如何合并委托（多播委托）- C# 编程指南 | Microsoft Docs

- - 和 -= 运算符 - C# 参考 | Microsoft Docs

+ 和 += 运算符 - C# 参考 | Microsoft Docs

注释

[1] 因此，可以定义类的地方，就可以定义委托。

[2] 这里把 Invoke 翻译为调用。但是要清楚 Invoke 和 Call 的区别，执行委托方法不是直接执行目标方法，而是从委托处援引 (Invoke) 目标方法执行。

[3] 实现细节请参阅 Reference Source Multicastdelegate ，算法为移除目标数组中的连续子序列

- - 和 -= 运算符 - C# 参考 | Microsoft Docs (委托删除) 中的示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Action a = () => Console.Write("a");
Action b = () => Console.Write("b");

var abbaab = a + b + b + a + a + b;
var aba = a + b + a;

var first = abbaab - aba;
first();  // output: abbaab
Console.WriteLine();
Console.WriteLine(object.ReferenceEquals(abbaab, first));  // output: True

Action a2 = () => Console.Write("a");
var changed = aba - a;
changed();  // output: ab
Console.WriteLine();
var unchanged = aba - a2;
unchanged();  // output: aba
Console.WriteLine();
Console.WriteLine(object.ReferenceEquals(aba, unchanged));  // output: True

[4] 可通过查看 IL code 验证这点：

[5] 请参阅 => 运算符 - C# 参考 | Microsoft Docs (表达式主体定义)

[6] 捕获上下文的外部变量以在回调方法中使用。闭包有对外部变量的引用，所以可能导致外部变量所在的对象声明周期延长。

发表于 更新于 分类于 本文字数： 1.3k 阅读时长 ≈ 5 分钟

可能有人认为相比于 ForTest1，ForTest2 存储了数组的 Length，少了对于数组属性的频繁调用，会有更好的性能表现。

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
using System;

namespace JITPropertyAccessInFor
{
    internal static class Program
    {
        public static void Main(string[] args)
        {
        }

        private static void Test1()
        {
            var a = new int[5];
        }

        private static void ForTest1()
        {
            var a = new int[5];
            for (var i = 0; i < a.Length; i++)
            {
                Console.WriteLine(a[i]);
            }
        }

        private static void ForTest2()
        {
            var a = new int[5];
            int len = a.Length;
            for (var i = 0; i < len; i++)
            {
                Console.WriteLine(a[i]);
            }
        }
    }
}

以下 是 上段代码编译出的 IL code：(以下所述栈均为操作数栈 (Operand stack))

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
.method private hidebysig static void  ForTest1() cil managed
{
  // Code size       30 (0x1e)
  .maxstack  2 // 栈最大深度
  .locals init ([0] int32[] a, // 变量声明 (局部变量表)
           [1] int32 i)
  IL_0000:  ldc.i4.5 // int32 5 入栈 (声明的数组大小)
  IL_0001:  newarr     [mscorlib]System.Int32 // 创建0基一维数组的对象引用入栈
  IL_0006:  stloc.0 // 出栈 置于局部变量表0位置 (初始化数组完毕)
  IL_0007:  ldc.i4.0 // int32 0 入栈 (i = 0)
  IL_0008:  stloc.1 // 出栈 置于局部变量表1位置 (i = 0)
  IL_0009:  br.s       IL_0017 // 无条件地将控制转移到目标指令(短格式)(至 for 中判断开始位置)
  IL_000b:  ldloc.0 // 局部变量表0位置变量入栈 (数组元素入栈)
  IL_000c:  ldloc.1 // 局部变量表1位置变量入栈 (i 入栈)
  IL_000d:  ldelem.i4 // 按指令指定类型(i4)，将指定数组索引中的元素入栈
  IL_000e:  call       void [mscorlib]System.Console::WriteLine(int32) // 调用由传递的方法说明符指示的方法 (打印a[i])
  IL_0013:  ldloc.1 // 局部变量表1位置变量入计算栈 (i 入栈) (i++ 开始)
  IL_0014:  ldc.i4.1 // int32 1 入栈
  IL_0015:  add // 出栈两次,出栈值相加，结果入栈
  IL_0016:  stloc.1 // 出栈 置于局部变量表1位置 (i++ 结束)
  IL_0017:  ldloc.1 // 局部变量表1位置变量入栈 (i 入栈) (for 中判断开始位置)
  IL_0018:  ldloc.0 // 局部变量表0位置变量入栈 (a 入栈,准备获取数组长)
  IL_0019:  ldlen // 将0基一维数组的元素数目推送到计算栈上。(数组长入栈)
  IL_001a:  conv.i4 // 将栈顶元素转换为 int32 类型
  IL_001b:  blt.s      IL_000b // 判断计算栈顶两值大小(计算栈出栈两次，后出栈的是第一个值)。若第一个值小于第二个值，将控制转移到目标指令 (短格式)。
  IL_001d:  ret // 从当前方法返回
} // end of method Program::ForTest1
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
.method private hidebysig static void  ForTest2() cil managed
{
  // Code size       32 (0x20)
  .maxstack  2 // 栈最大深度
  .locals init ([0] int32[] a, // 变量声明 (局部变量表)
           [1] int32 len,
           [2] int32 i)
  IL_0000:  ldc.i4.5 // int32 5 入栈 (声明的数组大小)
  IL_0001:  newarr     [mscorlib]System.Int32 // 创建0基一维数组的对象引用入栈
  IL_0006:  stloc.0 // 出栈 置于局部变量表0位置 (初始化数组完毕)
  IL_0007:  ldloc.0 // 局部变量表1位置变量入栈 (a 入栈,准备获取数组长)
  IL_0008:  ldlen // 将0基一维数组的元素数目推送到计算栈上。(数组长入栈)
  IL_0009:  conv.i4 // 将栈顶元素转换为 int32 类型
  IL_000a:  stloc.1 // 出栈 置于局部变量表1位置 (len = a.Length)
  IL_000b:  ldc.i4.0 // int32 0 入栈 (声明的数组大小)
  IL_000c:  stloc.2 // 出栈 置于局部变量表2位置 (i = 0)
  IL_000d:  br.s       IL_001b // 无条件地将控制转移到目标指令(短格式)(至 for 中判断开始位置)
  IL_000f:  ldloc.0 // 局部变量表0位置变量入栈 (a 入栈)
  IL_0010:  ldloc.2 // 局部变量表2位置变量入栈 (i 入栈)
  IL_0011:  ldelem.i4 // 按指令指定类型(i4)，将指定数组索引中的元素入栈
  IL_0012:  call       void [mscorlib]System.Console::WriteLine(int32) // 调用由传递的方法说明符指示的方法 (打印a[i])
  IL_0017:  ldloc.2 // 局部变量表2位置变量入栈 (i 入栈) (i++ 开始)
  IL_0018:  ldc.i4.1 // int32 1 入栈
  IL_0019:  add // 出栈两次,出栈值相加，结果入栈
  IL_001a:  stloc.2 // 出栈 置于局部变量表2位置 (i++ 结束)
  IL_001b:  ldloc.2 // 局部变量表2位置变量入栈 (i 入栈) (for 中判断开始位置)
  IL_001c:  ldloc.1 // 局部变量表1位置变量入栈 (len 入栈)
  IL_001d:  blt.s      IL_000f // 判断计算栈顶两值大小(计算栈出栈两次，后出栈的是第一个值)。若第一个值小于第二个值，将控制转移到目标指令 (短格式)。
  IL_001f:  ret // 从当前方法返回
} // end of method Program::ForTest2

对比上述的 IL code，确实临时存储数组长，能够少在 for 的比较进行中少进行一定的操作，无需将数组从局部变量表(Local Variable Table)入操作数栈 (Operand stack)，并执行 ldlen 获取数组长。 但要注意， JIT 编译器知道 Length 是 Array 类的属性，生成的代码中只会调用该属性一次，结果会存储到临时变量中，此后的检查中调用的都是此临时变量。不需要自己用局部变量做缓存，这样既没有性能提升，还可能造成可读性下降。

参阅

CLR via C# (第四版) 16.7 数组的内部工作原理

注释

Ildasm.exe(IL 反汇编程序)

一般，该工具位于 NETFX 4.7.2 Tools 中

C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.7.2 Tools\x64\ildasm.exe

发表于 更新于 分类于 本文字数： 86 阅读时长 ≈ 1 分钟

文章名称不需要后缀名

1
{% post_link 文章名称 %}

如

1
{% post_link Hello-World %}

文章链接配置位于 _config.yml 中 permalink

1
2
3
4
5
6
7
8
9
# URL
## If your site is put in a subdirectory, set url as 'http://yoursite.com/child' and root as '/child/'
url: http://yoursite.com
root: /
permalink: :title/ # :year/:month/:day/:title/
permalink_defaults:
pretty_urls:
  trailing_index: true # Set to false to remove trailing 'index.html' from permalinks
  trailing_html: true # Set to false to remove trailing '.html' from permalinks

发表于 更新于 分类于 本文字数： 2k 阅读时长 ≈ 7 分钟

详情

Unity 对象的空检测

UnityEngine.Object 有其自定义的空检测方法。

因此 UnityEngine.Object 有两种空检测：

  1. 检测 Unity 原生对象是否被销毁 (使用 UnityEngine.Object 自定义空检测)
  2. 检测 Unity 对象是否初始化与正确引用 (使用 object.ReferenceEquals(monoBehaviour, null))

Unity 对象的生与死

原生对象与包装对象：

Unity 是基于 C/C++ 的引擎，GameObject 的所有实际信息 (name、component list、HideFlags 等等) 都存储在 C++ 对象中。此类对象被称为**”原生对象” (native object)**。

C# GameObject 所有的仅是指向原生对象的指针 (pointer)。此类对象被称为**”包装对象” (wrapper object)**。

C# 与 C++ 有不同的内存管理方式，这意味着包装对象与其包裹的原生对象有着不同的生命周期。

当原生对象已被销毁，包装对象依然存在时，将包装对象其与 null 比较，**UnityEngine 的 == 运算符严格执行 Unity object 底层的生命周期检查，返回 “true”**。

Real null 与 Fake null：

**在 Editor only 时，MonoBehaviour 不是 “real null” 而是 “fake null”**。[1]

Unity 在 fake null object 中存储信息。当执行其方法 (method)，或访问其属性 (property) 时，可提供更多的上下文信息：

在 fake null object 中存储信息，Unity 能够在检视窗口 (Inspector) 中高亮该 GameObject，并给出更多指引。如:”looks like you are accessing a non initialized field in this MonoBehaviour over here, use the inspector to make the field point to something” (看来您试图访问此 MonoBehaviour 的未实例化字段，请在检视窗口使其指向实例)。

若不在 fake null object 中存储信息，只能得到 NullReferenceException 与堆栈跟踪。并不知道具体是哪个带有 MonoBehaviour 的 GameObject 有字段为 null。

UnityEngine 的 == 运算符能够检测是否存在 fake null object。

Unity 相关代码

反编译获得，不是源码。

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
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
// UnityEngine.Object
public static bool operator ==(Object x, Object y) => Object.CompareBaseObjects(x, y);

public static bool operator !=(Object x, Object y) => !Object.CompareBaseObjects(x, y);

public static implicit operator bool(Object exists) => !Object.CompareBaseObjects(exists, (Object) null);

public override bool Equals(object other)
{
    Object rhs = other as Object;
    return (!(rhs == (Object) null) || other == null || other is Object) && Object.CompareBaseObjects(this, rhs);
}

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);
  return flag1 ? !Object.IsNativeObjectAlive(rhs) : lhs.m_InstanceID == rhs.m_InstanceID;
}

private static bool IsNativeObjectAlive(Object o)
{
  if (o.GetCachedPtr() != IntPtr.Zero)
    return true;
  return !(o is MonoBehaviour) && !(o is ScriptableObject) && Object.DoesObjectWithInstanceIDExist(o.GetInstanceID());
}

/// <summary>
///   <para>Returns the instance id of the object.</para>
/// </summary>
[SecuritySafeCritical]
public int GetInstanceID()
{
  this.EnsureRunningOnMainThread();
  return this.m_InstanceID;
}

private void EnsureRunningOnMainThread()
{
  if (!Object.CurrentThreadIsMainThread())
    throw new InvalidOperationException("EnsureRunningOnMainThread can only be called from the main thread");
}

private IntPtr GetCachedPtr() => this.m_CachedPtr;

[NativeMethod(IsFreeFunction = true, IsThreadSafe = true, Name = "UnityEngineObjectBindings::DoesObjectWithInstanceIDExist")]
[MethodImpl(MethodImplOptions.InternalCall)]
internal static extern bool DoesObjectWithInstanceIDExist(int instanceID);

[NativeMethod(IsFreeFunction = true, IsThreadSafe = true, Name = "CurrentThreadIsMainThread")]
[MethodImpl(MethodImplOptions.InternalCall)]
private static extern bool CurrentThreadIsMainThread();

如上所示，Unity 实现了自己的空判断，并将其应用于重载的 != 运算符、== 运算符、隐式 bool 转换运算符及重写的 System.Object 的 Equals(object obj) 中。

其中涉及许多的逻辑，如确保方法调用于主线程，指定实例 id 的 UnityEngine.Object 是否存在，缓存的指针是否为 IntPtr.Zero，比较的两 UnityEngine.Object 的 实例 id 是否相同。及其他的外部方法调用。因此，相比于 object.ReferenceEquals() 的调用会被编译器优化为简单的空检查，Unity的自定义比较需要执行许多逻辑，速度较慢。

编写规范

上文提到了 Unity 对象的两种 null 检测，编写代码时，一定要明确表意，确定为其中的一种。

特别的，C# 的空合并运算符与空条件运算符将会绕过 Unity 的生命周期检查，导致表意不明：[2]

空合并运算符

以下示例的表意不明确：是检查 gameObject 是否正确引用，还是检查原生 Unity 引擎对象是否已销毁？

1
2
// DON'T DO THIS!
var go = gameObject ?? CreateNewGameObject();

若目的是检查底层引擎对象的生命周期，则此代码不正确，因为生命周期检查被绕过。

使用显式 null 或 boolean 比较修复代码：

1
2
3
var go = gameObject != null ? gameObject : CreateNewGameObject();
// 也可使用隐式的 bool 转换运算符进行同样的检测
go = gameObject ? gameObject : CreateNewGameObject();

若目的是确保 gameObject 变量已被初始化并分配了有效的 C# 引用，推荐使用 object.ReferenceEquals()：

1
return !object.ReferenceEquals(gameObject, null) ? gameObject : CreateNewGameObject();

虽然稍显冗长，但表意十分明确。

空条件运算符

以下示例的表意同样不明确：

1
2
// DON'T DO THIS!
monoBehaviour?.Invoke("Attack", 1.0f);

同样的，若目的是简单地检查 monoBehaviour 变量是否已正确初始化与引用，推荐使用 object.ReferenceEquals()：

1
2
if (!object.ReferenceEquals(monoBehaviour, null))
  monoBehaviour.Invoke("Attack", 1.0f);

若目的是检查底层引擎对象的生命周期，推荐使用显式的 null 或 boolean 比较：

1
2
3
4
5
if (monoBehaviour != null)
  monoBehaviour.Invoke("Attack", 1.0f);
// 也可使用隐式的 bool 转换运算符
if (otherBehaviour)
  otherBehaviour.Invoke("Attack", 1.0f);

个人解决方案

如果只是想检测 GameObject 是否初始化与正确引用，可以考虑使用 unity 平台宏 以及 C# 扩展方法对 ReferenceEquals 进行封装。[3]

这样避免了在 editor 时 fake null object 引发的 ReferenceEquals 判断错误的问题，也提高了代码的可读性。

1
2
3
4
5
6
7
8
public static bool IsSet(this GameObject gameObject)
{
#if UNITY_EDITOR
	return gameObject;
#else
	return !ReferenceEquals(gameObject, null);
#endif
}

个人思考

Unity 在与 null 进行比较时判断原生对象是否存活，而是不是检测 C# 对象。这种设计是反直觉的，大多数用户未注意到这种自定义比较。Custom == operator, should we keep it? | Unity Blog Unity 自己的开发者都忘记了。

C# 的引用类型，若不是”值类” (Value class)，应采用默认的比较逻辑 (直接对引用进行比较)，不应重载的 !=、== 及隐式 bool 转换运算符，不应重写 System.Object 的 Equals(object obj) 方法。

UnityEngine.Object 的比较逻辑有把自己的本职工作做好 (直接对引用进行比较)，又做了其他的工作 (判断原生对象是否存活)，这不符合单一职责原则。导致了两种空判断的存在，造成了可能的语义不明，与潜在的性能下降。这样增添的逻辑也导致其表现与 C# 的空合并运算符和空条件运算符不一致。导致在使用 UnityEngine.Object 没法很好的使用这两种运算符。若使用，则表意不明确，若不使用，则降低了代码的可读性 (见编写规范)。

更好的方法可能是在 UnityEngine.Object 中加入 destroyed 这样的字段标识原生对象的存活情况。当用户想到知道时进行调用。[4]

参阅

Unity 的说明 Custom == operator, should we keep it? | Unity Blog

译文 Unity-自定义==运算符，我们应该保留它吗

Resharper-unity 的说明 Possible unintended bypass of lifetime check of underlying Unity engine object · JetBrains/resharper-unity Wiki

译文 Unity-Resharper-可能意外绕过Unity引擎对象的底层生命周期检查

?? 和 ??= 运算符 - C# 参考 | Microsoft Docs

成员访问运算符和表达式 Null 条件运算符 ?. 和 ?[] - C# 参考

扩展方法 - C# 编程指南 | Microsoft Docs

Real null 与 Fake null 的测试可见我的 github 仓库：UnityEngineObjectNullCheck (分别打包运行与编辑器运行对比区别)

注释

[1] 仅在编辑器中有这种情况。这也是为什么调用GetComponent() 查询不存在的组件时，有 C# 内存分配产生，因为此时 fake null object 中正在生成自定义警告字符串。

这也是为什么测试游戏需要打包测试，而不是在编辑器测试。为了给用户提供便利，编辑器中做了很多额外的工作 (用例、安全检查等)，但是牺牲了性能。

[2] 空合并运算符与空条件运算符是无法重载的，可能是因为这点，Unity 无法令其进行自定义的空检查

[3] 扩展方法 - C# 编程指南 | Microsoft Docs

[4] Unity 最终选择了不对其修改，而是修复由此带来的种种问题。

发表于 更新于 分类于 本文字数： 830 阅读时长 ≈ 3 分钟

(Ryuu: 附上原文地址 : Possible unintended bypass of lifetime check of underlying Unity engine object · JetBrains/resharper-unity Wiki)

这是 Unity 特定的检查。此检查仅在 Unity 项目中运行。

若从 UnityEngine.Object 派生的类型使用空合并 (??) 或空传播或条件 (?.) 运算符，则会显示此警告。 这些运算符不会使用 UnityEngine.Object 上声明的自定义相等运算符，将绕过 Unity 原生(native)对象的存活检测。 为了阐明意图，最好使用显式 null 或 bool 比较，或调用 System.Object.ReferenceEquals()。

详情

从 UnityEngine.Object 派生的类型是托管 .NET 对象，在 C# 脚本中用于表示与使用原生 Unity 引擎对象。这两种类型的对象具有不同的生命周期。托管的 .NET 对象在没有更多引用时被垃圾收集，而本地 Unity 引擎对象在加载新场景或通过显式调用 UnityEngine.Object.Destroy() 时被销毁。这意味着托管的 .NET 对象指向的原生对象可能已被销毁。

UnityEngine.Object 类定义了自定义相等运算符，当与 null 进行比较时，这些运算符将检查底层原生 Unity 引擎对象是否已被破坏。换句话说， myMonoBehaviour == null 将检查是否已分配 myMonoBehaviour 变量，并且还将检查原生引擎对象是否已被销毁。可以使用布尔比较执行相同的检查，例如 if (myMonoBehaviour == true) 或 if (!myMonoBehaviour) 或是 if (myMonoBehaviour)。

如果使用空合并或条件运算符，则表意不明确，并且可能绕过预期的生命周期检查。如果打算进行生命周期检查，推荐使用与 null 或布尔比较的显式比较。若不打算进行生命周期检查，请调用 System.Object.ReferenceEquals() 以明确表意。注意，对 object.ReferenceEquals() 的调用被编译器优化为简单的空检查，比调用自定义相等运算符更快。

空合并运算符

以下示例的表意不明确：是检查 gameObject是否正确引用，还是检查原生 Unity 引擎对象是否已销毁？

1
var go = gameObject ?? CreateNewGameObject();

若目的是检查底层引擎对象的生命周期，则此代码不正确，因为生命周期检查被绕过。使用显式 null 或 boolean 比较修复代码：

1
2
3
var go = gameObject != null ? gameObject : CreateNewGameObject();
// 也可使用隐式的 bool 转换运算符进行同样的检测
go = gameObject ? gameObject : CreateNewGameObject();

若目的是确保 gameObject 变量已被初始化并分配了有效的 C# 引用，推荐使用显式调用 object.ReferenceEquals()：

1
return !object.ReferenceEquals(gameObject, null) ? gameObject : CreateNewGameObject();

虽然这种更改稍显冗长，但表意十分明确。

空条件运算符

以下示例的表意同样不明确：

1
monoBehaviour?.Invoke("Attack", 1.0f);

同样的，如果目的是简单地检查 monoBehaviour 变量是否已正确初始化与引用，推荐使用显式调用 object.ReferenceEquals()：

1
2
if (!object.ReferenceEquals(monoBehaviour, null))
  monoBehaviour.Invoke("Attack", 1.0f);

但是，如果目的是检查底层引擎对象的生命周期，推荐使用显式的 null 或 boolean 比较：

1
2
3
4
5
if (monoBehaviour != null)
  monoBehaviour.Invoke("Attack", 1.0f);
// 也可使用隐式的 bool 转换运算符
if (otherBehaviour)
  otherBehaviour.Invoke("Attack", 1.0f);

参阅

有关此主题的更多详细信息，请参阅 Unity 博客文章 “Custom == operator, should we keep it?”.

已翻译：Unity-Resharper-可能意外绕过Unity引擎对象的底层生命周期检查

发表于 更新于 分类于 本文字数： 1.6k 阅读时长 ≈ 6 分钟

(Ryuu: 附上原文地址 : Custom == operator, should we keep it?)

正文

Unity 的 == 运算符有特殊实现 (UnityEngine.Object 重载了 == 及 != 运算符)。

  1. 当一个 MonoBehaviour 有字段，在 editor only [1] 时，这些字段不是 “real null”，而是 “fake null”。UnityEngine 的 == 运算符能够检测是否存在 fake null object。

    虽然这样做很奇怪，但这能让 Unity 在 fake null object 中存储信息。当执行其方法 (method)，或访问其属性 (property)，提供更多的上下文信息。

    若不在 fake null object 中存储信息，只能得到 NullReferenceException，堆栈跟踪。并不知道具体是哪个带有 MonoBehaviour 的 GameObject 有字段为 null。

    在 fake null object 中存储信息，Unity 能够在检视窗口 (Inspector) 中高亮该 GameObject，并给出更多指引:”looks like you are accessing a non initialized field in this MonoBehaviour over here, use the inspector to make the field point to something” (看来你在 MonoBehaviour 中试图访问未实例化字段，请在检视窗口使其指向实例)。

  2. 第二点稍加复杂。

    当你获取 GameObject 类型的 c# object **[2]，他几乎不包含任何信息。这是因为 Unity 是基于 C/C++ 的引擎。关于此 GameObject 的所有实际信息 (name，component list，HideFlags，等等) 都存活在 C++ 侧。C# object 所有的仅是指向原生对象 (native object) 的指针 (pointer)。我们称这样的对象为“包装对象” (wrapper objects)**。

    这些如 GameObject 的 c++ objects 及其他一切继承自 UnityEngine.Object 的生命周期都被明确的管理。当你加载新场景，或在其上调用 Object.Destroy(myObject); 时，这些 Object 将会被销毁。

    C# object 的生命周期有 C# 的管理方式，其具有垃圾收集器 (garbage collector) **[4]**。这意味着，有可能被包裹的 C++ Object 已经被销毁，但包裹它的 C# 包装对象依然存在。将此对象与 null 比较，UnityEngine 重载的 == 会返回 true，尽管实际上的 C# 变量 (variable) 不为 null。

UnityEngine 自定义的空检测 (null check) 也导致许多缺陷

  • 这种自定义十分反直觉
  • 对两个 UnityEngine.Object 比较或与 null 比较，会比想象中的要慢
  • UnityEngine 重载的 == 是非线程安全 (not thread safe) 的 (这点 Unity 可在后续修复)
  • 其与 ?? 操作符的表现不一致，?? 同样进行空检测，但这是纯粹的 C# 空检测，会绕过 UnityEngine.Object 自定义空检测 [5]

回顾所有的这些优缺点，如果从头再构建 API，我们将不会选择自定义空检查，而是创建一个 myObject.destroyed 的属性，访问该属性以检测 object 的生死。让用户接受在空字段调用方法时不再提供更好的错误信息的事实。

我们在思考我们是否应该改变此自定义运算符，我们一直在寻找 “修复，清除原始项目” 与 “不要破坏原始项目” 之间的正确的平衡。在这种情况下，我们想了解其他人的思考。

对于 Unity5，我们一直在研究 Unity 自动更新脚本的能力 (于随后的博客中对此进行了详细介绍)。不幸的是，在本文情况下，我们无法使您的脚本自动升级 (无法准确辨识 “这个旧脚本确实需要旧的 behaviour” 和 “这个新脚本确实需要新的 behaviour” 的区分)。

我们倾向于 “移除自定义 == 运算符”，但还在犹豫，因为这将改变您工程中所有空检查的意义。对于对象不是 “really null” 而是已销毁对象的情况来说，空检查通常返回 true，如果我们修改了它，就会返回 false 了。若想检测变量是否指向被摧毁对象，需要把代码改成 “if (myObject.destroyed) {}”。我们对此有点紧张，无论你有没有读这篇文章，都很容易意识不到这种行为的改变，特别是大多数人根本没有意识到这种自定义空检查的存在。**[3]**

如果我们作修改，应在 Unity5 上。对于非主要发行版，我们允许用户承受的升级痛苦阈值更低。

你希望我们怎么做？以必须更改已有项目中的空检查为代价，提供更整洁的体验，或是保持现状？

再见, Lucas (@lucasmeijer) **[6]

注释

[1] 我们只在编辑器中执行此操作。这就是为什么在调用GetComponent() 查询不存在的组件时，会看到 C# 内存分配产生，因为我们正在新分配的伪空对象中生成自定义警告字符串。在打包的游戏中，这种内存分配不会发生。这就是为什么测试游戏时，应在打包出来的独立端 (standalone 如 Mac, Windows or Linux) 或移动端测试，而不是在编辑器测试，因为我们在编辑器中做了很多额外的 安全/用例检查，以使你的工作更轻松，而牺牲了一些性能。在分析性能和内存分配时，永远不要在编辑器，应始终分析构建出的游戏。

[2] 不仅适用于 GameObject，也适用于继承自 UnityEngine.Object 的所有类。

[3] 有趣的故事: 我在优化GetComponent（）性能时遇到了这个问题，在为 transform 组件做一些缓存实现时，我没有看到任何性能优势。@jonasechterhoff 也研究了此问题，得出了相同的结论。缓存代码如下所示：

1
2
3
4
5
6
7
8
9
10
private Transform m_CachedTransform
public Transform transform
{
  get
  {
    if (m_CachedTransform == null)
      m_CachedTransform = InternalGetTransform();
    return m_CachedTransform;
  }
}

事实证明，我们自己的两位工程师都没有注意到空检查会比想象中更费时。这就是缓存没有带来速度提升的原因，”连我们自己都忘记了它 (Unity 自定义空检测)，会有多少用户会忘记了它？”，这使得我写下了此篇文章 :)

[4] Ryuu: C# 托管对象的回收是 C# 垃圾回收器管理的，不能保证其生命周期和 C++ 侧对象完全一致。

[5] Ryuu: 原文是 “and cannot be bypassed to call our custom null check”(可以绕过自定义空检测) 个人认为是写错了 (也可能是我英语太差，理解错了)，实际情况是，使用 ?? 或 ?. 都会绕过 UnityEngine.Object 的自定义空检测。附上 JetBrains/resharper-unity 的解释页: Possible unintended bypass of lifetime check of underlying Unity engine object

[6] Ryuu: 最后作者真香了，并没有移除自定义的空检查，而是想办法修复其产生的缺陷。

发表于 更新于 分类于 本文字数： 1.8k 阅读时长 ≈ 6 分钟

由于大多数程序的算法都是要在一系列元素而非单一元素上执行操作，因此开发者会使用 foreach、for 循环及 while 等结构。通常把某集合用作输入值，然后检视或修改集合本身或其中元素，最后把另一个集合作为输出值返回给调用方。

这样做的问题在于，若针对整个集合中的每个元素执行操作，程序效率很低。因为执行的操作通常不止一个，且需要多次变换才能把源集合元素转换为目标集合元素。在此过程中，需要创建一些集合保存中间结果，且集合有可能较大，必须等整个集合完成了一次变换操作后，才能继续执行下一次变换操作。要执行几次操作，就得把集合遍历几遍，因此，若执行操作较多，那么算法的执行时间会较长。

另一种办法是，在方法中仅遍历一次，将序列中每个元素都处理一遍，并对其进行各种变换，得到结果。这将提高程序的效率，降低内存使用 (不用每执行一步就创建一个集合)。但这样的的代码很难复用，因为开发者复用的不是整套逻辑，而是其中的一小步。

由于 C# 有*迭代器 (iterator)，因此，开发者可用它创建出一种方法来操作序列中的元素，这样的方法只会在调用方法真正请求获取元素是才会处理并返回该元素。这些方法以 IEnumerable 型参数表示源序列，并把要生成的目标序列也设计为 IEnumerable，而且通过 yielld return语句返回序列中的元素，使得开发者无需给整个目标序列中的元素分配空间，而是可以等调用方真正用到序列中的下一个元素时采取向源序列查询相关数据，并以此生成所需元素。将通用的 IEnumerable 或针对某种类型的 IEnumerable 设计成方法的输入及输出参数是一种比较少见的思路，因此，很多开发者都不会这样做，但这种思路能带来许多好处。与传统方法相比，这种延迟执行 (deferred execution，见37条)*机制可以降低算法所需内存空间，使算法各部分能够更灵活的拼接复用 (见40条)。还可把不同操作放在不用的 CPU 内核中执行，进一步的提高程序性能。可创建泛型方法，扩大其使用范围。

如下实例将序列中每种元素输出一次 (重复元素不输出)：

1
2
3
4
5
6
7
8
9
10
11
public static void Unique(IEnumerable<int> nums)
{
    var uniqueSet = new HashSet<int>();

    foreach (int num in nums)
    {
        if (uniqueSet.Contains(num)) continue;
        uniqueSet.Add(num);
        Console.WriteLine(num);
    }
}

此方法虽然简单，但是不能进行复用。

可以考虑改用迭代器方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public static IEnumerable<int> UniqueV2(IEnumerable<int> nums)
{
    var uniqueSet = new HashSet<int>();

    foreach (int num in nums)
    {
        if (uniqueSet.Contains(num)) continue;
        uniqueSet.Add(num);
        yield return num;
    }
}

public static void Main(string[] args)
{
    int[] nums = {0, 3, 4, 5, 7, 3, 2, 7, 8, 0, 3, 1};
    foreach (int i in UniqueV2(nums))
        Console.WriteLine(i);
    
    Console.WriteLine(UniqueV2(nums).First());
}

有人认为这样改差不多，没什么好处。加上一些追踪语句，能让你更清楚此方法的运作：

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
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
public static IEnumerable<int> UniqueV2(IEnumerable<int> nums)
{
    var uniqueSet = new HashSet<int>();
    Console.WriteLine("\tEntering Unique");
    foreach (int num in nums)
    {
        Console.WriteLine($"\tEvaluating {num.ToString()}");
        if (uniqueSet.Contains(num)) continue;
        uniqueSet.Add(num);
        yield return num;
        Console.WriteLine("\tRe-entering after yield return");
    }

    Console.WriteLine("\tExiting Unique");
}

public static void Main(string[] args)
{
    int[] nums = {0, 3, 4, 5, 7, 3, 2, 7, 8, 0, 3, 1};
    
    // Entering Unique
    // Evaluating 0
    // 0
    // Re-entering after yield return
    //     Evaluating 3
    // 3
    // Re-entering after yield return
    //     Evaluating 4
    // 4
    // Re-entering after yield return
    //     Evaluating 5
    // 5
    // Re-entering after yield return
    //     Evaluating 7
    // 7
    // Re-entering after yield return
    //     Evaluating 3
    // Evaluating 2
    // 2
    // Re-entering after yield return
    //     Evaluating 7
    // Evaluating 8
    // 8
    // Re-entering after yield return
    //     Evaluating 0
    // Evaluating 3
    // Evaluating 1
    // 1
    // Re-entering after yield return
    //     Exiting Unique
    foreach (int i in UniqueV2(nums))
        Console.WriteLine(i);

    //        Entering Unique
    //        Evaluating 0
    // 0
    Console.WriteLine(UniqueV2(nums).First()); // Ryuu: 添加一个示例
    
    // foreach (int num in Square(UniqueV2(nums)))
    //     Console.WriteLine($"Number returned from unique square: {num.ToString()}");
}

之所以有这样的效果，关键就在于 yield return 语句。此语句会返回值，并保留信息，记录当前执行的位置及内部迭代逻辑的状态。用此语句写出来的方法，输入输出值都是迭代器，其迭代逻辑可根据早前保留的信息判断当前应读取输入序列的哪一元素，据此生成并返回输出序列中的下一元素。此方法属于可从上次执行位置继续执行的方法 (continuable method)，系统每次运行它时，可根据先前记录的状态信息决定继续执行的位置。

将 Unique() 方法改写成连续方法 (continuation method) 有两个好处：

  1. 推迟了每个元素的求值时机，提高程序效率。
  2. 此操作可拼接，可灵活复用。

反之，想用包含 foreach 循环的命令式方法进行灵活复用则较为困难。

注意，Unique() 方法还可转换为泛型方法：

1
2
3
4
5
6
7
8
9
10
public static IEnumerable<T> UniqueV3<T>(IEnumerable<T> sequence)
{
    var uniqueSet = new HashSet<T>();
    foreach (T item in sequence)
    {
        if (uniqueSet.Contains(item)) continue;
        uniqueSet.Add(item);
        yield return item;
    }
}

迭代器方法可把多个步骤拼接成一套流程。若要输出是每一种数值的平方，接上一个 Square() 即可：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public static IEnumerable<int> Square(IEnumerable<int> nums)
{
    foreach (int num in nums)
        yield return num * num;
}

public static void Main(string[] args)
{
    int[] nums = {0, 3, 4, 5, 7, 3, 2, 7, 8, 0, 3, 1};
    
    foreach (int num in Square(UniqueV2(nums)))
        Console.WriteLine($"Number returned from unique square: {num.ToString()}");
    
}

无论使用多少个迭代器方法，仅需将源序列迭代一次即可。

将序列用作迭代器的输入参数。并令其输出另一序列是一种很好的思路，这使得开发者能设计更多的用法。若迭代器方法的参数不是一个序列而是两个，可用这样的迭代器方法将两个序列合并起来：

1
2
3
4
5
6
7
8
9
10
11
12
13
public static IEnumerable<string> Zip(IEnumerable<string> first, IEnumerable<string> second)
{
    using (var firstSequence = first.GetEnumerator())
    {
        using (var secondSequence = second.GetEnumerator())
        {
            while (firstSequence.MoveNext() && secondSequence.MoveNext())
            {
                yield return $"{firstSequence.Current}{secondSequence.Current}";
            }
        }
    }
}

Zip() 从两个不同的字符串序列中分别取出一个元素，并连接成为新字符串，输出目标序列。当然，此方法也可设计成泛型方法，只不过稍复杂 (见18条)。

迭代器方法不会修改源序列本身，而是会依次产生目标序列中的元素，这些元素构成一个新序列。若源序列中的元素是引用型，那么迭代器有可能在处理元素时改动该元素内容。

如果能把复杂的算法拆解成多个步骤，并将每个步骤都表示成小型的迭代器方法，那么可将这些方法拼成一条管道，使得程序仅需遍历一次源序列处理，即可对其中元素进行多种小变换。

发表于 更新于 分类于 本文字数： 1.3k 阅读时长 ≈ 5 分钟

这条建议可能听起来有些奇怪，因为 lambda 表达式代替方法会重复编写代码。例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
var allEmployees = FindAllEmployees();

// Find the first employees:
var earlyFolks =
    from e in allEmployees
    where e.Classification == EmployeeType.Salary
    where e.YearsOfService > 20
    where e.MonthlySalary < 4000
    select e;

// Find the newest people:
var newest =
    from e in allEmployees
    where e.Classification == EmployeeType.Salary
    where e.YearsOfService < 20
    where e.MonthlySalary < 4000
    select e;

你可以将这些 where 合并为一条子句，然而这并不会带来太大区别。查询操作之间本就可以拼接 (见31条)，而简单的 where 谓词还会有可能内联 (inline)，因此，这两种写法在性能上是一样的。

看到刚才那段代码，你可能会想把重复的 lambda 表达式提取到方法，以便复用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// Factor out method:
private static bool LowPaidSalaried(Employee e) => 
    e.MonthlySalary < 4000 && e.Classification == EmployeeType.Salary;

// else where
var allEmployees = FindAllEmployees();

var earlyFolks =
	from e in allEmployees
	where LowPaidSalaried(e) && e.YearsOfService > 20
	select e;
            
// Find the newest people:
var newest =
	from e in allEmployees
	where e.Classification == EmployeeType.Salary
	where e.YearsOfService < 20
	where e.MonthlySalary < 4000
	select e;

如果将来需要修改员工的类别 (Classification)，或修改筛选底薪员工时所依据的最低月薪 (MonthlySalary)，那么只需要改动 LowPaidSalaried() 里的逻辑即可。

但是这样的重构不能提高其复用性，这与 lambda 表达式求值、解析及执行机制有关：

  • LINQ to Objects

    为执行表达式中代码，将 lambda 表达式转化成为委托

  • LINQ to SQL

    根据 lambda 表达式创建表达式树，并解析，使其能在其他环境执行

LINQ to Objects 针对本地数据存储 (local data store) 来执行查询，数据通常放在泛型集合。系统根据 lambda 表达式中的逻辑建立匿名委托，并执行相关代码。LINQ to Objects 扩展方法使用 IEnumerable 来表示输入序列。

LINQ to SQL 使用表达式树，根据所写查询逻辑构建表达式树，将其解析为适当的 T-SQL 查询，这种查询是针对数据库执行的，LINQ to SQL 把 T-SQL 形式的查询字符串发送给数据库引擎并执行。这种处理方式要求 LINQ to SQL引擎必须解析表达式树，并把其中每一项操作都替换成等价的 SQL，这意味着所有的方法调用都需要换成 Expression.MethodCall 节点。然而 LINQ to SQL 引擎并不能把每一种方法调用都顺利的转化为 SQL 表达式，无法转换将会引发异常。

如果所写的程序库需要支持任意类型的数据源，必须考虑上述情况。需要分开编写 lambda 表达式，且内联至代码中，以保证程序库正常运行。

这并不是在鼓励一味的复制代码，而是提醒，涉及查询表达式及 lambda 的地方应该用更为合理的方法去创建复用代码块。例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
private static IQueryable<Employee> LowPaidSalariedFilter(this IQueryable<Employee> sequence) =>
    from s in sequence
    where s.Classification == EmployeeType.Salary && s.MonthlySalary < 4000
    select s;

// else where
var allEmployees = FindAllEmployees();

// Find the first employees:
var salaried = allEmployees.LowPaidSalariedFilter();

var earlyFolks = salaried.Where(e => e.YearsOfService > 20);

// Find the newest people:
var newest = salaried.Where(e => e.YearsOfService < 2);

并不是每一种查询都能像这样简单的改写，可能需要沿着调用链寻找，才能发现可供复用的列表处理逻辑 (list-processing logic)，从而提取相同的 lambda 表达式。31条提过，只要当程序真的需要遍历集合的时，enumerator 方法才会得以执行。可利用此特征，将查询操作分成许多小方法来写，这些小方法都能复用某一套 lambda 表达式来执行它所应该完成的那一部分查询工作。这些方法需要将待处理的序列当成输入值，并以 yield return 形式返回处理结果。这些小方法可构成较大的查询模块。避免重复的代码，使得代码结构更合理。

也可按照同样的思路建立表达式树，以此拼接 IQueryable 形式的 enumerator，令查询操作能够远程执行。寻找相关员工所用的那棵表达式树可以先于其他查询拼接，然后执行。IQueryProvider 对象 (LINQ to SQL 引擎的数据源就是这种对象) 可以把全套查询操作一次执行完毕，而不必将其分解成多个部分放到本地执行。

若想在复杂的查询中有效地复用 lambda 表达式，可以考虑针对封闭的泛型类型创建扩展方法。LowPaidSalariedFilter 方法就是这么写的，它接受有待筛选的 Employee 对象序列，输出经过筛选后的 Employee 对象序列。在实际工作中，还应该创建以 IEnumerable 作阐述的重载版本，以便同时支持 LINQ to Objects 及 LINQ to SQL。

你可以把查询操作分成多个小方法，其中一些方法在其内部用 lambda 表达式处理序列，另一些方法以 lambda 表达式作参数。把这些小方法拼接起来，以实现整套操作。这样既可以支持 IEnumerable 与 IQueryable，又能令系统有机会构建出表达式树，以便高效执行查询。

发表于 更新于 分类于 本文字数： 1.4k 阅读时长 ≈ 5 分钟

定义查询操作，程序并不会立刻把数据获取并填充至序列，因为定义的实际上只是一套执行步骤，当真正需要遍历结果时，才会执行。每迭代一遍产生一套新结果，这叫做***惰性求值 (lazy evaluation)，反之，若像普通代码一样直接查询某套变量的取值并立即记录，那么就称为及早求值 (eager evaluation)***。

若定义查询操作需多次执行，请考虑采用哪种求值方式。是给数据做一份快照，还是先把逻辑记录下来，以便随时根据该逻辑查询，并将结果置入序列？

惰性求值与一般编写代码时的思路有很大区别，LINQ 查询操作把代码当数据看，用作参数的 lamdba 表达式要等到调用时才执行。此外，如果 provider 使用表达式树 (expression tree) 而不是委托，那么稍后可能还会有新的表达式融入树中。

通过以下示例演示惰性求值与及早求值的区别。生成一个序列，暂停，迭代，暂停，再迭代：

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
37
38
39
40
private static IEnumerable<TResult> Generate<TResult>(int number, Func<TResult> generator)
{
    for (var i = 0; i < number; i++)
        yield return generator();
}

/// <summary>
/// Start time for Test One: 8:37:28 PM
/// Waiting...      Press Return
/// 
/// Iterating...
/// 8:37:30 PM
/// ...
/// 8:37:30 PM
///      Waiting...      Press Return
///
///  Iterating...
///   8:37:39 PM
///   ...
///   8:37:39 PM
/// </summary>
private static void LazyEvaluation()
{
    Console.WriteLine($"Start time for Test One: {DateTime.Now:T}");
    var sequence = Generate(10, () => DateTime.Now);

    Console.WriteLine("Waiting... \tPress Return");
    Console.ReadLine();

    Console.WriteLine("Iterating...");
    foreach (DateTime dateTime in sequence) // warning: Possible multiple enumeration
        Console.WriteLine($"{dateTime:T}");

    Console.WriteLine("Waiting... \tPress Return");
    Console.ReadLine();

    Console.WriteLine("Iterating...");
    foreach (DateTime dateTime in sequence) // warning: Possible multiple enumeration
        Console.WriteLine($"{dateTime:T}");
}

注意观察结果中的时间戳 (time stamp)。由此可知，前后两次迭代所生成的是不同的两个序列，因为 sequence 变量保存的不是创建好的元素，而是创建元素所用的表达式树。(Ryuu：在 Rider 中编写该代码，将出现 Possible multiple enumeration 警告，同样告知，此操作可能导致遍历序列前后不一致。)

由于查询表达式能够惰性求值，因此可以在现有的查询操作后继续拼接其他的操作。

如下示例将 sequence1 序列得到的时间转换成协调世界时：

1
2
3
4
5
6
7
var sequence1 = Generate(10, () => DateTime.Now);
var sequence2 =
    from dateTime in sequence1
    select dateTime.ToUniversalTime();

foreach (DateTime dateTime in sequence2)
    Console.WriteLine($"{dateTime:T}");

sequence1 和 sequence2 两个序列是在功能层面上组合，而不是在数据层面上。系统并不会先把 sequence1 的所有值拿出来，然后全部修改一遍，构成 sequence2。而是执行相关的代码，把 sequence1 的元素生成出来，紧接着执行另一端代码处理该元素，将结果放入sequence2。程序并不会把时间都准备好，并将其转换为协调世界时，而是等待调用时再去生成该序列中被调用的时间。

由于查询表达式可惰性求值，因此，理论上来说，它可以操作无穷序列 (infinite sequence)。如果代码写的较为合理，那么程序仅需检查开头部分即可，因为在完成查询后程序会停止。反之，有些写法令表达式必须把整个序列处理一遍才能得到完整结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/// <summary>
/// 0123456789
/// </summary>
private static void LazyEvaluation3()
{
    var answers = from number in AllNumbers() select number;
    var smallNumbers = answers.Take(10);

    foreach (int num in smallNumbers)
        Console.Write(num);
}

private static IEnumerable<int> AllNumbers()
{
    var number = 0;

    while (number < int.MaxValue)
        yield return number++;
}

此示例不必生成整个序列，而是仅生成十个数 (虽然 AllNumbers() 可以生成至 int.MaxValue)。Take() 方法只需要其中的前 N 个对象。

反之，如果把查询语句改成这样，程序将一直运行，直到 int.MaxValue才停下：

1
2
3
4
var answers = from number in AllNumbers() where number < 10 select number;

foreach (int num in answers)
	Console.Write(num);

查询语句需要逐个判断序列中的每个元素，并根据其是否小于 10 决定要不要生成该元素，该逻辑导致其必须遍历整个元素。

某些查询操作必须把整个序列处理一遍，然后才能得到结果。比如上例的 where，以及 OrderBy、Max、Min。对于可能无限延伸下去的序列来说，尽量不要执行此操作。即使是有限长度，还是应尽量利用过滤机制来缩减待处理的数据，以提高程序效率。

1
2
3
4
5
6
7
8
9
10
11
12
13
// Order before filter.
var sortedProductsSlow =
    from p in products
    orderby p.UnitsInStock descending
    where p.UnitsInStock > 100
    select p;

// Filter before order.
var sortedProductsFast =
    from p in products
    where p.UnitsInStock > 100
    orderby p.UnitsInStock descending
    select p;

第一种方法会将所有产品排序，然后剔除小于等于 100 的产品，而第二种，则是先剔除小于等于 100 的产品，然后再排序，这样的话待排序的数据量可能减小。在编写算法时，请安排合适的执行顺序，这样的算法可能执行很快，反之，则可能极为耗时。

笔者列举了以上理由，建议查询时优先考虑惰性求值，但在个别情况下，可能想要给结果做一份快照，这是可以考虑 ToList() 及 ToArray()，他们都能立刻根据查询结果来生成序列，并保存至容器中。该方法用在以下两个场合：

  1. 需要立即执行查询操作
  2. 将来还要使用同一套查询结果

与及早求值的方法比，惰性求值能减少程序工作量，且使用起来更灵活。若有需要，可使用 ToList() 及 ToArray() 来保存结果。

0%