On 11/22/2012 12:48 PM, Piren wrote:
Well, getting mad of this issue or trying to blame something else,
wouldn't really benefit you, would it?
Actually yes: it would not solve my crashes, but helps me to unload a
bit of stress, you know... ;-D
Also swearing is not incompatible with coding, I am doing both things at
same time ;-)
Absurd as much as it is, thats most likely what you got.
If you're so pressed on using so much memory, you can also resolve
this issue by allocating it in a different manner. This issue is
raised because the heap grew to 48MB prior to allocating the offending
bitmap, not because that bitmap is too big... if you can change the
way you do things so you'll never get to needing 48MB at the same time,
It is unlikely I need so much memory. In all the test I did, I never
used more than 30Mb. I do not know what determines the step that makes
the heap grow, but may be I just need 32Mb and the system decides to
allocate 48Mb by itself.
Anyway we are not sure about this being the source of the problem. As
told, I cannot discard even that heap information passed by Bugsense is
inaccurate.
Of course the crash is there, but the reason may be different and have a
more rational solution.
you'd avoid the issue. This is how i resolved it, just changed the
order of things i do and used stricter control on my memory allocation
so i'll never inflate the heap so much. If you have 15mb free at the
moment of the crash, it might indicate that you never needed to
increase the heap to that size anyway. Imagine you're playing memory
sokoban :)
you can also:
- use largeHeap=true and cross your fingers
This is useful at all? I mean, I do no think such devices will have a
heap bigger than those 48Mb (that as seen SHOULD be more than enough for
my app...)
- use added code to limit the requested bitmap quality dependent on
heap size. lower quality is better than crashing.
Well, this is more or less what I am doing right now, but it will make
users experience worse than they should be: they buy a xdpi screen, and
they will see only hdpi images... :-|
And the worst is that I am not sure that this will solve the OOM
problems, and some users complain about updating to often -probably
those that are not affected by crashes-, but it is better than spending
$6000 in different phones for testing that may -or not- fail for real
debugging.
- allocate the needed space on native memory manually. Although i
haven't done the same, i understand that when using native your limits
go up
- Come to terms with random crashes but enjoy your HD backgrounds
while they show:)
:-)
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
