On May 1, 7:55 am, Ward Willats goo...@wardco.com wrote:
Thanks -- I used hprof with a previous layout leakage problem, and I
think it is a huge turd on toast -- at least the default HTML output
anyway. Lot's of noise and very little insight. Maybe there are
better viewers for that data.
If
Okay, a nice OOM crash during inflation to start the morning.
VM won't let us allocate 67600 bytes
Caused by: java.lang.OutOfMemoryError: bitmap size exceeds VM budget
at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method)
at
On Apr 30, 8:23 am, Ward Willats goo...@wardco.com wrote:
But lordy, how in the heck does that thing jump from 1 MB to 11 MB
and back down again?? I surely don't have anything anywhere near that
size that I am aware of!
It's possible that it didn't actually jump back down. The event log
In my app, i've been dillegently 'unloading' bitmaps when i need
memory.
I clear out as much as I can.
E.g. when a view becomes invisible (onPause) or just before you start
loading a big bitmap:
- do a setImageBitmap(null) (or similar methods, depending on which
class of View you're actually
On Apr 30, 1:39 pm, Ward Willats goo...@wardco.com wrote:
It still seems like Voodo to me. If I have to manually call
setImageBitmap(null) it implies (to me) that the image view is not
being released in the first place, which means the view hierarchy is
not being released, even though I have
On Apr 29, 9:53 am, Ward Willats goo...@wardco.com wrote:
While I wait for a crash I can measure, my colleague here points out
we use a lot of 9 patches as backgrounds for various fields on our
screens. If they go into bitmap storage, and aren't regularly
compacted as we move from screen to
Google should do somethign about this feature... A lot of people get
OutOfMemory exception even if they don't do anything wrong.
Dalvik could and should be better. It is pretty slow compared to
native code 10 or 15 times depending on what you are doing.
Hope that JIT is comming soon on Android
Drawables are cached. So if you reuse the same 9patch in different
activities, you're good :)
On Wed, Apr 29, 2009 at 1:00 PM, fadden fad...@android.com wrote:
On Apr 29, 9:53 am, Ward Willats goo...@wardco.com wrote:
While I wait for a crash I can measure, my colleague here points out
we
On Apr 29, 9:41 am, Ward Willats goo...@wardco.com wrote:
Oh well, I switched to gawk and did this aeheap.awk (android external heap):
I got a Python script working. I believe this is the second python
script I've ever written, so it's probably not going to win any style
awards.
When a GC
At 11:19 AM -0700 4/28/09, Jon Webb wrote:
Like many others here I'm getting OutOfMemoryError from BitmapFactory
when decoding multiple bitmaps. I am sure I am not leaking memory.
I am scrupulously recycling bitmaps nulling pointers, etc.
Any ideas what's going on, or for a workaround?
+1
I have a clue -- the OutOfMemoryError went away when I set debuggable
to false. Does that help?
-- Jon Webb
On Apr 28, 2:59 pm, Ward Willats goo...@wardco.com wrote:
At 11:19 AM -0700 4/28/09, Jon Webb wrote:Like many others here I'm getting
OutOfMemoryError from BitmapFactory
when
On Apr 28, 12:05 pm, Jon Webb jonaw...@gmail.com wrote:
I have a clue -- the OutOfMemoryError went away when I set debuggable
to false. Does that help?
There's a known problem in the VM where exceptions don't get freed
while a debugger is attached. The state of the debuggable flag in
the app
On Apr 28, 1:33 pm, Ward Willats goo...@wardco.com wrote:
So am I really out of memory or just chasing my tail?
You're really out of memory.
Bitmap storage exists in a weird parallel universe. The memory isn't
allocated in the virtual heap, but we act like it is when it comes to
deciding if
On Apr 28, 6:28 pm, Ward Willats goo...@wardco.com wrote:
So this separate pile for bitmaps doesn't grow with the VM heap --
in fact, growing the VM heap made it smaller (I think) because, as
you say, that space came out of total 16 MB allocation (?)
Yup. The way you make more space for
14 matches
Mail list logo
