0

So, I tested my game out for the first time with the Monkey test. I managed to go about 3 minutes without a crash, but I ended up crashing with an out of memory error, and I'm trying to figure out how I might make it better.

My program is structured as follows:

  • There is a front screen which will start an activity.
  • The secondary activity is where most of the action is, and also where I crashed.
  • I crash on an inflate command
  • My game forces portrait mode, it was easier to make 1 layout than 2 work...
  • There are a number of class variables associated with my secondary activity. I'll include the non-static ones below. I've also included some kind of a clue for those things which aren't obvious as to what they are.

What I'm wanting to know is how I can improve the memory management of my program so it won't crash. I suspect that I need to manually delete some of these variables, but I'm not sure what the right place to do so is. Thanks!

private Level_Score_bar score_bar; // Custom view
private number_viewer num_viewer; // Custom view
private number_pad num_pad;       // Custom View
private int time,score,level,num_remaining,current_var,change_loc,time_remaining;
private ArrayList<Integer> the_key;
private ImageView Number_to_select;
private Boolean update_viewer; 
Random rseed;
Vibrator bzzz;
long ctime;
private Activity self=this;

private SharedPreferences prefs;
private Editor prefs_edit;

The out of memory occurred

   setContentView(R.layout.level_layout);

This layout is rather complex, containing several image views, buttons, text views, etc.

PearsonArtPhoto
  • 38,970
  • 17
  • 111
  • 142
  • It would be nice to know where in your code you got the OOM. If you can, post a stacktrace and relevant piece of code. Not really related, but according to the Java naming convention variables should not have an underscore (unless it is a static final) but rather be written together with the first letter in the next word capitalized: http://docs.oracle.com/javase/tutorial/java/nutsandbolts/variables.html – Jave Mar 29 '12 at 13:22
  • @Jave: Included the line with the out of memory. I should learn Java conventions someday as well, I might work on that... – PearsonArtPhoto Mar 29 '12 at 13:25
  • And what does the `R.layout.level_layout` contain? Large images or similiar? – Jave Mar 29 '12 at 13:26
  • @Jave: Quite a few things, but several image views, image buttons, text views, etc. None of them are particularly large, but I suppose they add up. – PearsonArtPhoto Mar 29 '12 at 13:31
  • If you have many ImageViews or load many large images, that could be the source of your problem. especially if you load them several times before the GC has had a chance to reclaim the memory. – Jave Mar 29 '12 at 13:39
  • 1
    Have you tried System.gc(); for calling manual garbage collector? – Pattabi Raman Mar 29 '12 at 13:50
  • @Raman-Mystry: No. That might be the trick, just call it in the onCreate()? – PearsonArtPhoto Mar 29 '12 at 13:51
  • @Pearsonartphoto: no it is not a trick. For imageviews using bitmaps, does not call default garbage collection, so the execution memory exceeds the allocated memory when images memory is higher. manual garbasge collection to be done to avoid memory leak. it is better to call in onresume() – Pattabi Raman Mar 29 '12 at 13:56
  • @Pearsonartphoto: i have answered your question. you can accept it if my answer worked for you. – Pattabi Raman Mar 29 '12 at 14:09

3 Answers3

3

So it turns out, I was right on the hairy edge of the Heap. I am using quite a few images, and it turns out that I was over the "normal" heap size. I've managed to improve this situation by shrinking some of the images, but the best solution came by changing my manifest to the following:

<application 
    android:label="@string/app_name" 
    android:icon="@drawable/logo" 
    android:screenOrientation="portrait" 
android:largeHeap="true">

The large heap will allow me to do future upgrades (Which will include level designs, etc, which would take up quite a bit of space...) All in all, it should be a pretty minimal affect.

I selected @Booger's answer as this was the piece which allowed me to do some research and figure out that my heap space just wasn't large enough, but I also included @Ramam-Mystry's piece of code.

I also used many answers from this excellent question in my quest. I started to store references instead of bitmaps, and a few other related bits. All in all, my memory consumption is down 25%, and continuing to improve.

Another tip could be to use the onLowMemory() function in Activity, trim the memory that's not needed then.

Community
  • 1
  • 1
PearsonArtPhoto
  • 38,970
  • 17
  • 111
  • 142
2

It sounds like you need to check out the "Allocation Tracker" tool, which is available in the "DDMS' Perspective in eclipse.

This will show you exactly which data structures are consuming memory.

Booger
  • 18,579
  • 7
  • 55
  • 72
  • I have a fair idea as to what is consuming memory, but I'm not quite sure what I need to do about it... – PearsonArtPhoto Mar 29 '12 at 13:50
  • You need to know exactly which component is causing your memory problem, than you can concentrate on fixing that. You can adjust your scope, to ensure the variables are created\deleted at the right time, you can also cache some of the frequently accessed items in memory, to ensure you are only creating a single instance. – Booger Mar 29 '12 at 13:57
1

Try by using System.gc(); in onresume() to avoid memory leaks on using high resolution or high memory pictures in imageview.

Note: For imageviews using bitmaps, default garbage collection is not called, so the execution memory exceeds the allocated memory when images memory is higher. manual garbasge collection to be done to avoid memory leak. it is better to call in onresume();

Pattabi Raman
  • 5,814
  • 10
  • 39
  • 60