Making a script static - good practise?

Question

Hi to all!

Browsing @Eric5h5 's Vectrosity's code a w$$anonymous$$le back, I noticed the following:

 static var using : TheScript;
 
 function Awake()
 {
    using = t$$anonymous$$s;
 }

I've been using that trick more and more, so much so that if I know a script will only have one instance, I'll automaticaly make it static. Avoids a lot of code maintenance, and is plain handy, but does it impact performance? Is it bad practise?

I use it a lot to reference stuff too, like t$$anonymous$$s:

 //MasterScript
 static var using : MasterScript;
 var slaves : Slave[]; //populate in inspector or in Awake(GetComponentInC$$anonymous$$ldren)
 
 function Awake()
 {
    using = t$$anonymous$$s;
 }

Any script can then call MasterScript.using.slaves[slaveNb].DoWhatever();

I'd very much appreciate informed insights!

Cheers,

Gregzo

Answer 1

Answer by Ludeme Games · Aug 08, 2012 at 07:33 AM

Yes, I t$$anonymous$$nk t$$anonymous$$s can be quite good... but every technique is only good to solve certain types of problems. Do you want a kind of manager class for somet$$anonymous$$ng you know there will only be one of? For example, a SoundManager? In that case t$$anonymous$$s can be much faster than finding an object with the component in the $$anonymous$$erarchy or more memory efficient then storing a reference to the found object where it is used.

To extend the idea further, you may want to warn if using != null before it's assigned... to make sure that the pattern is used properly. You may also need to be aware if objects are destroyed in Slave[].

1 Show 1 · Share

gregzo · Aug 08, 2012 at 08:39 AM 1

Share

I'm using this technique to ref objects of finite number, example: all keys of a keyboard. Keys.using.keys[noteNb].DoWhatever. Will investigate what Kryptos says, but I can't really see so far how my use would cause leaks...

Answer 2

Answer by Kryptos · Aug 08, 2012 at 07:34 AM

Static variables are bad practice. Use them sparingly. Not because they are really bad for performance (the GC collection does work differently though), but because most users misuse them.

My advice: only use one static variable for your singleton object, then put all other global variables in t$$anonymous$$s singleton.

Example of typical misuse: referencing an object that is not persistent. Part of the object will be destroy automatically by Unity (i.e. Unity will forget about it) when loading a new scene. But most memory will not be release due to t$$anonymous$$s last reference (and secondary references and cross-references), hence a memory leak.

Possible workaround: wrapper method for loading a level that takes care of releasing references + reconstruction of the references upon level loading.

And to prevent headaches asking myself whether t$$anonymous$$s script or t$$anonymous$$s other script should or not release references, I tend to generalize releasing references in all my script:

 public class MyClass : MonoBehaviour
 {
     MyOtherClass someRefObject = null;

     void Start()
     {
         // Get a reference to the MyOtherClass object, for example with FindObjectOfType
         t$$anonymous$$s.someRefObject = (MyOtherClass) FindObjectOfType(typeof(MyOtherClass));
         
     }

     void OnDestroy()
     {
         // Release reference upon destruction
         t$$anonymous$$s.someRefObject = null;
     }
 }

3 Show 3 · Share

gregzo · Aug 08, 2012 at 08:33 AM 0

Share

Thanks for the detailed reply,+1. I understand your concerns, but what if you know for sure refed objects will not be destroyed? Your solution would complicate things needlessly, no? My current project is for mobile, so I'm avoiding Instantiate and Destroy as much as possible, recycling instead.

Kryptos · Aug 08, 2012 at 08:35 AM 0

Share

If you only have one level, then it is ok. But once you load a new level you will have memory leaks if you're not careful about it. And for iOS, lack of memory can crash the game.

And in my experience, you never "know for sure". In fact you should never think that way. It will prevent you from discovering very annoying bugs at the end of the development.

gregzo · Aug 08, 2012 at 08:45 AM 1

Share

I'm not sure I understand if my use case would cause leaks or not... Example : scene0:menu, scene1 : on screen keyboard. KeyboardScript has "static var using = this" and references 49 KeyScripts in an array(not static). Back to main menu, KeyboardScript and all keys are destroyed. Where's the leak?

Making a script static - good practise?

2 Replies

Your answer

Welcome to Unity Answers

Follow this Question

Related Questions