11

Folks, I don't think that this is a duplicate and is NOT one of those how do I avoid OOMs questions. This is a genuine quest for knowledge so hold off on those down votes please...

Imagine I have a JPEG of 500x500 pixels. I load it as ARGB_8888 which is as "bad as it gets".

I would expect Android to allocate 500x500x4 bytes = a little under 1MB however, look at a heap dump and you will see that Android allocates significantly more, often factors of 5-10 times greater.

You frequently see questions on here about OOMS where the stack trace shows a heap request of say 15MB and it is Always much larger than is required simply to hold the bytes of the image. The OP usually catches some downvotes then is bombarded with stock answers and comments about using less memory (thanks Romain!) and in scaling. I think there is more than meets the eye here.

Anybody know why this is?

If there is no apparent answer, I will put together an SSCCE if it helps.

PS. I assume that JPEG vs PNG etc is irrelevant since we're talking about the memory usage of the backing bitmap which is simply x times y times BPP - or am I being slow?

Hamad
  • 5,096
  • 13
  • 37
  • 65
Simon
  • 14,407
  • 8
  • 46
  • 61
  • 4
    Are you sure that you are not causing the image to be scaled by how you apply it (e.g., loading it into an `ImageView` that is not the same dimensions)? Moreover, when you looked at your heap dump, you should see precisely where the "factors of 5-10 times greater" allocations went -- where did you see those values wind up? "I will put together an SSCCE if it helps" -- please do. – CommonsWare Nov 10 '12 at 15:55
  • Ah. Looks like I might be being slow. Let me try an example and come back if and when I find that it's not scaling when applied. Thanks – Simon Nov 10 '12 at 16:01
  • Oddly enough, the guy in [this question](http://stackoverflow.com/questions/4866653/read-in-jpg-as-rgb888-on-android) *wants* and ARGB8888, but keeps getting an RGB565. Perhaps you can use his method? – GolezTrol Nov 10 '12 at 16:12
  • @GolezTrol. Thanks, but I am not trying to solve any problem, just trying to understand how Android allocates bitmap memory. – Simon Nov 10 '12 at 16:24
  • In my case if i put bitmaps into an ImageView the ImageView objects allocate about 2.3x the size of the actual bitmap. Android also seems to crash when it has to process a 200 kb bitmap and has less than 10 MB of memory left doesnt matter if its 2.x or 4.x – NikkyD Nov 10 '12 at 17:45
  • lol @ the Romain comment. Did you find any useful info? – StackOverflowed Aug 20 '13 at 17:19
  • 1
    @StackOverflowed Hi, I wish I had! I must admit that since I posted the question, I haven't had time to investigate it further and have parked it for now as "just the way it is". You have inspired me though. I might just download the source, hook it into my IDE and see if I can start to figure out what Android is doing. Seems inefficient to me..cheers – Simon Aug 20 '13 at 19:27
  • Please let me know if you discover anything! – StackOverflowed Aug 20 '13 at 19:28
  • can you share a memory dump? maybe your views have drawing cache enabled, maybe you are duplicating the memory as a side effect of sth else. android is definitely not allocating 10x memory for bitmaps. you can even convert Bitmap objects from thread dump to actual photo to verify (using gimp raw import). there is definitely sth else wrong here which should show up in the memory dump. – yigit Nov 29 '13 at 07:51

1 Answers1

1

It used to be quite a common trick with memory management to grab a pool or block of memory which is parceled out into smaller requests. When I worked with embedded systems it was a common practice to maintain pools of memory of different sizes, and we just allocated a block larger than the amount requested from a pool . It is a convenient way of preventing too much memory fragmentation. Maybe this is happening here.

vogomatix
  • 4,856
  • 2
  • 23
  • 46