GameObject的==的一个坑和一点GameObject的内部构造

一切都是因为==，才有了这篇博客

目录

• 测试
• 结果和分析
• 总结

测试

先放一段unity的一个普通的脚本

using UnityEngine;

public class UnityEngineObjectCheck : MonoBehaviour {
	void Start () {
		GameObject go1 = new GameObject ("go1");
		GameObject go2 = new GameObject ("go2");
		DestroyImmediate (go1);
		Debug.Log ("go1 == null : " + (go1 == null).ToString());
		Debug.Log ("go2 == null : " + (go2 == null).ToString());
		GameObject go = go1 ?? go2;
		Debug.Log ("go == null : " + (go == null).ToString());
	}
}

这里有个 ?? 运算符有点意思我也是查了MSDN文档

其意思就是对null的判别 ，a??b意思就是a为空则返回b，a不为null则不会对b进行表达式计算，??=运算符在此基础上多加了把b赋给a的功能

结果和分析

先预测一波结果：

1、go被销毁了，那么第一个输出将是go1 == null : True；

2、没有对go2进行操作，那么第二个输出应该是go2 == null : False；

3、通过??运算符、go1既然是null、那么go将会被赋值为go2。因此第三个输出将是go == null : False。

然而实际运行结果：

这说明了go1并没有完全销毁，他不是null，C#的对象由GC(Garbage collector)来管理对象的生存，destroy针对的是UnityGameobject的对象，UnityGameObject继承了UnityEngine.Object类,而object类重载了==和!=运算符，所以GameObject的== 和!=就相应的被重载了 。

所以上面使用==使用unity内置的对象判null方式，如果你的底层对象被destory了那就为null没问题，而使用其他的运算符时，这个C#对象还活着，也就会出现上面的问题。

总结

综上所述加上我查的一些资料：

可以初步认为

GameObject= C#包裹对象 + UnityEngineC++底层对象

Destroy处理的是C++底层对象，销毁然后C#对象里面的指向底层对象指针指向一个null，就完成了destory这一步。

gameobj == null的来历就是如此了，写代码的时候注意不要踩坑就行。

文章大部分来自该博客：https://blog.csdn.net/serenahaven/article/details/83381501