if (this.dramaEndBuildMapCallback != null)
{
	this.dramaEndBuildMapCallback();
	this.dramaEndBuildMapCallback = null;
}

可以看出，该块代码想表达的意思是执行完委托就清空。事实上在Unity5.6的时候它确实可以正常工作，但是随着Unity升级，.Net版本也升级到4.x，这种方式失效了。

经过查询，找到了一个可以正常清空委托列表的方法，首先通过GetInvocationList()方法获取委托列表，然后遍历，删掉。。

/// <summary>
/// 清除委托列表。
/// </summary>
/// <param name="action"></param>
public static void ClearDelegage(Action action)
{
	if (action != null)
	{
		Delegate[] delegates = action.GetInvocationList();
		for (int i = 0; i < delegates.Length; i++)
		{
			action -= delegates[i] as Action;
		}
	}
}

好想吐槽一下，为什么C#没提供一个像链表Clear()那样的方法来清除委托列表呢_(:з」∠)_

C#清除委托列表的正确用法最先出现在初晴神社。

之前给一个大佬做有赞应用时候遇到了post收发的问题，其实实现起来很简单的。无奈网上关于这方面的资料很少，特此整理一下，希望帮助有需要的人_(:з」∠)_

发送

直接上代码了，关键的地方我加了注释，应该不难理解。

C#提供了相关的API，很方便。这段代码可以直接拿去用_(:з」∠)_

大致步骤就是创建Request-填充信息-发送。

/// <summary>
/// Post提交数据
/// </summary>
/// <param name="postUrl">URL</param>
/// <param name="paramData">参数</param>
/// <returns></returns>
string PostWebRequest(string postUrl, string paramData)
{
    string ret = string.Empty;
    try
    {
        byte[] byteArray = Encoding.UTF8.GetBytes(paramData);
        HttpWebRequest webReq = (HttpWebRequest)WebRequest.Create(new Uri(postUrl));
        // 提交方法，POST/GET等
        webReq.Method = "POST";
        // ContentType
        webReq.ContentType = "application/x-www-form-urlencoded";
        webReq.ContentLength = byteArray.Length;

        Stream newStream = webReq.GetRequestStream();
        //写入参数
        newStream.Write(byteArray, 0, byteArray.Length);
        newStream.Close();
        HttpWebResponse response = (HttpWebResponse)webReq.GetResponse();
        StreamReader sr = new StreamReader(response.GetResponseStream(), Encoding.UTF8);
        ret = sr.ReadToEnd();

        sr.Close();
        response.Close();
        newStream.Close();
    }
    catch (Exception ex)
    {
        return ex.Message;
    }
    return ret;
}

接收

接收消息模块我分了两部分，一是主体，如何调用api进行监听。这部分需要另开一个线程来处理。

/// <summary>
/// 监听post消息，在收到消息后发送响应消息。
/// 建议使用死循环反复监听，且开启一个线程执行该方法。
/// </summary>
void ListenWebRequest()
{
    // string url= "需要监听的url范围";
    // 示例：(这里有个坑，见下文)
    string url = "http://127.0.0.1:2333";
    try
    {
        HttpListener listener = new HttpListener();
        listener.Prefixes.Add(url);

        // 开始监听端口，接收客户端请求
        listener.Start();

        // 阻塞主函数至接收到一个客户端请求为止
        // 也可以使用listener.BeginGetContext()异步监听
        HttpListenerContext context = listener.GetContext();
        HttpListenerRequest request = context.Request;
        HttpListenerResponse response = context.Response;

        // msg即为body内容
        string msg = GetBodyString(request);

        // 通过QueryString索引获取post参数
        string sample = request.QueryString["sample"];

        // 收到信息后返回数据
        string responseString = "响应数据";
        response.StatusCode = 200;
        // header头信息
        response.Headers.Add("Access-Control-Allow-Origin", "*");
        // contentType 类型
        response.ContentType = "application/json";
        response.ContentEncoding = System.Text.Encoding.UTF8;
        byte[] buffer = System.Text.Encoding.UTF8.GetBytes(responseString);
        response.ContentLength64 = buffer.Length;
        Stream output = response.OutputStream;
        output.Write(buffer, 0, buffer.Length);

        output.Close();
        listener.Stop();
        listener.Close();
    }
    catch (Exception ex)
    {
        // TODO
    }
}

第二部分，由于接收到的post消息中body内容是以流格式的，还需要将其转换为string。

/// <summary>
/// 将body内容解析为String。
/// </summary>
/// <returns>The body string.</returns>
/// <param name="request">Request.</param>
string GetBodyString(HttpListenerRequest request)
{
    string result = null;
    using (System.IO.Stream body = request.InputStream) // here we have data
    {
        using (System.IO.StreamReader reader = new System.IO.StreamReader(body, request.ContentEncoding))
        {
            result = reader.ReadToEnd();
        }
    }

    if (string.IsNullOrEmpty(result))
    {
        // TODO 读取到空消息
    }
    else
    {
        // TODO 成功读取消息
    }

    return result;
}

推荐一个post测试工具

Restlet Client – REST API Testing

谷歌浏览器插件：下载链接（需要翻墙）

炒鸡好用！

碎碎念

就是在接收方法那绑定的url，我当时用的腾讯云的服务器（window系统）测试的。是这样的，

如果url是localhost或127.0.0.1，在服务器本机测试一切正常。但如果从外网向其post数据，会报400或405错误。

如果url是服务器外网IP呢，干脆直接抛异常，好像是无法绑定。

最后尝试了下将url改成内网IP，一切OK。不过我还是不知道是什么原因_(:з」∠)_

使用C#实现POST消息发送和读取最先出现在初晴神社。

举个栗子，现在巧克力和香子兰两个人肚子饿了，要吃饭。吃饭的过程有三个步骤：

1.吃配菜；

2.吃主食；

3.喝饮料；

虽然吃饭步骤一样，可是两个人吃的东西却不同。巧克力配菜要吃西红柿炒鸡蛋，主食要吃馒头，饮料要喝可乐；而香子兰要吃麻婆豆腐，米饭和牛奶。

如果用程序表示的话，可以看出二者使用相同的验算流程，且实现的内容不一样。一般情况下我们会分别给二者写一套代码，这样做没有什么问题。可是如果后续开发需要添加新的功能呢，比如说红豆，时雨也要吃饭饭。或者她们想改变下吃饭的流程，先吃主食再吃配菜呢？是不是要为每套代码做出修改？显而易见这样的实现不太好，那么有没有一种好的实现方法呢？

答案就是使用模板方法模式（Template）

偷来的结构图_(:з」∠)_

1.定义一个算法的流程，即是很明确的定义算法的每一个步骤，并写在父类的方法中，而每一个步骤都可以是一个方法的调用。

2.某些步骤由子类完成。

代码实现

算法定义类：

由一个主方法和三个步骤方法组成，主方法不可重写，步骤方法必须在子类实现：

abstract class IEat
{
    public void Eat()
    {
        EatDishes();
        EatStaple();
        Drink();
    }

    protected abstract void EatDishes();
    protected abstract void EatStaple();
    protected abstract void Drink();
}

算法步骤的实现类：

巧克力：

class ChocolatEat : IEat
{
    protected override void EatDishes()
    {
        Console.WriteLine("配菜：西红柿炒鸡蛋");
    }

    protected override void EatStaple()
    {
        Console.WriteLine("主食：馒头");
    }
    protected override void Drink()
    {
        Console.WriteLine("饮料：可乐");
    }
}

香子兰：

class VinillaEat : IEat
{
    protected override void EatDishes()
    {
        Console.WriteLine("配菜：麻婆豆腐");
    }

    protected override void EatStaple()
    {
        Console.WriteLine("主食：米饭");
    }
    protected override void Drink()
    {
        Console.WriteLine("饮料：牛奶");
    }
}

在Main中调用：

static void Main(string[] args)
{
    ChocolatEat chocolat = new ChocolatEat();
    VinillaEat vinilla = new VinillaEat();

    Console.WriteLine("巧克力吃了：");
    chocolat.Eat();

    Console.WriteLine("-------------");
    Console.WriteLine("香子兰吃了：");
    vinilla.Eat();
}

结果：

结论

模板方法模式将可能出现重复的“算法流程”从子类提升到父类中，减少重复的发生，并且也开放子类参与算法中各个步骤的执行或优化。但如果“算法流程”开放太多的步骤，并要求子类必须全部重新实现的话，反而会造成实现的困难，也不容易维护。

【设计模式】05 – 模板方法模式最先出现在初晴神社。

从托管堆分配资源

在谈GC之前我们先看一看CLR中资源是如何创建的。

CLR要求所有对象都从托管堆分配。进程初始化时，CLR划出一个地址空间区域作为托管堆。并维护一个指针，称之为NextObjPtr，这个指针指向下一个对象在堆中的分配位置。刚开始的时候，NextObjPtr为地址空间区域的基地址。怎么说呢，有些类似栈指针，每安排一个对象，栈顶指针就会移动一个对象的大小。

当然这个堆的大小是有上限的，如果超过了上限，即这个区域被非辣鸡对象占满，CLR会尝试分配更多的区域，或者尝试垃圾回收。直到整个进程地址空间都被填满，到那个时候会抛出OutOfMemoryException异常。

在创建对象时我们会使用new操作符，来看下使用new后在CLR中会执行哪些操作：

1.首先计算类型的字段（以及从基类型继承的字段）所需的字节数。

2.将这个字节数加上对象开销所需的字节数。每个对象有两个开销字段：类型对象指针和同步块索引。

类型对象指针在程序运行，JIT编译时会用到，用来引用和对象对应的基本类型。

同步块索引我暂时只发现在垃圾回收时有用（之后会讲），不知道有没有别的用途。

3.CLR检查区域中是否有分配对象所需的字节数。如果有，就在NextObjPtr指针指向的地址处放入对象，并将为对象分配的字节清零。然后调用类型的构造器（对象中的this的值就是NextObjPtr），接着new操作符返回对象引用，分配完成。

然后NextObjPtr的值会加上对象占用的总字节数得到一个新的值，即下次分配时的初始地址。

垃圾回收算法

应用程序调用new操作符创建对象时，可能没有足够的空间来分配。发现空间不够，CLR就执行垃圾回收操作。

.NET垃圾回收器采用的是mark-and-compact算法。这种算法只关心引用类型的变量，并将其成为根。

CLR开始垃圾回收时，首先暂停进程中的所有线程。这样可以防止线程在CLR检查期间访问对象并更改状态。然后CLR进入垃圾回收的mark阶段，这时CLR遍历堆中所有对象，将同步块索引中的一位设为0。这表明所有对象都应该删除。然后CLR检查所有活动根，查看它们引用了哪些对象。任何根如果引用了堆上的对象，表明这个对象时可达的（还有用的），CLR将这个对象的同步块索引中的位从0改为1。一个对象被标记后，CLR会检查那个对象中的根，标记它们引用的对象。如果发现对象已经标记，就不重新检查对象的字段，这就避免了因为循环引用产生的死循环。

检查完成后，堆中的对象就被分成0（不可达）和1（可达）两部分，接下来CLR就要处理那些不可达的对象。即进入compact阶段，这个过程类似于磁盘碎片整理，并不是删除不可达对象，而是通过移动可达的对象，覆盖掉不可达的对象。这种做法不仅减小了应用程序的工作集，也解决了堆的空间碎片化问题。

不过完成上述步骤后还有一个问题需要解决。引用幸存对象的根还是指向移动前的位置，就好比你已经搬了家，但别人知道的还是你之前的地址。所以CLR还要从每个根减去所引用的对象在内存中偏移的字节数。这样就能保证每个根的引用还是和之前一样的对象。

compact之后，NextObjPtr指针指向最后一个幸存对象之后的位置。CLR恢复所有线程的运行。

如果在一次垃圾回收之后回收不了内存，而且进程中没有空间来分配新的GC区域，就说明该进程的内侧已耗尽。此时，试图分配更多内存的new操作符会抛出OutOfMemoryException异常。这可能导致操作系统终止进程并回收内存，即程序崩溃_(:з」∠)_

代

.NET垃圾回收的特别之处在于引入了“代”的概念，并非所有垃圾都一定会在一个垃圾回收周期中被回收。它有以下几点假设：

1.对象越新，生存期越短。

2.对象越老，生存期越长。

3.回收堆的一部分，速度快与回收整个堆。

即垃圾回收期会以更快的频率尝试清除生存时间较短的对象（新对象）。

总共分了0,1,2三代。新生对象被列为0代，假如第一次垃圾回收没有清除掉它，他就会提升至1代，同理直到提升到2代。相较于2代的对象，垃圾回收器会以更快的频率对第0代的对象执行垃圾回收。

除此之外，还有个优化效率的方法。上文提到如果一个对象被标记后，CLR会检查那个对象中的根，标记它们引用的对象。如果这个根引用了老一代的某个对象，垃圾回收器就可以忽略老对象内部的所有引用，也就能在更短时间内构造好可达对象图。当然老对象的字段也有可能引用新对象，为了确保对老对象的已更新字段进行检查，垃圾回收器利用了JIT编译器内部的一个机制，这个机制在对象的引用字段发生变化时，会设置一个对应的位标识。这样，垃圾回收器就知道自上一次垃圾回收以来，那些老对象（如果有的话）已被写入，只有字段发生变化的老对象才需检查是否引用了第0代中的任何新对象。

垃圾回收触发条件

1.CLR检测到第0代的大小超出预算。

2.代码显式调用System.GC的静态Collect()方法。

尽量不要使用这种方法，因为在调用后会暂停所有线程的执行，所以降低性能。

不过在实现对性能要求高，多线程运行的方法前可以手动调用一次，尽量避免在方法运行时触发垃圾回收。

3.Windows报告低内存情况。

4.CLR卸载AppDomain。

5.CLR正在关闭。

GC与终结器

之前在q群看到有人问，既然有GC了为什么还需要终结器机制？

要回答这个问题首先要了解下托管资源和非托管资源：

• 托管资源指的是.NET可以自动进行回收的资源，主要是指托管堆上分配的内存资源。托管资源的回收工作是不需要人工干预的，有.NET运行库在合适调用垃圾回收器进行回收。
• 非托管资源指的是.NET不知道如何回收的资源，最常见的一类非托管资源是包装操作系统资源的对象，例如文件，窗口，网络连接，数据库连接，画刷，图标等。这类资源，垃圾回收器在清理的时候会调用Object.Finalize()方法。默认情况下，方法是空的，对于非托管对象，需要在此方法中编写回收非托管资源的代码，以便垃圾回收器正确回收资源。

简单说，GC只能处理堆上的资源，比如对象。而像文件句柄，数据库连接这些GC是无能为力的。需要我们手动释放它们，而终结器可以当做是保底机制，我们可以在终结器中写好清理非托管的资源的代码。假如我们忘记在代码中显式清理资源，当终结器被CLR调用的时候就可以帮我们清理。

参考书籍;

1.《CLR via C#（第4版）》

2.《C# 6.0 本质论》

CLR中的垃圾回收（GC）机制最先出现在初晴神社。

状态模式，顾名思义，在于状态以及切换。比较常用的就是状态机，一个游戏角色在空闲，移动，攻击等状态相互切换时，就可以用状态模式。从一种行为转化为另一种行为的过程都在游戏内部实现，玩家不需要理解这个转化过程。而且无论怎么转化，玩家都是控制的该角色，并不会因为其内部的转变而有所差异。

另外虽然游戏角色会从空闲切换到攻击等状态，它的“表现行为”会有所变化，但是对于客户端来说，并不会因为这样的变化，而改变对它的“操作方法”的方式，也就是从开发角度说，这个对象对外界的对应方式不会有任何改变。但是对象的内部确实是会通过“更换状态类对象”的方式来进行状态的转换。

来看下状态模式的结构图：

（懒得画图了，自己找了个。与后续代码有些不同，不过整体结构是一样的）

其中：

[successbox title=”Context”]状态的拥有者，可以制定相关的接口，让外界能够得知状态的改变或通过操作让状态改变。[/successbox]

[infobox title=”State”]状态接口类，规范Context在特定状态下要表现的行为。[/infobox]

[infobox title=”StartState等”]具体状态类，实现Context在特定状态下该有的行为。比如角色空闲状态，攻击状态等。[/infobox]

代码实现

Context：

class Context
{
    private IState state;  // 代表当前状态

    // 更改状态
    public void SetState(IState state)
    {
        this.state = state;
    }

    // 状态行为
    public void Run()
    {
        if (state != null)
        {

            state.Handle();
        }
    }
}

IState

抽象类，通过构造方法传入Context，以便后续操作中使用。并定义了一个抽象方法，使其在子类中实现。

abstract class IState
{
    protected Context context;

    public IState(Context context)
    {
        this.context = context;
    }

    public abstract void Handle();
}

3个State

class StateA : IState
{
    public StateA(Context context) : base(context)
    {

    }

    public override void Handle()
    {
        Console.WriteLine("已切换到StateA");
        context.SetState(new StateB(context));
    }
}

class StateB : IState
{
    public StateB(Context context) : base(context)
    {

    }

    public override void Handle()
    {
        Console.WriteLine("已切换到StateB");
        context.SetState(new StateC(context));
    }
}

class StateC : IState
{
    public StateC(Context context) : base(context)
    {

    }

    public override void Handle()
    {
        Console.WriteLine("已切换到StateC");
        context.SetState(new StateA(context));
    }
}

上述三个子类都实现了父类的抽象方法，用来表示在各自状态下的行为。这里为了演示，只做了最简单的切换状态功能。

Context类中提供了SetState方法用来让外界切换状态，而这个“外界”也可以是另一个State。所以实现上，状态的切换可以有一下两种方式：

• 交由Context类本身，按条件在各状态之间切换；
• 产生Context类对象时，马上指定初始状态给Context对象，而后在后续执行过程中的状态转换则交由State对象负责，Context对象不再介入。

测试代码：

static void Main(string[] args)
{
    Context context = new Context();
    context.SetState(new StateA(context));

    context.Run();
    context.Run();
    context.Run();
    context.Run();
}

结果如下：

结论

使用状态模式的优点：

1.减少错误的发生并降低维护难度；

不再使用switch来判断状态，在后续更新维护时如果需要新的功能（状态），直接从IState派生就可以了，符合了开闭原则。

2.状态执行环境单一化；

与每一个状态有关的对象及操作都被实现在一个场景状态下，符合单一职责原则。

3.项目之间可以共享，增强可复用性。

参考资料：《设计模式与游戏完美开发》

【设计模式】03 – 状态模式最先出现在初晴神社。

例如将一个double数组的元素当做int类型输出，使用for循环可能需要这样写

for (int i = 0; i < doubleArray.Length; i++)
{
      Console.WriteLine((int)doubleArray[i]);
}

但如果使用foreach：

foreach (int i in doubleArray)
{
        Console.WriteLine(i);
}

/************************************************/

回到正题，foreach的原理是什么，或者说怎么实现一个可以被foreach遍历的结构呢？

答案主要在于两个C#接口，IEnumerable和IEnumerator。

IEnumerable 接口里有一个方法GetEnumerator。IEnumerable的意思是这个集合是可以遍历的，而GetEnumerator方法返回的IEnumerator的就是一个遍历器，用这个工具来遍历这个类。

IEnumorator接口中定义的内容包括Current，就是返回这个遍历工具所指向的那个容器的当前的元素，MoveNext ()方法就是指向下一个元素，当遍历到最后没有元素时，返回一个false.

上代码：School集合里有很多Student

首先定义一个Student类，这个类里有属性Name和构造器：

class Student
{
    public string Name { get; set; };

    public Student()
    {

    }

    public Student(string name)
    {
        Name = name;
    }
}

接下来定义School类，其中包含一个Student数组，构造方法。并继承IEnumerable接口并实现IEnumerator IEnumerable.GetEnumerator()方法：

class School : IEnumerable
{
    private Student[] students;

    public School(Student[] stus)
    {
        students = (Student[])stus.Clone();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return new PeopleEnum(students);
    }
}

其中PeopleEnum  是继承了IEnumerator接口的类型，用于foreach遍历。IEnumerator接口中包括了object IEnumerator.Current属性和public bool MoveNext()，public void Reset()方法。

如果使用了泛型T还会有T IEnumerator<T>.Current属性。

class PeopleEnum : IEnumerator
{
    private Student[] students;
    private int index = -1;

    object IEnumerator.Current => Current;
    public Student Current
    {
        get
        {
            return students[index];
        }
    }

    public PeopleEnum(Student[] stus)
    {
        students= stus;
    }

    public bool MoveNext()
    {
        index++;
        return index < students.Length;
    }

    public void Reset()
    {
        index = -1;
    }
}

我们额外添加了student数组和一个数组下标index。

其中foreach首先调用MoveNext()  方法，使其下标加1，判断是否越界。如果没有越界就通过Current取出目标值。可以看到如果没有使用泛型的话，返回的是object类型的值，这也是为什么foreach不需要我们进行强制类型转换的原因，即foreach会自动进行转换，缺点就是涉及到装箱拆箱，影响效率。但是这一点可以通过使用泛型避免，有点类似于C#中的ArrayList和List。

C#中的foreach实现原理最先出现在初晴神社。

• 某个类只能有一个实例；
• 它必须自行创建这个实例；
• 它必须自行向整个系统提供这个实例。

• 单例模式的类只提供私有的构造函数，
• 类定义中含有一个该类的静态私有对象，
• 该类提供了一个静态的公有的函数用于创建或获取它本身的静态私有对象。

优缺点

写法1（只适用于单线程环境）

由于单例模式只有一个实例，即没有继承，所以一般将其设为sealed。

同时把构造方法设为私有，防止从外部创建，我们可以定义一个静态的实例，在需要的时候创建该实例。

代码如下：

namespace _01_单例模式
{
    sealed class Singleton1
    {
        private static Singleton1 instance;
        private static Singleton1 Instance
        {
            get
            {
                if (instance == null)
                {
                    instance = new Singleton1();
                }
                return instance;
            }
        }

        private Singleton1()
        {

        }
    }
}

这种写法比较简单，只有在instance为空时才会创建实例，避免了重复创建。

缺点：该代码在单线程下可以正常工作，但在多线程环境下可能会出现问题。如果存在两个线程同时运行到if (instance == null) 并且instance还未创建，那么两个线程都会创建一个实例，这样就不再满足单例模式要求了。

写法2（可以在多线程中正常工作）

为了解决写法1的缺点，需要加上一个同步锁。写法如下：

namespace _01_单例模式
{
    sealed class Singleton2
    {
        private static object syncObj = new object();

        private static Singleton2 instance;
        private static Singleton2 Instance
        {
            get
            {
                if (instance == null)
                {
                    lock (syncObj)
                    {
                        if (instance == null)
                        {
                            instance = new Singleton2();
                        }
                    }
                }
                return instance;
            }
        }

        private Singleton2()
        {

        }
    }
}

在这个类里面创建了一个object专门用与互斥锁判断，同时用了两个if语句。第一个语句限制只有在instance为空时进行互斥判断，提高了效率。

而第二个if，假如有两个线程同时运行到了lock (syncObj) ，其中一个线程向下执行，创建instance。创建之后另一个线程继续运行，如果没有第二个if，第二个线程还会创建instance，不符合要求。

该类解决了多线程的问题，不过运用了两个if，依然比较复杂。

【推荐】写法3（利用静态构造方法）

其实C#中又一个方法能够确保只调用一次，即静态构造方法。所以可以利用这个特点实现单例模式。

代码如下：

namespace _01_单例模式
{
    sealed class Singleton3
    {
        private static Singleton3 instance = new Singleton3();

        public static Singleton3 Instance
        {
            get
            {
                return instance;
            }
        }

        private Singleton3()
        {

        }
    }
}

由于C#是在调用静态构造方法时初始化静态变量，在运行时能确保只调用一次静态构造方法，这样就能保证只初始化一次instance。

不过该方式依然有个小缺点：C#中的静态构造方法并非程序员控制，而是系统自动调用。假如Singleton3中有个静态方法，当我们第一次调用该静态方法时，instance就会被创建。但我们的本意希望调用Singleton3.Instance时创建。所以这个方式可能会过早的创建实例，降低内存使用效率。

【推荐】写法4（按需创建）

为了优化写法3，我们可以额外利用一个类。写法如下：

namespace _01_单例模式
{
    sealed class Singleton4
    {
        public static Singleton4 Instance
        {
            get
            {
                return Nested.instance;
            }
        }

        class Nested
        {
            internal static readonly Singleton4 instance = new Singleton4();

            static Nested()
            {

            }
        }

        private Singleton4()
        {

        }
    }
}

在Singleton4内部定义了一个私有类型Nested，当我们第一次调用Singleton4.Instance时，会自动调用Nested的静态构造方法创建instance。如果不调用Singleton4.Instance，就不会触发.Net运行时调用Nested，也不会创建实例，这样就做到了按需创建。

【设计模式】01 – 单例模式最先出现在初晴神社。

原则1：尽可能地使用属性，而不是可直接访问的数据成员

• 属性(property)一直是C#语言中比较有特点的存在。属性允许将数据成员作为共有接口的一部分暴露出去，同时仍旧提供面向对象环境下所需的封装。属性这个语言元素可以让你像访问数据成员一样使用，但其底层依旧是使用方法实现的。
• 使用属性，可以非常轻松的在get和set代码段中加入检查机制。
• 需要注意，正因为属性是用方法实现的，所以它拥有方法所拥有的一切语言特性：

• • 1）属性增加多线程的支持是非常方便的。你可以加强 get 和 set 访问器（accessors）的实现来提供数据访问的同步。
  • 2）属性可以被定义为virtual。
  • 3）可以把属性扩展为abstract。
  • 4）可以使用泛型版本的属性类型。
  • 5）属性也可以定义为接口。
  • 6）因为实现实现访问的方法get与set是独立的两个方法，在C# 2.0之后，你可以给它们定义不同的访问权限，来更好的控制类成员的可见性。
  • 7）而为了和多维数组保持一致，我们可以创建多维索引器，在不同的维度上使用相同或不同类型。
• 无论何时，需要在类型的公有或保护接口中暴露数据，都应该使用属性。如果可以也应该使用索引器来暴露序列或字典。现在多投入一点时间使用属性，换来的是今后维护时的更加游刃有余。

 原则2：偏向于使用运行时常量而不是编译时常量

• 编译时常量（const）的值会被目标代码中的值直接取代。
• 运行时常量（readonly）的值是在运行时进行求值。引用运行时生成的IL将引用到readonly变量，而不是变量的值。

• 编译时常量（const）仅能用于数值和字符串。
• 运行时常量（readonly）可以为任意类型。运行时常量必须在构造函数或初始化器中初始化，因为在构造函数执行后不能再被修改。你可以让某个readonly值为一个DataTime结构，而不能指定某个const为DataTIme。
• 可以用readonly值保存实例常量，为类的每个实例存放不同的值。而编译时常量就是静态的常量。
• 有时候你需要让某个值在编译时才确定，就最好是使用运行时常量（readonly）。
• 标记版本号的值就应该使用运行时常量，因为它的值会随着每个不同版本的发布而改变。
• const优于readonly的地方仅仅是性能，使用已知的常量值要比访问readonly值略高一点，不过这其中的效率提升，可以说是微乎其微的。

原则3： 推荐使用is 或as操作符而不是强制类型转换

• C#中，is和as操作符的用法概括如下。

• • is : 检查一个对象是否兼容于其他指定的类型,并返回一个Bool值,永远不会抛出异常。
  • as：作用与强制类型转换是一样,但是永远不会抛出异常,即如果转换不成功,会返回null。
• 尽可能的使用as操作符，因为相对于强制类型转换来说，as更加安全，也更加高效。
• as在转换失败时会返回null，在转换对象是null时也会返回null，所以使用as进行转换时，只需检查返回的引用是否为null即可。
• as和is操作符都不会执行任何用户自定义的转换，它们仅当运行时类型符合目标类型时才能转换成功，也不会在转换时创建新的对象。
• as运算符对值类型是无效，此时可以使用is，配合强制类型转换进行转换。
• 仅当不能使用as进行转换时，才应该使用is操作符。否则is就是多余的。

原则4： 推荐使用条件属性而不是#if条件编译

• 由于#if/#endif很容易被滥用，使得编写的代码难于理解且更难于调试。C#为此提供了一条件特性(Conditional attribute)。使用条件特性可以将函数拆分出来，让其只有在定义了某些环境变量或设置了某个值之后才能编译并成为类的一部分。Conditional特性最常用的地方就是将一段代码变成调试语句。
• Conditional特性只可应用在整个方法上，另外，任何一个使用Conditional特性的方法都只能返回void类型。不能再方法内的代码块上应用Conditional特性。也不可以在有返回值的方法上应用Conditional特性。但应用了Conditional特性的方法可以接受任意数目的引用类型参数。
• 使用Conditional特性生成的IL要比使用#if/#Eendif时更有效率。同时，将其限制在函数层面上可以更加清晰地将条件性的代码分离出来，以便进一步保证代码的良好结构。

原则5：理解几个等同性判断之间的关系

• C#中可以创建两种类型：值类型和引用类型。如果两个引用类型的变量指向的是同一个对象，它们将被认为是“引用相等”。如果两个值类型的变量类型相同，而且包含同样的内容，它们被认为是“值相等”。这也是等同性判断需要如此多方法的原因。
• 当我们创建自己的类型时（无论是类还是struct），应为类型定义“等同性”的含义。C#提供了4种不同的函数来判断两个对象是否“相等”。

• • public static bool ReferenceEquals (object left, object right);判断两个不同变量的对象标识（object identity）是否相等。无论比较的是引用类型还是值类型，该方法判断的依据都是对象标识，而不是对象内容。
  • public static bool Equals (object left, object right); 用于判断两个变量的运行时类型是否相等。
  • public virtual bool Equals(object right); 用于重载
  • public static bool operator ==(MyClass left, MyClass right); 用于重载
• 不应该覆写Object.referenceEquals（）静态方法和Object.Equals（）静态方法，因为它们已经完美的完成了所需要完成的工作，提供了正确的判断，并且该判断与运行时的具体类型无关。对于值类型，我们应该总是覆写Object.Equals（）实例方法和operatior==( ),以便为其提供效率更高的等同性判断。对于引用类型，仅当你认为相等的含义并非是对象标识相等时，才需要覆写Object.Equals( )实例方法。在覆写Equals( )时也要实现IEquatable。
• PS: 此原则对应于《EffectiveC# Second Edition》中原则6。

原则6：了解GetHashCode( )的一些坑

• GetHashCode( )方法在使用时会有不少坑，要谨慎使用。GetHashCode()函数仅会在一个地方用到，即为基于散列(hash)的集合定义键的散列值时，此类集合包括HashSet和Dictionary容器等。对引用类型来讲，索然可以正常工作，但是效率很低。对值类型来讲，基类中的实现有时甚至不正确。而且，编写的自己GetHashCode( )也不可能既有效率又正确。
• 在.NET中，每个对象都有一个散列码，其值由System.Object.GetHashCode()决定。
• 实现自己的GetHashCode( )时，要遵循上述三条原则：

• • 如果两个对象相等（由operation==定义），那么他们必须生成相同的散列码。否则，这样的散列码将无法用来查找容器中的对象。
  • 对于任何一个对象A，A.GetHashCode()必须保持不变。
  • 对于所有的输入，散列函数应该在所有整数中按随机分别生成散列码。这样散列容器才能得到足够的效率提升。
• PS: 此原则对应于《EffectiveC# Second Edition》中原则7。

原则7：理解短小方法的优势

• 将C#代码翻译成可执行的机器码需要两个步骤。C#编译器将生成IL，并放在程序集中。随后，JIT将根据需要逐一为方法（或是一组方法，如果涉及内联）生成机器码。短小的方法让JIT编译器能够更好地平摊编译的代价。短小的方法也更适合内联。
• 除了短小之外，简化控制流程也很重要。控制分支越少，JIT编译器也会越容易地找到最适合放在寄存器中的变量。
• 所以，短小方法的优势，并不仅体现在代码的可读性上，还关系到程序运行时的效率。
• 此原则对应于《EffectiveC# Second Edition》中原则11。

原则8：选择变量初始化而不是赋值语句

• 成员初始化器是保证类型中成员均被初始化的最简单的方法——无论调用的是哪一个构造函数。初始化器将在所有构造函数执行之前执行。使用这种语法也就保证了你不会再添加的新的构造函数时遗漏掉重要的初始化代码。
• 综上，若是所有的构造函数都要将某个成员变量初始化成同一个值，那么应该使用初始化器。
• PS: 此原则对应于《Effective C# Second Edition》中原则12。

原则9：正确地初始化静态成员变量

• C#提供了有静态初始化器和静态构造函数来专门用于静态成员变量的初始化。
• 静态构造函数是一个特殊的函数，将在其他所有方法执行之前以及变量或属性被第一次访问之前执行。可以用这个函数来初始化静态变量，实现单例模式或执行类可用之前必须进行的任何操作。
• 和实例初始化一样，也可以使用初始化器语法来替代静态的构造函数。若只是需要为某个静态成员分配空间，那么不妨使用初始化器的语法。而若是要更复杂一些的逻辑来初始化静态成员变量，那么可以使用静态构造函数。
• 使用静态构造函数而不是静态初始化器最常见的理由就是处理异常。在使用静态初始化器时，我们无法自己捕获异常。而在静态构造函数中却可以做到。
• PS: 此原则对应于《Effective C# Second Edition》中原则13。

原则10：使用构造函数链（减少重复的初始化逻辑）

• 编写构造函数很多时候是个重复性的劳动，如果你发现多个构造函数包含相同的逻辑，可以将这个逻辑提取到一个通用的构造函数中。这样既可以避免代码重复，也可以利用构造函数初始化器来生成更高效的目标代码。
• C#编译器将把构造函数初始化器看做是一种特殊的语法，并移除掉重复的变量初始化器以及重复的基类构造函数调用。这样使得最终的对象可以执行最少的代码来保证初始化的正确性。
• 构造函数初始化器允许一个构造函数去调用另一个构造函数。而C# 4.0添加了对默认参数的支持，这个功能也可以用来减少构造函数中的重复代码。你可以将某个类的所有构造函数统一成一个，并为所有的可选参数指定默认值。其他的几个构造函数调用某个构造函数，并提供不同的参数即可。
• PS: 此原则对应于《EffectiveC# Second Edition》中原则14。

原则11：实现标准的销毁模式

• GC可以高效地管理应用程序使用的内存。不过创建和销毁堆上的对象仍旧需要时间。若是在某个方法中创建了太多的引用对象，将会对程序的性能产生严重的影响。
• 这里有一些规则，可以帮你尽量降低GC的工作量：

• • 1）若某个引用类型（值类型无所谓）的局部变量用于被频繁调用的例程中，那么应该将其提升为成员变量。
  • 2）为常用的类型实例提供静态对象。
  • 3）创建不可变类型的最终值。比如string类的+=操作符会创建一个新的字符串对象并返回，多次使用会产生大量垃圾，不推荐使用。对于简单的字符串操作，推荐使用string.Format。对于复杂的字符串操作，推荐使用StringBuilder类。

• PS: 此原则对应于《EffectiveC# Second Edition》中原则16

原则12：区分值类型和引用类型

• C#中，class对应引用类型，struct对应值类型。
• C#不是C++，不能将所有类型定义成值类型并在需要时对其创建引用。C#也不是Java，不像Java中那样所有的东西都是引用类型。你必须在创建时就决定类型的表现行为，这相当重要，因为稍后的更改可能带来很多灾难性的问题。
• 值类型无法实现多态，因此其最佳用途就是存放数据。引用类型支持多态，因此用来定义应用程序的行为。
• 一般情况下，我们习惯用class，随意创建的大都是引用类型，若下面几点都肯定，那么应该创建struct值类型：

• • 1）该类型主要职责在于数据存储吗？
  • 2）该类型的公有接口都是由访问其数据成员的属性定义的吗？
  • 3）你确定该类型绝不会有派生类型吗？
  • 4）你确定该类型永远都不需要多态支持吗？

• 用值类型表示底层存储数据的类型，用引用类型来封装程序的行为。这样，你可以保证类暴露出的数据能以复制的形式安全提供，也能得到基于栈存储和使用内联方式存储带来的内存性能提升，更可以使用标准的面向对象技术来表达应用程序的逻辑。而倘若你对类型未来的用图不确定，那么应该选择引用类型。
• PS: 此原则对应于《Effective C# Second Edition》中原则18。

原则13：保证0为值类型的有效状态

• 在创建自定义枚举值时，请确保0是一个有效的选项。若你定义的是标志(flag)，那么可以将0定义为没有选中任何状态的标志（比如None）。即作为标记使用的枚举值（即添加了Flags特性）应该总是将None设置为0。
• PS: 此原则对应于《Effective C# Second Edition》中原则19。

原则14：保证值类型的常量性和原子性

• 常量性的类型使得我们的代码更加易于维护。不要盲目地为类型中的每一个属性都创建get和set访问器。对于那些目的是存储数据的类型，应该尽可能地保证其常量性和原子性。
• PS: 此原则对应于《Effective C# Second Edition》中原则20。

原则15：限制类型的可见性

• 在保证类型可以完成其工作的前提下。你应该尽可能地给类型分配最小的可见性。也就是，仅仅暴露那些需要暴露的。尽量使用较低可见性的类来实现公有接口。可见性越低，能访问你功能的代码越少，以后可能出现的修改也就越少。
• PS: 此原则对应于《Effective C# Second Edition》中原则21。

原则16：通过定义并实现接口替代继承

• 理解抽象基类（abstract class）和接口（interface）的区别：

• • 接口是一种契约式的设计方式，一个实现某个接口的类型，必须实现接口中约定的方法。抽象基类则为一组相关的类型提供了一个共同的抽象。也就是说抽象基类描述了对象是什么，而接口描述了对象将如何表现其行为。
  • 接口不能包含实现，也不能包含任何具体的数据成员。而抽象基类可以为派生类提供一些具体的实现。
  • 基类描述并实现了一组相关类型间共用的行为。接口则定义了一组具有原子性的功能，供其他不相关的具体类型来实现。

• 理解好两者之间的差别，我们便可以创造更富表现力、更能应对变化的设计。使用类层次来定义相关的类型。用接口暴露功能，并让不同的类型实现这些接口。
• PS: 此原则对应于《EffectiveC# Second Edition》中原则22。

原则17：理解接口方法和虚方法的区别

• 第一眼看来，实现接口和覆写虚方法似乎没有什么区别，实际上，实现接口和覆写虚方法之间的差别很大。

• • 接口中声明的成员方法默认情况下并非虚方法，所以，派生类不能覆写基类中实现的非虚接口成员。若要覆写的话，将接口方法声明为virtual即可。
  • 基类可以为接口中的方法提供默认的实现，随后，派生类也可以声明其实现了该接口，并从基类中继承该实现。
  • 实现接口拥有的选择要比创建和覆写虚方法多。我们可以为类层次创建密封（sealed）的实现，虚实现或者抽象的契约。还可以创建密封的实现，并在实现接口的方法中提供虚方法进行调用。

• PS: 此原则对应于《EffectiveC# Second Edition》中原则23。

原则18：用委托实现回调

• 在C#中，回调是用委托来实现的，主要要点如下：

• • 委托为我们提供了类型安全的回调定义。虽然大多数常见的委托应用都和事件有关，但这并不是C#委托应用的全部场合。当类之间有通信的需要，并且我们期望一种比接口所提供的更为松散的耦合机制时，委托便是最佳的选择。
  • 委托允许我们在运行时配置目标并通知多个客户对象。委托对象中包含一个方法的应用，该方法可以是静态方法，也可以是实例方法。也就是说，使用委托，我们可以和一个或多个在运行时联系起来的客户对象进行通信。
  • 由于回调和委托在C#中非常常用，以至于C#特地以lambda表达式的形式为其提供了精简语法。
  • 由于一些历史原因，.NET中的委托都是多播委托（multicast delegate）。多播委托调用过程中，每个目标会被依次调用。委托对象本身不会捕捉任何异常。因此，任何目标抛出的异常都会结束委托链的调用。

• PS: 此原则对应于《EffectiveC# Second Edition》中原则24。

原则19：用事件模式实现通知

• 事件提供了一种标准的机制来通知监听者，而C#中的事件其实就是观察者模式的一个语法上的快捷实现。
• 事件是一种内建的委托，用来为事件处理函数提供类型安全的方法签名。任意数量的客户对象都可以将自己的处理函数注册到事件上，然后处理这些事件，这些客户对象无需在编译器就给出，事件也不必非要有订阅者才能正常工作。
• 在C#中使用事件可以降低发送者和可能的通知接受者之间的耦合，发送者可以完全独立于接受者进行开发。
• PS: 此原则对应于《EffectiveC# Second Edition》中原则25。

原则20：避免返回对内部类对象的引用

• 若将引用类型通过公有接口暴露给外界，那么对象的使用者即可绕过我们定义的方法和属性来更改对象的内部结构，这会导致常见的错误。
• 共有四种不同的策略可以防止类型内部的数据结构遭到有意或无意的修改：

• • 1）值类型。当客户代码通过属性来访问值类型成员时，实际返回的是值类型的对象副本。
  • 2）常量类型。如System.String。
  • 3）定义接口。将客户对内部数据成员的访问限制在一部分功能中。
  • 4）包装器（wrapper）。提供一个包装器，仅暴露该包装器，从而限制对其中对象的访问。

• PS: 此原则对应于《Effective C# Second Edition》中原则26。

原则21：仅用new修饰符处理基类更新

• 使用new操作符修饰类成员可以重新定义继承自基类的非虚成员。
• new修饰符只是用来解决升级基类所造成的基类方法和派生类方法冲突的问题。
• new操作符必须小心使用。若随心所欲的滥用，会造成对象调用方法的二义性。
• PS: 此原则对应于《Effective C# Second Edition》中原则33。

原则22：尽量减少在公有API中使用动态对象

• 动态对象有一些“强制性”，即所有打交道的对象都变成动态的。若是某个操作的某个参数是动态的，那么其结果也会是动态的。若是每个方法返回了一个动态对象，那么所有使用过该对象的地方也变成了动态对象。
• 所以，若你要在程序中使用动态特性，请尽量不要在公有接口中使用，这样可以将动态类型现在在一个单独的对象或类型中。
• 应该将动态对象限制在最需要的地方，然后立即将动态对象转换为静态类型。当你的代码依赖于其他环境中创建的动态类型时，可以用专门的静态类型封装这些动态对象，并提供静态的公有接口。
• PS: 此原则对应于《Effective C# Second Edition》中原则44。

【转】【《Effective C#》提炼总结】提高Unity中C#代码质量的22条准则最先出现在初晴神社。

2018.5.6之前

这段时间主要是搭建框架，并完成了注册，登录，创建角色功能。

大致流程如下：

构思框架->设计服务端框架->设计通信协议->设计客户端框架->验证通信协议

由于这之前我并未有开发网络游戏的经验，所以这部分参考siki dalao的《丛林战争》和罗培羽dalao的《Unity 3D 网络游戏实战》，不过这两个项目跟《樱色伊始》需求有些出入，就综合了一下。

通信协议我分了四级，RequestCode –  ActionCode – ReturnCode – 内容

服务端：首先通过RequestCode 在Dictionary中查找对应处理Class，然后通过反射机制查找ActionCode对应的method，ReturnCode就是简单的结果码，诸如Success，Fail之类。

最后跟的就是内容，比如如果是登录功能：

User – Login – None – Username + Password

客户端：客户端维护了一个消息队列和委托Dictionary，在发送请求的同时处理返回结果的方法注册到Dictionary中。

客户端每帧处理若干条协议，通过Action匹配Dictionary中的委托。

服务端框架和客户端框架有些复杂，等之后我会再写篇文章进行详细解析。

// 设计协议的时候也有个坑，原型我是参考一本书的。刚开始使用没问题，后来在发送角色基本数据（协议数据比较长）的时候发现总会丢失4个字节的内容。

// 测来测去，最终发现是书上搞错了字符串的长度和字符串字节数组的长度。而这个bug在某些情况下又是不存在的。。

// 总之还是不要太相信“权威”

->实现创建，登录功能->实现选择，创建角色功能

->设计角色动作状态机

// 这个地方必须得吐槽下，没有合适的动作素材真难受，为了实现流畅的动作，我到处找素材，淘宝，论坛逛了一遍，始终没找到合适的。。

// 就现在用的动作还是从三套模型上抠出来的。。

->实现摄像机跟随角色的功能

// 这里有个细节，在实现摄像机自动拉近与被遮挡角色距离的时候，碰到射线无法检测部分物体的物品，后来发现是因为摄像机处于collider内部，而从内部发出的射线是无法检测collider边缘的。

// 换了下思路，改为从角色像摄像机方向发射射线，问题解决。

2018.5.6

回头看了下前段时间写的代码，发现有部分已经快看不懂了。。（捂脸）

论注释的重要性

今天添加了删除角色功能，不过删除确认还没做，等开发到之后扔掉背包物品和退出游戏时一并做吧_(:з」∠)_

做了这么久，最让我头痛的还是模型动作的问题，除非我愿意去学习3dsmax或者有建模师帮我，不然我真的一点办法都没有。。

只能先将就着用了。。

希望到时候面试时dalao不要介意。。

2018.5.7

今天是“沉重”的一天。。

让我担心的事最终还是发生了。。

设计客户端架构时经验不足，没有认真考虑到Unity执行脚本的生命周期而埋下的隐患，导致今天在改写功能的时候各种空指针引用。。

痛定思痛，花了点时间对核心脚本进行了重构，抛弃了先前的GameFacade脚本，并将其功能整合到了GameRoot脚本中。

暂时做如下设计

不知道效果咋样，等下课了回去试试_(:з」∠)_

*****************

改写之后，无bug一遍过

看来新结构行得通2333

2018.5.8 Scene加载与切换

今天试着做了下异步加载Scene功能_(:з」∠)_

目前游戏有四个Scene，加载流程如下

欢迎Scene -> 登录与注册相关Scene -> Load Scene -> 游戏Scene

其中Load Scene是专门用来显示加载进度条的，比如说从Scene 1 到 Scene 2，

Scene 1 中使用SceneManager.LoadScene() 直接加载LoadScene（因为很小，只有进度条，所以可以做到秒加载）

然后在LoadScene中使用SceneManager.LoadSceneAsyc()异步加载Scene2 ，加载过程通过其返回值AsyncOperation中的progress参数获取加载进度。

需要注意的是SceneManager.LoadSceneAsyc()加载完毕默认会直接切换到目标Scene，如果想手动控制切换时机的话设置AsyncOperation.allowSceneActivation为false，等到需要切换时再设为true。另外把allowSceneActivation设置为false后，Unity就只会加载场景到90%，剩下的10%要等到allowSceneActivation设置为true后才加载。

5.9 – 5.13

最近心态有点不好 T T

不过已经缓过来了，明天继续！

5.14

做了些UI，比如角色属性，状态栏啥的，

还有设计了下地图

好像没啥好说的。。

5.15 角色属性读取

目前设计的是将角色不同等级的基础属性，比如HP，暴击率什么的做成Json文件保存在客户端。在生成角色或角色升级时进行加载。

（数值设计暂且不考虑）

后期装备也准备这样做，角色总属性 = 基础属性 + 装备属性；

放在本地可以减轻服务器的压力，当然这样做有个很大的缺点，数据容易被篡改（作弊）。。

将其保存在服务器数据库实现起来应该不会太难，不过暂时先这样用着 _(:з」∠)_

5.16

增加了“删除角色”确认对话框，防止误删除；

完善了角色状态的UI显示，并能根据登录角色加载不同的角色到游戏中；

制作了角色暴击特效（暴击时在角色背后生成一个“假人”）；

开始制作包裹系统，由于以前有做过这个东西，所以大部分用的都是原来的代码，改动下就可以用了；

大致结构如下（不完整）：

5.17

新增了穿上、脱下装备以及同步属性面板的显示；

新增了使用药品，恢复HP，MP以及同步面板的显示；

重构基础战斗属性：HP，MP，攻击，命中率，穿刺，防御，闪避率，暴击率，暴击伤害为PropertiesModel类，并重载了其“+”，“-”操作符，使得两个PropertiesModel可以进行加减运算；

（使用场景，当穿戴一个装备时，角色的PropertiesModel+=装备的PropertiesModel）

角色持有3个PropertiesModel，一个为固定角色属性，一个为“装备属性和”，一个为总可变属性；

1.固定角色属性是指角色本身基础属性，由职业和等级决定；

2.“装备属性和”由角色所佩戴的装备决定，等于角色身上每件装备的PropertiesModel相加；

3.总可变属性由固定属性和“装备属性和”组成，其中的HP，MP字段会随着收到伤害，使用技能，使用药品等发生变化，主要用于战斗计算；

另外角色属性上限由固定角色属性和“装备属性和”构成，例如HP上限 = 基础HP + 装备HP，这个部分只有在装备发生变化时才会改变，战斗中收到伤害等情况下不会改变；

（穿上，脱下装备对HP，MP来说只会影响上限，当前HP也不会超过上限。例如角色当前HP为80/100，卸下了一个可以增加50HP的装备，HP变为50/50）

装备类物品在数据库中有个额外的标志位，“1”表示穿戴中，“0”表示未穿戴；

已知bug：

在某些情况下表示拾取中的物品的ItemUI会被Destroy，暂时没发现规律，也不知道怎么回事。。。

5.18

新增天气-雨天效果；

用粒子系统做的

emmm截图中雨滴看起来是矩形的，实际运行由于下落速度快还是挺好看的。。

顺便吐槽下剑灵的剧情。。

来个Happy Ending就那么难吗。。。

5.19

新增雨天音效，环境音效的播放；

新增小地图功能（具体做法可以看我之前的文章：在Unity中制作小地图）

新增商店功能，包括购买，出售物品及金钱的同步；

5.20

修复了出售商品时商品数量实际上不会减少的bug；

新增客户端与服务端的位置同步；

重构 PlayerController.cs 和 PlayerBattle.cs 合为Player.cs （历史总是惊人的相似）

重新设计了角色生成机制，为多人游戏做准备（脑阔痛）

5.21

说些题外话，sz做了这么久了，感觉自己的心境也在慢慢变化。

一开始只是想着做个属于自己的游戏，一步一步，一砖一瓦构建自己想要的游戏世界

但是现在，不知不觉把找工作当成了首要任务

经常担心这做不好，那做不好，面试官问起这个怎么办，做的不完美怎么办。。

有些时候真的对sz有了略微的恐惧心理 _(:з」∠)_

惭愧，可能是我对那个公司太喜欢了吧，很担心自己水平不够_(:з」∠)_

5.22 – ~~~

临近期末，各科都要做期末项目设计和实验报告，答辩啥的，比较忙。。

暂时挂起。。

《樱色伊始》开发日记最先出现在初晴神社。

可是如果元素类型没有实现IComparable<T>，或者默认的比较逻辑不符合要求，又该怎么办呢？

为了指定非默认的排序顺序，可以调用List<T>.Sort()的重载版本，它获取一个IComparer<T>作为实参。

首先我们需要了解一下IComparable<T>和IComparer<T>的区别：

IComparable<T>：“我知道如何将我自己和我的类型的另一个实例进行比较”；

IComparer<T>：“我知道如何比较给定类型的两个实例”；

很明显，IComparable<T>由需要排序的对象继承并实现，IComparer<T>需要另建一个类继承并实现；

来看下面这个例子：

首先新建一个需要排序的类Name：

class Name
{
    public string FirstName { get; private set; }
    public string LastName { get; private set; }

    public Name(string firstName, string lastName)
    {
        FirstName = firstName;
        LastName = lastName;
    }

    public override string ToString()
    {
        return String.Format($"{FirstName} {LastName}");
    }
}

然后新建一个比较类，继承并实现IComparer<T>接口：

class NameComparison : IComparer<Name>
{
    public int Compare(Name x, Name y)
    {
        if (Object.ReferenceEquals(x, y))
            return 0;
        if (x == null)
            return 1;
        if (y == null)
            return -1;

        int result = StringCompare(x.FirstName, y.FirstName);
        if (result == 0)
        {
            result = StringCompare(x.LastName, y.LastName);
        }

        return result;
    }

    public static int StringCompare(string x, string y)
    {
        if (Object.ReferenceEquals(x, y))
            return 0;
        if (x == null)
            return 1;
        if (y == null)
            return -1;

        return x.CompareTo(y);
    }
}

接下来在Main方法中调用：

class Program
{
    static void Main(string[] args)
    {
        List<Name> nameList = new List<Name>()
            {
                new Name("Michelle", "Green"),
                new Name("Susan", "Miller"),
                new Name("Susan",""),
                new Name("","Smith"),
                new Name("Keisey","Smith")
            };

        nameList.Sort(new NameComparison());

        foreach (Name item in nameList)
        {
            Console.WriteLine(item);
        }
    }
}

这样就能得到输出结果：

注意：实现IComparable<T>和IComparer<T>时必须生成一个全序。

CompareTo的实现必须为任何可能的数据排列组合提供完全一致的排序结果。

例如上述代码中考虑到了实参为null的情况。不能“任何一个元素为null就返回0,”，否则两个元素可能等于null，但相互不等，程序可能会崩溃！

C#中自定义集合排序最先出现在初晴神社。