注意,從國外文章看到UnityEvent系統(tǒng)比c#自帶的Event系統(tǒng)性能要差，但是好處是可以在編譯器可視化。其結(jié)果如下圖：

英語原文：

C# events beat?UnityEvent?for each number of arguments. The gap widens as more args are dispatched to the listeners. In the best case,?UnityEvent?takes 2.25x longer than C# events but in the worst case it takes almost 40x longer!

In conclusion,?UnityEvent?creates less garbage than C# events if you add more than two listeners to it, but creates more garbage otherwise. It creates garbage when dispatched (Update: the first time) where C# events do not. And it’s at least twice as slow as C# events. There doesn’t seem to be a compelling case to use it, at least by these metrics.?

然后是Update()和Event的性能比較，原文是

For anyone interested in this and stumbling upon it later, I have run three tests and the TLDR is: Unsurprisingly, do not use Update on too many game objects active in a scene at the same time, even on low frequency methods like this.

My test script simply spawns X amount of GameObjects based on a prefab that has either a

• a) script with the computation done in its Update method, （Update方程，每幀檢查）

  
  

• b) a script to subscribe to an event published by a manager behaviour, or （事件系統(tǒng)，觸發(fā)了才會運(yùn)行）

• c) a script that adds itself to a list to be later iterated through by the manager behaviour (based on?/u/Xeros778?suggestion). （觸發(fā)了遍歷的系統(tǒng)，具體寫法是：Maybe option three, by having the manager class directly call a public function on each gameobject. This would require no event calls, but would require the manner class to store a list of all objects.）

In all cases, the test method is called after 2 seconds have passed, with corresponding time checks done in the relevant Update method. The test method itself generates 10,000 random numbers from a base random - nothing useful or very computationally difficult. But the test method, ultimately, did not matter, as Update being present on Monobehaviours is the biggest drain.

For 20,000 game objects that run the test method in a 2 second interval,

a) 5.24ms CPU/frame, total memory 6.97 GB
b) 0.17ms CPU/frame, total memory 7.49 GB
c) 0.14ms CPU/frame, total memory 6.02 GB

總結(jié)，c勝者，b更占內(nèi)存，a非常消耗cpu

For 100,000 game objects, also running a test method in a 2 second interval:

a) 26.62ms CPU/frame, total memory 11.08 GB
b) 0.17ms CPU/frame, total memory 10.34 GB
c) 0.15ms CPU/frame, total memory 9.59 GB

同上，c是顯著勝者

So, the List option does somewhat better than Events in this test at least, also in regards to memory usage. Update is magnitudes worse compared to either approach.

Even without any computations done in Update, the mere presence of the method call is the culprit. I was not aware of the severity of this. 100k game objects active is of course a huge number, but still.

Depending on the weight of what actually needs to be calculated each interval, using a job system for the actual computations might indeed be worthwhile.