2

I'm working on a graphical app for which I want to keep an array of bitmaps that are used for Undo operations. The bitmaps are quite large at around 9M each, so I realise I can only keep a few in memory at any given time.

I'd like some way of working out in advance how many I can have.

I've tried various ways of querying available memory, and am being careful to recycle bitmaps once they are not needed, but despite that the app seems to crash with EOutOfMemory.

I don't want to scale down the bitmap, or use RGB565. I just want a reasonably reliable way to figure out how many undo steps I can allow for.

Thanks

EDIT #1

I've continued to try various ways of determining available memory, including those linked to in the comments, but still am having problems.

The strange thing is that my old Samsung I9000 phone doesn't have too many problems creating and accessing lots of bitmaps each 9MB in size, but my newer Samsung Tab 3 dies allocating the 3rd one.

It should have plenty of memory available. I did read something about there being differences in where memory is allocated for bitmaps on Android 3 and above, but don't fully understand it. Could this be what is causing my Tab to die with EOutOfMemory?

EDIT #2

In desperation I decided to turn on largeHeap in the manifest. I know it's not recommended, but it has made the Tab 3 behave more predictably, and it possibly demonstrates something about the underlying problem.

xtempore
  • 5,260
  • 4
  • 36
  • 43
  • http://stackoverflow.com/questions/6073744/android-how-to-check-how-much-memory-is-remaining. Also check this if it helps http://developer.android.com/training/displaying-bitmaps/manage-memory.html – Raghunandan Sep 20 '13 at 09:07
  • Use Async task and just return the thing in background method and not perform any calculation task there – Harsh Parikh Sep 20 '13 at 09:52
  • Another trick I saw was to dump the bitmap to the disk to free up RAM. It should make things slower as you'll need to write the bitmap to disk, then read it from disk when needed, but it should allow you to have more possible undo. Also you should be able to more precisely know how many bitmaps you can keep on disk before it becomes full. – user276648 Aug 27 '15 at 01:51

2 Answers2

0

This reminds me of a very common mistake , of putting the image files into the "res/drawable" folder.

Such a thing causes the bitmaps to take much more memory the higher the screen density is.

for example, for a 100x100 image, it would take only 100*100*4 = 40,000 bytes on an mdpi device, but it will take (2*100)*(2*100)*4 = 160,000 bytes on an xhdpi device (4 times more).

however, since the galaxy tab 3 doesn't seem to have a high density screen, i think that you get OOM because the heap size is small for holding all the bitmaps.

check out my post here for some memory and bitmaps tips.

Community
  • 1
  • 1
android developer
  • 114,585
  • 152
  • 739
  • 1,270
  • does it still make sense to check available memory on device before loading a bitmap? – stdout Feb 16 '21 at 13:25
  • 1
    @stdout Today it's less important, because starting from some Android version (Android O , and I wrote about this observation here: https://stackoverflow.com/q/48091403/878126 ) , Bitmaps data is stored in the normal RAM and not on the heap, and it's quite hard to use too much of it (devices have plenty of RAM today). However, technically, you should perform some checks , because now when OOM occurs, it won't let you capture it using try-catch, or it will cause something weird (I don't remember what). – android developer Feb 16 '21 at 14:01
0

It seems that getting available memory is a bit quirky in Android, but it turned out that my main problem was that on newer versions of Android the memory allocation for bitmaps has changed, and they now easily blow the limit of the heap.

Setting largeHeap in the manifest got me around that problem, but I'm still not sure it's ideal.

xtempore
  • 5,260
  • 4
  • 36
  • 43