17

I'm writing an image gallery app and I keep running into out of memory errors. I cache all my images but the problem occurs when I try switching between images really fast. I'm assuming the app is allocating memory faster than the GC has time to free them up (because the crash doesn't happen when I switch images slowly).

After banging my head against this problem for days, I finally decided to give largeHeap setting in the manifest file a try. After this setting, my app no longer crashes no matter how fast I switch between images.

Now, I want to know if there is any convention or general guideline to using largeHeap setting because it probably wouldn't make much sense if, say, a note taking app used largeHeap. Generally speaking, what apps are a good candidate for largeHeap setting?

Thanks

baekacaek
  • 1,527
  • 3
  • 22
  • 45
  • BTW, if you call `bitmap.recycle();` as soon as you are SURE you will not use a bitmap again, then the bulk of that bitmap's memory will be immediately freed. (When the GC gets around to it, all that remains is a tiny object.) – ToolmakerSteve Feb 28 '17 at 21:43

2 Answers2

23

Generally speaking, what apps are a good candidate for largeHeap setting?

Ones where you can justify to the user why you're forcing all their other apps out of memory, to give you an outsized amount of heap space.

Personally, I would not consider "an image gallery app" to qualify. AutoCAD, video editors, and the like would qualify.

With respect to your memory management issues, make sure that you are using inBitmap on BitmapOptions when running on API Level 11+, so you recycle existing buffers rather than go through garbage collection. Particularly for an image gallery, where you probably have a lot of fairly consistent thumbnail sizes, recycling existing buffers will be a huge benefit. This can help both overall memory consumption (i.e., you are truly out of memory) and memory fragmentation (i.e., you get an OutOfMemoryError with plenty of heap space, but no single block big enough for your allocation, due to Android's frakkin' non-compacting garbage collector).

You might also consider looking at existing image cache implementations, such as the one that Picasso has, to see if there are some tips you could learn (or possibly just reuse).

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Thank you for your answer! One question: I'm also building a gallery app, but I'm already using Picasso and still am having OutOfMemoryError. What do you think is the best thing to do? Using 'largeHeap=true' does fix this issue; do you think there are other things that I can do besides using this quick fix? – Karim Aug 04 '14 at 13:59
  • 3
    @Cookiki: "What do you think is the best thing to do?" -- figure out what your real problem is. Do you have a memory leak? Are you not reusing `Bitmap` objects where you could? And so forth. – CommonsWare Aug 04 '14 at 15:21
3

First, make sure you aren't loading larger bitmaps than necessary:
Load a Scaled Down Version into Memory.

Then, before trying largeHeap, try to free the memory quickly yourself:

If you call bitmap.recycle(); as soon as you are SURE you will not use a bitmap again, then the bulk of that bitmap's memory will be immediately freed. (When the GC gets around to it, all that remains is a tiny object.)

On newer Android versions, there are alternatives (instead of recycle) that may be more effective:
Managing Bitmap Memory

Personally, I still use recycle often, especially if I might be loading a different size image, so can't reuse the existing one. Also, I find it easier to code "unloading" of old media separately from "loading" of new media, when changing to a different fragment or activity:
As leave the old fragment, all old bitmaps I recycle (then, if reachable from a static field, set to null).

The rule of thumb for whether to use largeHeap, is to consider it after you've tried alternative ways to reduce memory usage.

Code your app so you could turn it off again, and still run.

For example, monitor your memory usage, and load "scaled down" bitmaps if memory is tight. Will the user really notice if a given image is not at their device's "retina" resolution?

Or if it is an older, slower, device, will largeHeap make your app feel unresponsive / jerky? If so, can you drop resolution even further, or show fewer bitmaps at one time?

Get your app to work in all circumstances, without largeHeap [by techniques mentioned above]. NOTE: you can "force-test" running on tight memory, by allocating some "dummy" bitmaps, and hold references to them in global fields, so they don't get freed.

NOW you are able to evaluate the trade-off, as it affects YOUR app:

When you do turn largeHeap on, use your app heavily - are there places where it is now "more sluggish", or animations "stutter" or otherwise seem less smooth? BE SURE TO TEST ON AT LEAST ONE OLDER DEVICE, AND ON ONE HIGH_RESOLUTION DEVICE. You might be seeing long GC times, due to the larger heap.

OR you might conclude that largeHeap is working well for you, and now you can confidently say that it is the best choice in your circumstance.

Community
  • 1
  • 1
ToolmakerSteve
  • 18,547
  • 14
  • 94
  • 196