On Sep 11, 6:53 pm, fadden <[email protected]> wrote: > It works something like this:
Thanks Andy, this discussion has definitely clarified things for me. Of course the frustrating part is that we have no control over this code, so there's probably no way to influence its use of external memory. Short of forcing GCs, which I hate to do for a number of reasons, is there any way we can affect the heap management within our process, specifically to be more aggressive about finalizing objects and freeing their memory? It seems like the allocator needs to be smarter about the allocation/ free patterns of different processes, using a more adaptive algorithm to optimize heap use for different patterns of usage. Of course I know this is easy to say... On Sep 11, 7:23 pm, abliss <[email protected]> wrote: > This has proved very handy in Maps for dealing with OOM errors; > unfortunately the technique is not yet included in the framework that > MapView uses. Thanks for the input Adam. Do you have any suggestions about how developers can eliminate the OOM errors from apps written using the Maps framework in 1.5? Are there any levers we can use to force MapView to free up its bitmaps more aggressively? Do you know whether it's currently calling release() on them when it's done with them, or is it relying on the GC to free unreferenced Bitmaps? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
