C#中，所有的值类型均派生自System.ValueType，而System.ValueType则派生自System.Object
值类型是“轻“量的类型，内存开销上要比引用类型要小，原因是：
1.值类型不在拖管堆上分配
2.没有堆上的每个对象都有的额外成员：”类型对象指针”（type object pointer)和同步块索引（sync block index).
（这里的同步块索引会在GC的时候使用到）
但有的时候，我们需要将值类型转换成引用类型，这个过程就会产生“装箱”(boxing)的转换.
比如下面的代码：
public struct Point {
public int x;
public int y;
}
ArrayList a = new ArrayList ();
Point point;
for (int i = 0; i < 10; ++i) {
point.x = point.y = i;
a.Add (point);
}
Add接收的是一个object类型的参数，那么我们传入的是值类型，需要将值类型进行"装箱“，转换成object 类型并添加到ArrayList当中。
在装箱的过程中，都发生了哪些事情？
1.在拖管堆中分配内存，分配的内存量是由值类型的各个字段所需要的内存量决定，还要加上拖管堆中所有对象都有的额外
成员：类型对象指针和同步块索引
以上面Point为例，他有两个int字段，一个int字段是32位，占4个字节，2个int字段，就是8个字节，还有额外的两个成员（类型对象指针和同步块索引）的内存占用，如果是32位应用程序，那么各自需要32位的空间来存储，如果是64位，则各自需要64位的空间来存储，假设是32位应用程序，那么Point需要在堆中分配的内存空间是：
x占4字节+y占4字节+类型对象指针4字节+同步块索引4字节=16字节
当然，实际开发中，都要包含很多的字段，空间也会更大。
2.完成第一步的拖管堆的内存分配以后，第2步就要将值类型字段的值，复制到堆中的对应字段。
3.最后一步，返回对象的地址，现在该地址是对象引用，而不是值类型。
所以，如果我们装箱的操作放在Update中去执行话，就会不断的在拖管堆上分配内存，只要在拖管堆上分配内存就容易引起GC的调用，比如说内存超过第0代的预算时，GC就一定会调用来释放更多的空间。（C#中，GC调用是基于分代技术的，具体可以看我之前写的关于CLR垃圾回收，拖管堆的文章）
上面的例子中，我们直接通过ArrayList 来添加Point，仅是为了演示装箱的过程，实际上，可以使用泛型来避免装箱的操作，
比如：
ArrayList<Point> a = new ArrayList<Point>();
这样在Add时，就不会进行装箱操作了。
上面的装箱操作以后，就得谈谈拆箱(unboxing)了，即从引用类型转换为值类型，从字面上看，装箱和拆箱是相反的过程，但并不是这样，拆箱的性能开销要比装箱低得多。拆箱就是获取指针的过程。
Point p = (Point)a[0];
在拆箱的过程中，都发生了哪些事情？
1.获取已装箱Point对象中，各个字段的地址。
2.将字段包含的值从堆中复制到栈的值类型实例中。
在这个过程，也会有安全检查，如果已装箱值类型的字段为null，则抛出异常，另外，类型不匹配也会抛出异常
拆箱有着严格的限制，原类型和目标类型不一致是不可以进行转换的。
如下代码：
System.Int32 a = 10;
object o = a;
System.Int16 b = (System.Int16)o;
运行后会抛出异常：
InvalidCastException: Cannot cast from source type to destination type.
正确的操作是：
System.Int32 a = 10;
object o = a;
System.Int16 b = (System.Int16)(System.Int32)o;
先按原类型进行拆箱，再强制转换为short类型。
下面通过一些例子来演示装箱的拆箱的过程，加深理解：
Example 1：
Point p;
p.x = p.y = 1;
object o = p;//对P进行装箱，o引用已装箱的实例（装箱三步曲）
p = (Point)o;//对O拆箱，将字段从已装箱的实例复制到栈变量中
Example 2：
Point p;
p.x = p.y = 1;
object o = p;//对P进行装箱，o引用已装箱的实例（装箱三步曲）
p = (Point)o;//对O拆箱，将字段从已装箱的实例复制到栈变量中
p.x = 2;//更改栈变量p中x字段的值
o = p;//重新对p进行装箱，o引用新的已装箱的实例
Example 3：
System.Int32 v =5;
object o = v;
v = 123;
Console.WriteLine(v+","+(System.Int32)o);
上述代码发生了多少次装箱？
第1处： object o = v;//v被装箱，o指向堆中的地址
第2处&第3处：Console.WriteLine(v+","+(System.Int32)o);这一句，调用的Console.WriteLine(object,o1,object o2,object o3)的重载版本，所以v要装箱，并将已装箱的v在拖管堆中的地址传给参数o1，","是string引用类型，o2直接指向它，最后(System.Int32)o,是对引用o进行拆箱（但并没有紧跟着复制），这时候(System.Int32)o拆箱成为了值类型，但这个值类型要再一次的进行装箱，因为参数o3也是object类型的。
所以上面的代码一共进行了3次装箱操作，如果上面的输出很频繁，比如在Update中，那会不断的在堆中创建分配内存。会引起GC，所以一定要注意！
上面的代码，写成如下就会变得更加的有效率：
Console.WriteLine(v+","+o);
直接+o引用对象，去掉了一次装箱和拆箱，效率就高多了。
再看下面这种写法，只有一次装箱的操作，进一步提升代码的性能：
Console.WriteLine(v.toString()+","+o);
原因是v是值类型，值类型均继承自System.ValueType，而它又重写了toString()方法，所以toString()方法实际上是不会进行装箱转换的。
那么，如何确定我的代码都有哪些装箱和拆箱操作的地方呢？
.Net官方提供了一个ILDasm.exe工具，可以查看方法的IL代码，观察IL指令box/unbox都在哪些地方出现，并以此进行优化。
比如上面的代码中，我们通过ILDasm.exe工具进行查看如下：
先看Console.WriteLine(v+","+(System.Int32)o);这种情况：
（如果你是使用Unity测试的话，修改脚本后，Unity会生成程序集Assembly-CSharp.dll，位置在：工程目vi 录\Library\ScriptAssemblies\下，注意，每次重新生成时，要关闭ILDasm.exe，否则引用中，会生成失败）
将Assembly-CSharp.dll拖进工具里以后，会显示这样的树形结构，这是我当前类的目录结构，画圈的地方是
我当前运行的类App.cs，以及包含了上面执行代码的Awake()方法：
上红色的部分，可以对照上面文字说明的每一步，对应着拆箱和装箱的操作。
我们注意一个细节：IL代码的大小是56KB
下面我们使用中另一句输出，看看会有什么结果？
Console.WriteLine(v+","+o);
只进行了两次装箱，直接引用o，省去了一次拆箱和装箱的操作，IL的代码大小是46K，小了10K
我们再看看最后一种输出情况 ：
Console.WriteLine(v.toString()+","+o);
只有一次装箱操作，但空间只小了3K，原因是v调用了虚方法toString()
Example 4：
System.Int32 v = 5;
object o = v;
v =123;
Console.WriteLine(v);
v = (System.Int32)o;
Console.WriteLine(v);
这段代码，进行了几次装箱？
答案是只有一次装箱，Console.WriteLine方法有针对所有基元类型的重载方法，这里调用的是：
Console.WriteLine(int32)，这样就不需要进行装箱的操作。
如果是在Unity当中，我换成Debug.Log(v) 会如何呢？
System.Int32 v = 5;
object o = v;
v =123;
Debug.Log(v);
v = (System.Int32)o;
Debug.Log(v);
答案是3次，Debug.Log(v)调用了两次，进行了2次装箱操作，原因是Debug.Log只有一个实现版本，只接受一个object做为参数，
所以只要是值类型，都要进行装箱操作，这也是为什么在一些优化的文章中，建议要在正式的线上版本关闭掉Debug.Log，只保
留必要的输出即可。因为很多Log的输出都是包含值类型的转换，不断的在拖管堆中进行内存的分配，增加GC运行的次数，这是不可取的！
这里就想到了另一点，我们可以参考Console.WriteLine多个重载的版本，为Debug.Log也为所有的值类型提供重载版本，只需要调用各自的toString()即可，这样就可以避免装箱操作，而且我们为System.xxx下的类型提供重载版本以后，原始只接收object的方法就可以停止使用了，也方便我们通过开关进行控制。
下面这是在网上看到的例子，很有意思
int a = 10;
int b = 10;
int c = 10;
string d = "30";
string e = a+b+c+d;
Debug.Log(e);
结果是多少？
这里主要看匹配了string的哪个concat重载版本。
public static String Concat(params String[] values);
public static String Concat(params object[] args);
public static String Concat(String str0, String str1, String str2, String str3);
public static String Concat(String str0, String str1, String str2);
public static String Concat(String str0, String str1);
[CLSCompliant(false)]
public static String Concat(object arg0, object arg1, object arg2, object arg3);
public static String Concat(object arg0, object arg1, object arg2);
public static String Concat(object arg0, object arg1);
public static String Concat(object arg0);
会先执行a+b+c的结果=30
然后调用String.Concat(object,object)重载版本，进行字符串的连接。会进行一次拆箱。
string f = d+a+b+c;
这个结果是多少？
答案是30101010
a,b,c分别要进行三次装箱，而且最后调用的是String.Concat(params object[] args)重载版本进行连接。
并不是先计算d+a,返回值再加b，然后再加c，最后调用String.Concat(object,object)的版本。
我们要看+号左右是否满足运算的条件.
string g = a+b+d+c;
这个结果是多少？
答案是：203010
先计算a+b=20,20+d+c,则分别要进行2次装箱，调用String.Concat(object,object,object)重载版本。
string h = a+d+b+c;
这个结果是多少？
答案是：10301010
从左到右计算，a+d，需要将a进行装箱，d+b，b也要进行装箱，最后加c，则c也要进行装箱。三次装箱。
调用String.Concat(params object[] args)重载版本
再看下面这个例子，以下三种字符串的连接，哪种更高效？
string a = "a";
a+="b";
a+="c";
string a = "a";
string b = "b";
string c = "c";
string a = "a"+"b"+"c";
首先例子1,IL会定义字符串a,然后a+=b会调用一个String.Concat(string,string)进行字符串的连接操作，
然后再次调用String.Concat(string,string)，连接字符串c. 调用了2次String.Concat(string,string)函数
例子2，定义了三个字符串,a,b,c,然后执行一次函数的调用String.Concat(string,string,string) 生成的IL文件要小于例子1
例子3，相当于直接定义了"abc"字符串，效率最高，IL对此进行了优化，例子2其次，例子1最差。
这是例子3的IL代码，非常的简洁：
这是例子1的IL代码：
差距还是比较明显的。
最的再简单啰嗦装箱/拆箱的步骤：
装箱三步曲：1.拖管堆分配内存空间 2.复制字段的值到堆中 3.返回堆中内存地址.
拆箱：获取已装箱类型各个字段的内存地址，通常拆箱会紧跟着复制，2.将堆中字段的值复制到栈中值类型的字段中.
(不是每次拆箱都紧跟复制)
感谢阅读，如文中有误，欢迎指正.
