0

For a few months now I have been testing my skills with AndEngine framework to develop games for Android.
Now I'm facing a confusing issue, in our project, we hold all TextureAtlas (i.e the textures) of an activity in a static HashMap in this activity. Could this generate some memory leak issue or unpleasant stuff like that ? I've heard lots of contradictory things of static variables in Android so I'm not sure what to think about that.

Note that screen rotation is blocked, so it's at least one trap less.

Thanks in advance !

Sephy
  • 50,022
  • 30
  • 123
  • 131

2 Answers2

2

Could this generate some memory leak issue or unpleasant stuff like that ?

Static data members in Java, by definition, are memory leaks. Those objects, and anything they reference, cannot be garbage collected, at least until the static reference to them is removed.

Whether this is a problem is another matter. Leaking a four-byte integer is not going to be an issue, for example. You can use DDMS to generate a heap dump and use MAT to examine it, to see "for realz" how much memory your static HashMap of TextureAtlas is.

For a static collection like a HashMap, the key will be to make sure that you are removing entries that you no longer need. Memory leaks become a problem when collections grow and grow and grow, because you keep adding things to them and never remove anything. Depending on your situation, a WeakHashMap (where the keys are held weakly, allowing the map entry to go away when nothing else is using your key) might be a better solution.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Thx for the answer. I will probably have to do this later on, when we have functionnal screens to see how the baby behaves. It might depend on the quantity of textures we put into the HashMap... – Sephy Dec 30 '12 at 17:00
1

static variables are bad when there is a back reference to the Activity instance. Because activities recreated several times in the life-cycle of the use of an app (for example when you switch your phone).

For example, the following code is safe:

private static Long mMyLong;

But this one is not safe :

private static Context mContext;

Be careful sometimes, there are some non obvious back references.

To avoid this kind of trouble you should store your static HashMap in your application class (you can find here my other post about application class creation https://stackoverflow.com/a/13994622/1789730). So your hashmap will be created once regardless of your activities lifecycle. Besides, you will gain in performance. To be really sur to not keep any reference, you can set to null the hashmap and its content in YourActivity.onDestroy() and recreate it in YourActivity.onCreate().

You can make the following experience to be sur if hashmap keeps any death references. Put the hashmap in the application class like said above. Flip your phone to portrait/landscape to recreate your activity. So if your activity crashes by using the hashmap objects, that means it keeps references to your activity.

Community
  • 1
  • 1
gezdy
  • 3,292
  • 2
  • 14
  • 14
  • Indeed, I knew of this problem with Context being recreated when flipping between landscape and portrait, though I'm not sure then that this leads to the same with TextureAtlas. The class has no reference to the context. thx for the answer – Sephy Dec 30 '12 at 16:57
  • So your question should be : "is TextureAtlas has a reference to the context?" Personnally I don't know, check it in the source code of ANdroid. – gezdy Dec 30 '12 at 17:01
  • well i'm asking for context but it's true for any other class that could cause an issue like this. Except that I'm not aware of any other than Context. Thus my question... – Sephy Dec 31 '12 at 11:46
  • I added a new paragraphe in my main post above. – gezdy Dec 31 '12 at 12:30
  • Interesting suggestion. Thanks for clarifying your point. I will test that. The only limitation to this solution is the size the map could reach if I put to much big objects in it. Though if I clean it in the activity onDestroy I should be ok. – Sephy Dec 31 '12 at 14:43