测试环境：Unity2018.4；.Net4.x。需要注意.Net4.x和3.5差异还是挺大的

写的内容大部分网上已有，算是总结他人的成果，是浅谈。

1、先说几条结论：

1_1、字符串在C#中是高频出现的

1_2、这类高频出现方法、字段通常不是每帧的性能瓶颈。但有可能是瞬间卡顿的来源。

1_3、字符串内存开销计算：26b(基础开销) + string.Length * sizeof(char)。如字符串“1”：28b开销

1_4、值类型，与字符串拼接不要偷懒，记得加上.ToString();

1_5、字符串拼接应尽量控制在4个以内

1_6、解决1_5中的问题

2、解释。

2_1、因为System.Object这个C#醉基础的类都有ToString();方法，其必然是个通用且极易出现的东西。

2_2、一个非常非常基础的东西如果存在性能问题，其上下文很有可能有问题或很可能存在更大的性能问题。如调用次数过高等。

2_3、此处是基础，且自己可能很轻松推算出。

2_4、开始正式聊C#字符串的拼接了。

2_4_1、即String.Concat方法，其内部有两类方法即String.Concat(string, string);和String.Concat(object, object);

2_4_2、string + string就不用说了，字符串拼接是字符串 + 字符串很合理。object + object同样也容易理解，字符串拼接时其参数可以是五花八门，且ToString()是System.Object内的方法，所以用object来承载参数是很合理的。它相当于String.Concat(object, object) -> String.Concat(object.ToString(), object.ToString());

2_4_3、那就意味着，值类型 + 字符串会走String.Concat(object, object);就以1 + "abc"为例

2_4_4、那首先，值类型 -> object存在一次装箱，以int类型为例，其内存开销为16b + sizeof(int)。即20b的开销，自然其也有cpu开销【但先忽略，因为其很低】。

2_4_5、其次object(1) -> string时，C#会生成字符串"1"，即28b开销。

2_4_6、最终结果为"1abc"，即34b开销。过程中共产生82b开销

2_4_7、如果写成1.ToString() + "abc"呢？首先1.ToString();开销28b，结果34b，共计62b。

2_4_8、主要问题就出现在值类型转object时的那次开销。次要问题，毕竟又多了object -> string开销。所以无论怎样，肯定是要加上.ToString();划算

2_5、String.Concat重载有很多，但直接传入的参数最多支持4个，超过4个时，如果是string相加，会走String Concat(params String[])。

2_5_1、以图中③处5个字符串相加时为例，C#会生成string[5]去容纳这些参数，其开销为32b + sizeof(char*) * 5 = 72。值得一提的是，在.Net3.5中，数组的起始开销是40b，所以此处在.net3.5中是80b，至于多出的8b是啥呢？可自己查查玩。

2_5_2、当我们真的用工具看其内存开销时，其开销是180b，这是因为.Net4.x中做了线程安全处理，即C#会将传入的string[5]套娃复制一遍，以免出现其他线程修改其内容的问题，所以这里会翻倍变成144b。再加上结果"12345"36b，就是180b

2_5_3、值得一说的是在.Net3.5中是没有线程安全这项处理的，所以其最终开销为80b + 36b = 116b。我TM谢你啊~

2_5_4、回到图中①处，4个字符串相加时34b，5个就飙升至180b，这里真的不可谓不坑爹。这也算C#这类以方便换性能所谓高级语言的一个毛病了。所以绝大多数引擎使用C++写代码是有原因的。

2_5_5、图中④处，其实并不是好思路，万一几个字符串长有一万米，那多算的一次result开销会远大于2次string[5]数组。但如果没有解决的问题，且拼接字符串都很短，这个方法可能有点用。但……内存碎片的隐患值得吗？

2_6、可以自行思考下，并且网上其实也有相关的解决方法，后面哪天有时间再写个字符串拼接更深入一些的内容。其实C#字符串操作方面可聊的实在太多，也可能等明年闲一点做个视频说下。