Using System.gc() helped me with my image editing program.
But it is NOT full proof.
This is what I do:
When ma app no longer needs (a) bitmap(s), it calls *recycle()* (this will
clean up the memory - image data - that is part of your process, but not
part of the DalvikVM), nulls the Bitmap(s)
27.04.2011 22:50, dnkoutso пишет:
Also, I've read somewhere before the we should not just 'nullify' the
drawable reference. For example do not do bitmap = null; as this has
no effect. Instead just call bitmap.recycle() only.
recycle() seems a better option as it probably includes some native
Makes absolute sense. So how would I be able to clean those from my app? I
need to call recycle() myself? It also seems that the practice of using a
SoftReference for a drawable cache is not helpful (not unless you are
developing in HC).
Also, I've read somewhere before the we should not just '
I believe Java heap GC is triggered by various characteristics of the
Java heap.
If you don't have a lot of Java objects, there may not be anything to
cause those soft references to be collected. In the meanwhile, the
native heap may overflow.
I suspect it's one of the reasons why HC puts bi
Hey everyone,
I got an OOM. I know it has been covered alot by previous questions but mine
has to do with the internals of Android.
As I am loading images at random points I get this dreaded OOM exception.
I do have my images in an HashMap>. From the SoftReferences definition I
would expect
5 matches
Mail list logo
