[android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
Eclipse has so many moving parts, I don't think you should assume he knows by 'MAT' you mean the Open Source Project, Eclipse Memory Analysis Tool. On Sep 7, 8:11 pm, Romain Guy romain...@android.com wrote: It's not hard to debug. Dump the heap (with DDMS) and use a tool like MAT to see what's going on. On Tue, Sep 7, 2010 at 7:05 PM, Indicator Veritatis mej1...@yahoo.com wrote: It is one of the ironies of Java that though it is harder to write a memory leak than in C++, once you do manage it, it is harder to debug than in C++;) IBM developerworks has some good articles on it. So, for example, though the article is old, and mentions rather dated GC technology, I do believe that the hints in http://www.ibm.com/developerworks/java/library/j-leaks/are still pretty up to date for finding memory leaks. Unfortunately, he talks about using Jprobe, which I don't think you can run on an Android phone. But http://kohlerm.blogspot.com/2009/04/analyzing-memory-usage-off-your-a... suggests using the hprof-conv tool and describes how to do that. On Sep 7, 1:26 pm, Jason Van Anden robotiss...@gmail.com wrote: I have seen the same issue - and I suspect a memory leak. What would be best way to track something like this down? jOn Tue, Sep 7, 2010 at 3:08 PM, Romain Guy romain...@android.com wrote: It could also be a memory leak in your application. On Tue, Sep 7, 2010 at 12:06 PM, blahblah...@gmail.com blahblah...@gmail.com wrote: It's happening on the emulator when running 2.0 or 2.2. No compatibility mode AFAIK. I just did some testing and we are still getting OutOfMemoryError after changing screen orientation 3 times - it always gives the error the third time even though I added gc(); runFinalization(); gc() just before the createBitmap. I'm thinking it must be either a memory leak in Android or heap fragmentation. So far I don't have any workaround. On Sep 3, 2:40 pm, Matt Kanninen mathias...@gmail.com wrote: I found OutOfMemory Bitmap errors happened more frequently when I had a compatibility mode set. Although that was just on the Moto Droid, on Android 2.1, back in December. -- 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.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- 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.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- 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 -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- 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
Re: [android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
If this bitmap is used for drawing off-screen, then why are you recreating it every time the orientation changes? Screen size stays the same no matter what the orientation. You might need to use various matrix scaling methods in Canvas so that your drawing code works in either orientation. -- Kostya 08.09.2010 0:59, blahblah...@gmail.com пишет: More info - when I use meminfo the native allocated kb increases from 10MB to 15MB to 20MB after each screen orientation change, even though I am explicitly calling recycle() on the large bitmaps in our onDestroy (and I ran it in the debugger and verified that this code is being called). Also, when I reduce the size of the bitmap to the screen size (instead of twice the width and height of the screen) the native allocated only increases about 2MB each time, so it takes more screen orientation changes before the thing keels over (but it eventually does). So it looks like the bitmap is getting leaked somehow. We have no static members, and one thread is created (which exits after our onDestroy is called, which I have verified) and I've checked all our inner classes to make sure there is nothing getting leaked. So I'm pretty sure it's not our code leaking it (but I could be wrong). And even if it was a leak in our code, the explicit recycle() should have sorted it out. On Sep 7, 1:08 pm, Romain Guyromain...@android.com wrote: It could also be a memory leak in your application. -- Kostya Vasilyev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com -- 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
[android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
The workaround seems to be to put a System.gc(); System.runFinalization(); System.gc(); at the end of the onDestroy(). -- 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
[android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
It's happening on the emulator when running 2.0 or 2.2. No compatibility mode AFAIK. I just did some testing and we are still getting OutOfMemoryError after changing screen orientation 3 times - it always gives the error the third time even though I added gc(); runFinalization(); gc() just before the createBitmap. I'm thinking it must be either a memory leak in Android or heap fragmentation. So far I don't have any workaround. On Sep 3, 2:40 pm, Matt Kanninen mathias...@gmail.com wrote: I found OutOfMemory Bitmap errors happened more frequently when I had a compatibility mode set. Although that was just on the Moto Droid, on Android 2.1, back in December. -- 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
Re: [android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
It could also be a memory leak in your application. On Tue, Sep 7, 2010 at 12:06 PM, blahblah...@gmail.com blahblah...@gmail.com wrote: It's happening on the emulator when running 2.0 or 2.2. No compatibility mode AFAIK. I just did some testing and we are still getting OutOfMemoryError after changing screen orientation 3 times - it always gives the error the third time even though I added gc(); runFinalization(); gc() just before the createBitmap. I'm thinking it must be either a memory leak in Android or heap fragmentation. So far I don't have any workaround. On Sep 3, 2:40 pm, Matt Kanninen mathias...@gmail.com wrote: I found OutOfMemory Bitmap errors happened more frequently when I had a compatibility mode set. Although that was just on the Moto Droid, on Android 2.1, back in December. -- 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 -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- 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
Re: [android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
I have seen the same issue - and I suspect a memory leak. What would be best way to track something like this down? j On Tue, Sep 7, 2010 at 3:08 PM, Romain Guy romain...@android.com wrote: It could also be a memory leak in your application. On Tue, Sep 7, 2010 at 12:06 PM, blahblah...@gmail.com blahblah...@gmail.com wrote: It's happening on the emulator when running 2.0 or 2.2. No compatibility mode AFAIK. I just did some testing and we are still getting OutOfMemoryError after changing screen orientation 3 times - it always gives the error the third time even though I added gc(); runFinalization(); gc() just before the createBitmap. I'm thinking it must be either a memory leak in Android or heap fragmentation. So far I don't have any workaround. On Sep 3, 2:40 pm, Matt Kanninen mathias...@gmail.com wrote: I found OutOfMemory Bitmap errors happened more frequently when I had a compatibility mode set. Although that was just on the Moto Droid, on Android 2.1, back in December. -- 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.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- 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.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- 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
[android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
More info - when I use meminfo the native allocated kb increases from 10MB to 15MB to 20MB after each screen orientation change, even though I am explicitly calling recycle() on the large bitmaps in our onDestroy (and I ran it in the debugger and verified that this code is being called). Also, when I reduce the size of the bitmap to the screen size (instead of twice the width and height of the screen) the native allocated only increases about 2MB each time, so it takes more screen orientation changes before the thing keels over (but it eventually does). So it looks like the bitmap is getting leaked somehow. We have no static members, and one thread is created (which exits after our onDestroy is called, which I have verified) and I've checked all our inner classes to make sure there is nothing getting leaked. So I'm pretty sure it's not our code leaking it (but I could be wrong). And even if it was a leak in our code, the explicit recycle() should have sorted it out. On Sep 7, 1:08 pm, Romain Guy romain...@android.com wrote: It could also be a memory leak in your application. -- 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
[android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
It is one of the ironies of Java that though it is harder to write a memory leak than in C++, once you do manage it, it is harder to debug than in C++;) IBM developerworks has some good articles on it. So, for example, though the article is old, and mentions rather dated GC technology, I do believe that the hints in http://www.ibm.com/developerworks/java/library/j-leaks/ are still pretty up to date for finding memory leaks. Unfortunately, he talks about using Jprobe, which I don't think you can run on an Android phone. But http://kohlerm.blogspot.com/2009/04/analyzing-memory-usage-off-your-android.html suggests using the hprof-conv tool and describes how to do that. On Sep 7, 1:26 pm, Jason Van Anden robotiss...@gmail.com wrote: I have seen the same issue - and I suspect a memory leak. What would be best way to track something like this down? jOn Tue, Sep 7, 2010 at 3:08 PM, Romain Guy romain...@android.com wrote: It could also be a memory leak in your application. On Tue, Sep 7, 2010 at 12:06 PM, blahblah...@gmail.com blahblah...@gmail.com wrote: It's happening on the emulator when running 2.0 or 2.2. No compatibility mode AFAIK. I just did some testing and we are still getting OutOfMemoryError after changing screen orientation 3 times - it always gives the error the third time even though I added gc(); runFinalization(); gc() just before the createBitmap. I'm thinking it must be either a memory leak in Android or heap fragmentation. So far I don't have any workaround. On Sep 3, 2:40 pm, Matt Kanninen mathias...@gmail.com wrote: I found OutOfMemory Bitmap errors happened more frequently when I had a compatibility mode set. Although that was just on the Moto Droid, on Android 2.1, back in December. -- 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.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- 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.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- 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
[android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
I managed to recreate the bug with a very simple test case. It only happens when you place the Bitmap into a Canvas, so I think it is a memory leak in the Android Canvas code. I have logged a bug here: http://code.google.com/p/android/issues/detail?id=11089 As far as I can tell this bug will happen for any android app that uses Bitmaps with Canvas - basically it will crash with an out of memory error after you change screen orientation sufficient times (or do anything else that causes the activity to be destroyed and recreated). -- 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
Re: [android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
It's not hard to debug. Dump the heap (with DDMS) and use a tool like MAT to see what's going on. On Tue, Sep 7, 2010 at 7:05 PM, Indicator Veritatis mej1...@yahoo.com wrote: It is one of the ironies of Java that though it is harder to write a memory leak than in C++, once you do manage it, it is harder to debug than in C++;) IBM developerworks has some good articles on it. So, for example, though the article is old, and mentions rather dated GC technology, I do believe that the hints in http://www.ibm.com/developerworks/java/library/j-leaks/ are still pretty up to date for finding memory leaks. Unfortunately, he talks about using Jprobe, which I don't think you can run on an Android phone. But http://kohlerm.blogspot.com/2009/04/analyzing-memory-usage-off-your-android.html suggests using the hprof-conv tool and describes how to do that. On Sep 7, 1:26 pm, Jason Van Anden robotiss...@gmail.com wrote: I have seen the same issue - and I suspect a memory leak. What would be best way to track something like this down? jOn Tue, Sep 7, 2010 at 3:08 PM, Romain Guy romain...@android.com wrote: It could also be a memory leak in your application. On Tue, Sep 7, 2010 at 12:06 PM, blahblah...@gmail.com blahblah...@gmail.com wrote: It's happening on the emulator when running 2.0 or 2.2. No compatibility mode AFAIK. I just did some testing and we are still getting OutOfMemoryError after changing screen orientation 3 times - it always gives the error the third time even though I added gc(); runFinalization(); gc() just before the createBitmap. I'm thinking it must be either a memory leak in Android or heap fragmentation. So far I don't have any workaround. On Sep 3, 2:40 pm, Matt Kanninen mathias...@gmail.com wrote: I found OutOfMemory Bitmap errors happened more frequently when I had a compatibility mode set. Although that was just on the Moto Droid, on Android 2.1, back in December. -- 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.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- 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.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- 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 -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- 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
[android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
We can't split up the bitmap into smaller ones. It is a drawing program and we draw shapes to the offscreen bitmap. For now we have just put a gc() and recycle() before reallocating bitmaps, and also put a gc() at the end of onDestroy() as suggested in another thread. This is working so far, but I can see that running out of memory could be an issue in many other situations where you are dealing with large documents or graphics. On Sep 2, 8:07 pm, EnjoyLifeHappyEveryday--Jay Meng enjoylifehappyevery...@gmail.com wrote: hey blahblah...@gmail.comblahblah...@gmail.com We meet the same question,but we thought two ways to solve it: 1 cutting up a big bitmaps into many small bitmaps, less than 2M of every bitmaps, and then splitting joint small bitmaps 2 using virtual-point idea to call small bitmaps when is used at once and release small bitmaps when isn't used at once. Hope it useful for you. Best Regards. Jay Meng EnjoyLifeHappyEveryday CodeCore Groups -- 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
[android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
I found OutOfMemory Bitmap errors happened more frequently when I had a compatibility mode set. Although that was just on the Moto Droid, on Android 2.1, back in December. On Sep 3, 12:44 pm, blahblah...@gmail.com blahblah...@gmail.com wrote: We can't split up the bitmap into smaller ones. It is a drawing program and we draw shapes to the offscreen bitmap. For now we have just put a gc() and recycle() before reallocating bitmaps, and also put a gc() at the end of onDestroy() as suggested in another thread. This is working so far, but I can see that running out of memory could be an issue in many other situations where you are dealing with large documents or graphics. On Sep 2, 8:07 pm, EnjoyLifeHappyEveryday--Jay Meng enjoylifehappyevery...@gmail.com wrote: hey blahblah...@gmail.comblahblah...@gmail.com We meet the same question,but we thought two ways to solve it: 1 cutting up a big bitmaps into many small bitmaps, less than 2M of every bitmaps, and then splitting joint small bitmaps 2 using virtual-point idea to call small bitmaps when is used at once and release small bitmaps when isn't used at once. Hope it useful for you. Best Regards. Jay Meng EnjoyLifeHappyEveryday CodeCore Groups -- 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
[android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
We are also having occasional problems with OutOfMemory errors in createBitmap. It tends to happen after a few orientation changes when we are allocating the backbuffers. I have made it so that it calls recycle() on the old bitmaps (if any exist) and does a System.gc() before allocating the new backbuffers. Hopefully this will solve the problem, but I'm worried that it could still happen. What we are doing is allocating a backbuffer that is twice the width and height of the screen so that we can quickly zoom in and out. With a 854x480 screen this would presumably be 6.25MB in size. The problem as I see it is the 16 or 24MB maximum heap size per process. This is unreasonably small, especially on devices that have 512MB of RAM. Ideally the max heap size should be something like 64MB, or perhaps allow apps to request a larger heap size from the user. -- 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
Re: [android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
hey blahblah...@gmail.comblahblah...@gmail.com We meet the same question,but we thought two ways to solve it: 1 cutting up a big bitmaps into many small bitmaps, less than 2M of every bitmaps, and then splitting joint small bitmaps 2 using virtual-point idea to call small bitmaps when is used at once and release small bitmaps when isn't used at once. Hope it useful for you. Best Regards. Jay Meng EnjoyLifeHappyEveryday CodeCore Groups You received this message because you are subscribed to the Google Groups CodeCore group. To post to this group, send email to codecoregro...@googlegroups.com To unsubscribe from this group, send email to codecoregroups+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.ca/group/codecoregroups?hl=en 2010-09-03 09:57:53 发件人： blahblah...@gmail.com 发送时间： 2010-09-03 07:41:48 收件人： Android Developers 抄送： 主题： [android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed We are also having occasional problems with OutOfMemory errors in createBitmap. It tends to happen after a few orientation changes when we are allocating the backbuffers. I have made it so that it calls recycle() on the old bitmaps (if any exist) and does a System.gc() before allocating the new backbuffers. Hopefully this will solve the problem, but I'm worried that it could still happen. What we are doing is allocating a backbuffer that is twice the width and height of the screen so that we can quickly zoom in and out. With a 854x480 screen this would presumably be 6.25MB in size. The problem as I see it is the 16 or 24MB maximum heap size per process. This is unreasonably small, especially on devices that have 512MB of RAM. Ideally the max heap size should be something like 64MB, or perhaps allow apps to request a larger heap size from the user. -- 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 -- 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
[android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
On Jun 15, 10:36 pm, Romain Guy romain...@android.com wrote: Drawable s = mCtx.getResources().getDrawable(R.drawable.symbol_icon); Where s is a local variable to rendering. Suppose I call this 37 times. Am I to assume that Android will do something smart like create only one bitmap for this resource even if it is used 37 times? Drawables loaded from resources share as much data as possible. In this case, the 37 instances would use the same Bitmap data. Romain, are there any circumstances under which this would not be true? I'm maintaining an app where a large number of OutOfMemoryErrors are occuring in the field, all of them from the same line of code which is a call to setBackgroundResource(R.id.a-local- drawable). The implication seems to be that repeat executions of this line of code result in OutOfMemoryErrors. The stack trace is: BitmapFactory.java-2):-1:in `android.graphics.BitmapFactory.nativeDecodeAsset' BitmapFactory.java:464:in `android.graphics.BitmapFactory.decodeStream' BitmapFactory.java:340:in `android.graphics.BitmapFactory.decodeResourceStream' Drawable.java:697:in `android.graphics.drawable.Drawable.createFromResourceStream' Resources.java:-1:in `android.content.res.Resources.loadDrawable' Resources.java:580:in `android.content.res.Resources.getDrawable' View.java:-1:in `android.view.View.setBackgroundResource' One possible factor that might result in new memory usage is that the drawable is resized to fit in to the view. In its original form it's a 9-patch containing a color gradient, with different dimensions from the view it's loaded into. Any thoughts about what might be consuming additional memory in these calls, or how to prevent it? thanks, -Harry -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- 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
[android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
Still stuck here. Can anyone answer me the question of whether inPurgeable works? By works, I mean will the JVM go and purge all of those purgeable bitmaps before returning an OutOfMemoryError for CreateBitmap? Nathan -- 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
[android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
1) 3-4M for one image is a lot since you have total of 16M for the whole app! Dunno the answer to your question 2) 25*256K in bitmaps is already over 6,4M. Added to 1) makes already over 10M! AFAIK you should only use .recycle() if you really don't need them anymore. Unclear to me what really don't need means. 3) 32x32 pixels is about 204800 bytes if you count 4 bytes per pixel 4) These icons are probably not big right? The allocation tracker didn't give enough details for me, so am using the Eclipse Memory Analyzer Tool. Here's a pretty handy tutorial on how to use it detect memory leaks, maybe useful: http://ttlnews.blogspot.com/2010/01/attacking-memory-problems-on-android.html On 16 jun, 01:24, Nathan critter...@crittermap.com wrote: I'm running into OutOfMemoryErrors when allocating bitmaps. This is not something I can reproduce with emulators, and has been reported by a few beta testers with the HTC Incredible. I'm not sure I can solve this directly, and my best hope is to follow best practices for bitmaps and memory thereof. But looking for those best practices based on groups archives left me with more questions than answers. If anyone has a chapter about this in their book, I will buy the book. Here are the things I've mulled over so far: 1. I have a bitmap for a drawing buffer. It is about 3-4 megabytes on some devices. This is the biggest bitmap I have, and without it, I wouldn't be able to much of anything useful in my app. I am assuming that it would not be useful to use inPurgeable if this is a bitmap that is drawn into. Is this true? 2. Next biggest in the hierarchy are some bitmaps that are about 22K bytes and 256K unpacked. Since I believe about 25 of these might be used at one time, I have a cache with a size of 25. I am careful to use BitmapFactory.Options.InPurgeable, so I believe that could make them take only 22K each, but I don't see that as guaranteed. Maybe they are taking 256K each, which would put me in the danger zone. As they are cycled out of the cache, I call bitmap.recycle(). I think this a good practice. Is it? 3. Next are some resources with icon size 32x32 pixels. There are about 50 that could be used or reused. If I use code like this: Drawable s = mCtx.getResources().getDrawable(R.drawable.symbol_icon); Where s is a local variable to rendering. Suppose I call this 37 times. Am I to assume that Android will do something smart like create only one bitmap for this resource even if it is used 37 times? Or am I to assume that Android will do something stupid like create 37 bitmaps and keep references in an obscure location that will prevent garbage collection? Do I need to get more access to these bitmaps and do something smart myself? 4. Finally are some other icons used for menus and ImageButtons. Most are declared in layout files - so I don't touch the bitmaps directly. Can someone better informed than me comment on these assumptions? I'd like to make my memory usage more efficient, but don't want to spend time on things that will amount to shuffling chairs on the Titanic. And how do I best measure this usage? Interestingly enough, I've tried using the Allocation Tracker and it says I haven't allocated a single bitmap. In light of the above, I don't think that's right. Thanks in advance. Nathan -- 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
[android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
Maybe you can tell us what the 4 mb pictures is used for. Say if you are working on a game and it is your scrolling background, maybe you could use tiles instead and only have smaller chunks. I understand your question is about best practices, but maybe with a use case scenario of these bitmap someone can come up with a better strategy. I take it you also set the BitmapFactory.Options.inInputShareable to true so that BitmapFactory.Options.InPurgeable MIGHT not make a copy of the data ? Yahel -- 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
[android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
On Jun 16, 2:29 am, MarcoAndroid marco...@gmail.com wrote: 1) 3-4M for one image is a lot since you have total of 16M for the whole app! Dunno the answer to your question Yep 2) 25*256K in bitmaps is already over 6,4M. Added to 1) makes already over 10M! AFAIK you should only use .recycle() if you really don't need them anymore. Unclear to me what really don't need means. That you can't use the bitmap object for drawing after you call recycle. You'd have to recreate it. 3) 32x32 pixels is about 204800 bytes if you count 4 bytes per pixel I was thinking 4096 bytes. 4) These icons are probably not big right? No ,they are only 32x32 as well. At one point, though, I have 50 or so icons in a gridview. If I call: imageView.setScaleType(ImageView.ScaleType.CENTER_CROP); imageView.setImageResource(icon_id); Does anyone know if the ImageView will create and preserve a bitmap of the scaled up size? If so, that's bad, and I need to exert more control. The allocation tracker didn't give enough details for me, so am using the Eclipse Memory Analyzer Tool. Here's a pretty handy tutorial on how to use it detect memory leaks, maybe useful:http://ttlnews.blogspot.com/2010/01/attacking-memory-problems-on-andr... I think that will help. Nathan -- 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
[android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
On Jun 16, 3:43 am, Yahel kaye...@gmail.com wrote: Maybe you can tell us what the 4 mb pictures is used for. It's a screen buffer. It's not useful to me unless it covers the entire screen - and then some because of arbitrary rotation. So it can easily be a 908x908 image on Incredible. Say if you are working on a game and it is your scrolling background, maybe you could use tiles instead and only have smaller chunks. That's what the 25 or so chunks in number two are. But as pointed out here, they can be taking up even more room, albeit in smaller chunks. I believe the buffer saves me from rendering these 25 images and hundreds of smaller ones, plus some lines and points each time. I won't rule out eliminating the screen buffer, but I'd have to profile it. I take it you also set the BitmapFactory.Options.inInputShareable to true so that BitmapFactory.Options.InPurgeable MIGHT not make a copy of the data ? Yes. I set both of those. On 1.6 or higher that is. I can see that it is likely that inPurgeable is not effective enough for my cache of images in number two. If it were, there would be 6 megabytes of bitmaps that could be purged before returning failure. Since it is a hint, it's certainly possible that the HTC Incredible doesn't do much for it. If that holds up under analysis, then perhaps the best scheme to force purgeability at certain times. Nathan -- 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
[android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
I tried the Eclipse MAT tool. Really cool stuff. Unfortunately, it appears blind to bitmaps, at least so far. I was relieved to find out that the 4 Megabyte bitmap is only taking up 32 bytes. ;) The cache of 25 bitmaps was listed as the biggest suspect. But with a retained heap of 600K, this only includes the original bytes, and doesn't tell me if any of the uncompressed bitmaps are taking up memory. This is going to be a serious limitation of tools if they can't see bitmaps, especially if bitmaps are your biggest suspects for leaks. Romain, do you know if you can make any tool see bitmaps? Nathan -- 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
Re: [android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
Bitmaps are allocated on the native heap but their size is counted against the Java heap limit. You can use tools like MAT to see whether you are leaking Bitmap objects but you can't rely on these tools to measure the amount of memory used by those bitmaps. Thankfully, it's very easy to figure out how much memory is used by a bitmap :) On Wed, Jun 16, 2010 at 11:44 AM, Nathan critter...@crittermap.com wrote: I tried the Eclipse MAT tool. Really cool stuff. Unfortunately, it appears blind to bitmaps, at least so far. I was relieved to find out that the 4 Megabyte bitmap is only taking up 32 bytes. ;) The cache of 25 bitmaps was listed as the biggest suspect. But with a retained heap of 600K, this only includes the original bytes, and doesn't tell me if any of the uncompressed bitmaps are taking up memory. This is going to be a serious limitation of tools if they can't see bitmaps, especially if bitmaps are your biggest suspects for leaks. Romain, do you know if you can make any tool see bitmaps? Nathan -- 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 -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- 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
[android-developers] Re: Bitmaps and OutOfMemoryError: Best Practices needed
On Jun 16, 11:48 am, Romain Guy romain...@android.com wrote: Bitmaps are allocated on the native heap but their size is counted against the Java heap limit. You can use tools like MAT to see whether you are leaking Bitmap objects but you can't rely on these tools to measure the amount of memory used by those bitmaps. Too bad. Thankfully, it's very easy to figure out how much memory is used by a bitmap :) Not true in all cases. Look at BitmapFactory.Options: --- public boolean inPurgeable Since: API Level 4 If this is set to true, then the resulting bitmap will allocate its pixels such that *they can be purged if the system needs to reclaim memory*. In that instance, when the pixels need to be accessed again (e.g. the bitmap is drawn, getPixels() is called), they will be automatically re-decoded. For the re-decode to happen, the bitmap must have access to the encoded data, either by sharing a reference to the input or by making a copy of it. This distinction is controlled by inInputShareable. If this is true, then the bitmap may keep a shallow reference to the input. If this is false, then the bitmap will explicitly make a copy of the input data, and keep that. Even if sharing is allowed, the implementation may still decide to make a deep copy of the input data. - Unless you assume using inPurgeable is utterly useless, I can't tell if those bitmaps are being purged when necessary. That means that bitmap is using either 0, 29K bytes, 256k bytes. That's quite a range. In total, that means that this bitmap collection is using somewhere between 600K bytes and 7K bytes. Quite a range also. So is inPurgeable useless or does it work? Nathan -- 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
