1

I know there are many questions, forums about OOM in Android in different situations, but I couldn't find a complete solution.

I have an activity where the user can scroll between many animations. Since only the animation should move when scrolling and at the beginning it must move without the user interaction, I used a ViewFlipper with the animations inside. As the image bellow schematically shows: enter image description here

The problem is that on tablets and devices above 3.0 it throw OOM after flipping some animations and playing them. What I tried until now, in order to solve the problem:

  1. I scaled down the animation images using BitmapFactory.Options (I followed the tutorial Loading Large Bitmaps Efficiently tutorial). The only thing I didn't implement from the tutorial is the caching.
  2. Since there are many animations, so many bitmaps, I loaded only 3 animation at a time (the current view, the one on the left and the one on the right), but adding and removing bitmaps has slowed down too much the app.
  3. I tried to make the garbage collector to release faster my images, by manually calling everything that could help: setCallback(null), setImageDrawable(null), destroy(), destroyDrawingCache() (the last 2 for AdView). I even tryed recycle() (for Bitmaps), but it caused other exception

After the above changes there is some improvement, but I still receive OOM on an emulator Android 4.x WVGA854 or WVGA800 (after a longer period of time). But even when it doesn't trow OOM, the memory profiling shows 80% loading on the devices that were problematic to begin with. In addition the user experience is bad on all devices due to anim removal and addition.

I am starting to think is more an architecture/design problem. It might be an emulator problem? Do you now better memory profilers than the one in DDMS perspective?

I would be very grateful for any suggestion, I don't know what else to try:)

Laviniux
  • 364
  • 3
  • 10
  • have you tried to use system.gc()? – Niko Adrianus Yuwono Oct 18 '12 at 08:49
  • Thank you! As I said bellow, it seems that we should try to avoid that call as this questions(http://stackoverflow.com/questions/3117429/garbage-collector-in-android) shows. But I will try it to see the difference. – Laviniux Oct 18 '12 at 11:54

1 Answers1

2

usually I'm using this to prevent the out of memory problem

bmp.recycle();
bmp = null;
System.runFinalization();
Runtime.getRuntime().gc();
System.gc();

I'm calling it after I used the bitmap

if it's still didn't work maybe you should try it in the real device

Niko Adrianus Yuwono
  • 11,012
  • 8
  • 42
  • 64
  • Thanks, I tried bmp.recycle, but I didn't really help (Do you also need to load many bitmaps in the same activity?). Regarding System.gc() I read that is not ok to call it because there is a complex algorithm of recycling and by manually calling the GC that algorithm becomes useless, so I avoided. – Laviniux Oct 18 '12 at 11:05
  • 1
    hmmmm,yes I need to load many bitmaps in the same activity, and system.gc() solved it,but if you don't want to use it maybe some other solution like using fragments?have you tried it? – Niko Adrianus Yuwono Oct 18 '12 at 15:01
  • Framents seem like a very good idea, I will try that. Thank you very much NAYOSO:) – Laviniux Oct 19 '12 at 07:24