Those errors are caught bei the default exception handler where I then
ask
how much memory is left (see below). Very often, like in the case from
below, there is plenty of memory left though.
I am wondering why this is?
AFAIK, Android's garbage collector is non-compacting. Hence, the
(Disclaimer: what follows is just my understanding of things and may be
quite wrong)
Bitmap memory management is complicated by the fact that the memory for
bitmaps is allocated in a separate native heap. The amount of memory
available in this native heap is the total memory allocation limit
Hey Mark.
AFAIK, Android's garbage collector is non-compacting. Hence, the issue is
not whether there is total free memory sufficient to allocate your bitmap,
but whether there is a single contiguous block sufficient to allocate your
bitmap.
Well, as the icons are just really small that
Hi Tom, thanks for taking the time.
On Wed, Oct 7, 2009 at 8:34 PM, Tom Gibara m...@tomgibara.com wrote:
1) Process starts up, generating a java heap allocation of 2MB.
2) Application initializes its state and allocates 2MB in the java heap.
3) Application creates a 2MB Bitmap which is
I think it's better to add a couple more columns to the table to see the
picture (as I see it) more clearly:
JH = Java Heap
JU = Memory actually used by Java
NH = Native Heap
TU = Total memory Used = JU + NH
TA = Total memory Allocated = JH + NH
(note I'm not distinguishing between native heap
Thanks for the detailed response Tom.
I understand the cause now.
You might try to pre-allocate bitmap memory before launching the WebViews?
It's not the WebView that's triggering the OOM, but some arbitrary other
piece of code that needs memory that is not *there* anymore. Very often this
is
6 matches
Mail list logo
