Many Unity applications use a GameObject Pooling strategy to improve performance, see use object pooling.
That is, GameObject's are (re)used multiple times during a level or application lifetime. If a GameObject isn't needed, it gets deactivated and put in a pool. If the game later asks for that GameObject, it's retrieved from the pool and activated again. I use pooling for effects and sounds a lot for example.
When activating/deactivating a GameObject, the OnEnable() and OnDisable() methods of all Components on that GameObject are called.
The issue with ResonanceAudioSource.OnEnable is that 'mixer.FindMatchingGroups' allocates memory, which would cause an application, that uses a pooling strategy, to generate garbage memory during run-time.
Expected
Enabling/Disabling a ResonanceAudioSource should not allocate memory aka GC.Alloc and OnEnable/OnDisable should be kept fast.
Many Unity applications use a GameObject Pooling strategy to improve performance, see use object pooling.
That is, GameObject's are (re)used multiple times during a level or application lifetime. If a GameObject isn't needed, it gets deactivated and put in a pool. If the game later asks for that GameObject, it's retrieved from the pool and activated again. I use pooling for effects and sounds a lot for example.
When activating/deactivating a GameObject, the OnEnable() and OnDisable() methods of all Components on that GameObject are called.
The issue with ResonanceAudioSource.OnEnable is that 'mixer.FindMatchingGroups' allocates memory, which would cause an application, that uses a pooling strategy, to generate garbage memory during run-time.
Expected Enabling/Disabling a ResonanceAudioSource should not allocate memory aka GC.Alloc and OnEnable/OnDisable should be kept fast.