我的意思是，UnityEvents 比原生 C# 事件慢，而且它们仍然存储对接收器的强引用。因此，我能找到在原生 C# 事件上使用 UnityEvents 的唯一正当理由是它们与编辑器的集成。 我忽略了什么？
【问题讨论】：
我是否忽略了什么？
不，你没有忽略任何东西。使用UnityEvent 的唯一优势和理由是它允许您在编辑器中使用事件。这适用于拖放人员或制作编辑器插件的人员。
UnityEvent 的另一个优点是它可以防止由于滥用委托或将匿名委托与 Unity 对象一起使用而导致 Unity 对象未被释放的问题。尽管当持有它们的主脚本被销毁时，它们会被释放。这是因为UnityEvent 是用弱引用实现的，因此可以消除/最小化这个问题。这两件事仍然不值得在原生 C# 事件上使用 UnityEvent。
如果您不制作编辑器插件，您应该始终使用原生事件并委托 UnityEvent，因为它具有快速的性能和较小的内存使用量。有关更多信息，请参阅 this 和 this 帖子。
【讨论】：
Texture2D。
WeakEventManager 没有任何问题，然后再在完整游戏中使用它。重新阅读我的答案。我为UnityEvent添加了一个积分。
UnityEvent主要用于Unity UI系统，因为ugui需要在ui系统中序列化回调配置，比如按钮的OnClick回调。
序列化是unity游戏引擎中最重要的一个特性，c#内置事件系统，你不能做序列化。
所以如果你使用unity UI System，你必须使用UnityEvent，如果你想序列化回调函数配置，你必须使用UnityEvent。
在其他情况下，只需使用 c# 内置事件。
【讨论】：
在尚未讨论的软件设计方面，UnityEvents 优于原生 c#events：
c# 中的原生 events are no 'first class objects。
最后一个限制实际上是一个设计功能 - 如果您发现自己处于想要这样做的情况，可能您的软件架构搞砸了。
（例如，我正在开发一个具有“EventManager”的代码库，它只是一个仅托管几个事件的类，这些事件是从其他组件触发的——这是一个坏主意——但这远远超出了这篇文章。）
所以没有抱怨，这里的 c# 事件没有错。
但是，我最近多次遇到其他问题。 例如，UI 中的一个常见问题是，您想要一个事件的 OneShot 处理程序 - 即您想要为事件注册一个处理程序，该处理程序会在事件触发一次后自动删除。 例如，假设您在模态对话框中有一个按钮，该按钮应该是
Button.onClick.AddListener(OnButtonClicked);
但是，如果用户决定在 1. 动画期间再次按下按钮，您希望阻止单击处理程序再次执行。 如果这是一次性的事情，您只需从处理程序中的 click 事件中删除处理程序即可。
Button.onClick.RemoveListener(OnButtonClicked);
我们数百个这样的案例在我们的代码库中也有很大不同。 远远不够，我真的很想能够写：
Button.onClick.OneShot(OnButtonClicked);
为此实现扩展方法 - 以及其他类似的好东西 - 是
UnityEvent 或 UnityEvent<T> 这样的对象，但是我们为所有 Unity 事件添加了几个扩展方法，以便将我们现有的代码库转向更具反应性的风格。 话虽如此，但必须注意 UnityEvent 并不是最佳解决方案，原因有几个，这远远超出了这篇 SO 帖子的主题。 还是让我提一下，我们考虑使用像 UniRx 或 Rx.Unity 这样的库 - 如果反应式编程是您的团队共享的目标，那么做同样的事情可能会很聪明。
【讨论】：
Button.onClick -= OnButtonClicked吗？