> I don't understand what's hogging the memory since the image is > already on the device, it's not being copied...
The image is stored on the device, but you still have to load it in RAM. > Is there something I should do to the ImageView to clear out it's > bitmap or something? There is nothing to clear out. You must be leaking something somewhere. Make sure you are not keeping any static reference (directly or indirectly) to an Activity or a Context for instance. Keeping such a reference will cause your application to leak everything on the first orientation change. > > confused.... > > On Oct 13, 5:40 pm, songs <[EMAIL PROTECTED]> wrote: >> I think we might be talking about a couple of different things. I've >> got a handle on the leak. What I'm saying is that there seem to be >> side-effects that change the assumptions of how the think about the >> lifecycle. From the perspective of the lifecycle and side-effects, I >> would have expected hitting the curved back arrow and then starting >> the app to have had the same effect as changing the orientation >> (except that the former would have had no saved state passed in and >> the latter would). This isn't the case. One has side-effects that >> the other doesn't so they behave differently. >> >> What about the lag? Even with cleaning up the thread, since it takes >> a couple of seconds for the system to actually reclaim the memory, a >> zealous user can still cause an OutOfMemoryError. >> >> On Oct 13, 3:05 pm, hackbod <[EMAIL PROTECTED]> wrote: >> >> > You need to make sure you have cleaned up everything by the time you >> > return from onDestroy(). If you do that, there will not be a leak. >> >> > On Oct 13, 1:46 pm, songs <[EMAIL PROTECTED]> wrote: >> >> > > This is a little confusing then, though. The animation thread dies as >> > > expected when I stop the application using the back arrow, but does >> > > not die (without being explicitly killed) when I flip the >> > > orientation. So some extra cleaning up must be happening for one that >> > > isn't happening for the other. >> >> > > Also, any ideas on the lag? >> >> > > On Oct 12, 11:00 am, hackbod <[EMAIL PROTECTED]> wrote: >> >> > > > onCreate -is- called when the activity is starting fresh. When an >> > > > orientation switch happens, the old activity is removed through >> > > > onPause()->onStop()->onDestroy(), and a new instance created in the >> > > > new orientation. >> >> > > > On Oct 11, 10:15 pm, songs <[EMAIL PROTECTED]> wrote: >> >> > > > > Tracked the leak down to my animation thread which was getting >> > > > > recreated on every onCreate. From the lifecycle docs, I had thought >> > > > > that onCreate only got called when the activity was starting fresh >> > > > > and >> > > > > any old instances had died (and killed everything associated with >> > > > > it). Since this apparently isn't always the case, I'm now managing >> > > > > this thread more actively. >> >> > > > > This mostly solved the issue except for two things - I can still get >> > > > > the memory issue to happen (I just have to try harder), and after >> > > > > changing the orientation it takes about 2-3 seconds before the app >> > > > > will respond to touch events. From watching the heap using DDMS, >> > > > > there's a good a couple of seconds between the thread dying and its >> > > > > resources getting cleaned up. Because of this lag, if I quickly >> > > > > switch back and forth between orientations I can get the memory error >> > > > > to happen. >> >> > > > > These remaining issues are kind of on outside of expected behavior so >> > > > > I'm not too worried about things now, but there's gotta be something >> > > > > I'm missing that would help button this up a little tighter. >> >> > > > > - Steve >> >> > > > > On Oct 10, 1:53 am, songs <[EMAIL PROTECTED]> wrote: >> >> > > > > > Interesting. Thanks for the lead. I'll look into this an report >> > > > > > back >> > > > > > either way. >> >> > > > > > On Oct 10, 1:48 am, "Romain Guy" <[EMAIL PROTECTED]> wrote: >> >> > > > > > > Then you should check carefully where exactly you pass your >> > > > > > > Activity >> > > > > > > (or Context) to other classes/APIs, etc. The Context is used by >> > > > > > > many >> > > > > > > different classes in the Android framework and if you somehow >> > > > > > > "leak" >> > > > > > > the Context, you leak all the views, images, etc. Your issue is >> > > > > > > very >> > > > > > > similar to several issues we fixed over the past few months: on >> > > > > > > each >> > > > > > > rotation the Context leaks and everything leaks with it. You can >> > > > > > > use >> > > > > > > DDMS to check how the heap is growing after each rotation, it >> > > > > > > should >> > > > > > > tell you whether this is the problem or not. >> >> > > > > > > On Fri, Oct 10, 2008 at 1:44 AM, songs <[EMAIL PROTECTED]> wrote: >> >> > > > > > > > Nope, the only static variables I have are constants. I do >> > > > > > > > keep an >> > > > > > > > array of Drawable in the view, but that's an instance variable. >> >> > > > > > > > On Oct 10, 1:14 am, "Romain Guy" <[EMAIL PROTECTED]> wrote: >> > > > > > > >> Looks like you're leaking memory somewhere. Do you keep a >> > > > > > > >> static cache >> > > > > > > >> somewhere in your app? >> >> > > > > > > >> On Thu, Oct 9, 2008 at 10:02 PM, songs <[EMAIL PROTECTED]> >> > > > > > > >> wrote: >> >> > > > > > > >> > Hi, >> >> > > > > > > >> > I think that either I've stumbled onto a bug or I'm missing >> > > > > > > >> > something >> > > > > > > >> > on how to manage my resources. I have an activity with a >> > > > > > > >> > Java based >> > > > > > > >> > view that contains 30 or so small images (~2k each .png) >> > > > > > > >> > that are >> > > > > > > >> > loaded into an array when the view is created. In "normal" >> > > > > > > >> > operation, >> > > > > > > >> > everything runs fine. When I flip the orientation between >> > > > > > > >> > landscape >> > > > > > > >> > and portrait 3-4 times, I get the following: >> >> > > > > > > >> > E/AndroidRuntime( 472): java.lang.OutOfMemoryError: bitmap >> > > > > > > >> > size >> > > > > > > >> > exceeds VM budget >> > > > > > > >> > E/AndroidRuntime( 472): at >> > > > > > > >> > android.graphics.BitmapFactory.nativeDecodeAsset(Native >> > > > > > > >> > Method) >> > > > > > > >> > E/AndroidRuntime( 472): at >> > > > > > > >> > android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:290) >> > > > > > > >> > E/AndroidRuntime( 472): at >> > > > > > > >> > android.graphics.drawable.Drawable.createFromStream(Drawable.java:635) >> > > > > > > >> > E/AndroidRuntime( 472): at >> > > > > > > >> > android.content.res.Resources.loadDrawable(Resources.java:1440) >> > > > > > > >> > E/AndroidRuntime( 472): at >> > > > > > > >> > android.content.res.Resources.getDrawable(Resources.java:498) >> >> > > > > > > >> > When the orientation gets changed, the activity seems to go >> > > > > > > >> > through >> > > > > > > >> > the entire lifecycle (pause, stop, then create again). A >> > > > > > > >> > new instance >> > > > > > > >> > of the activity's view is created in the onCreate method >> > > > > > > >> > and it seems >> > > > > > > >> > that the pause/stop steps in the lifecycle don't clean up >> > > > > > > >> > the old >> > > > > > > >> > view. I've tried explicitly setting the reference to the >> > > > > > > >> > view to null >> > > > > > > >> > in onPause and doing a System.gc(), but that doesn't seem >> > > > > > > >> > to help. >> > > > > > > >> > I've also tried setting the requested orientation to >> > > > > > > >> > portrait in hopes >> > > > > > > >> > that the activity would then ignore orientation changes, >> > > > > > > >> > but that >> > > > > > > >> > didn't work either. GC messages come up after every >> > > > > > > >> > orientation >> > > > > > > >> > change so one would think that the garbage collector was >> > > > > > > >> > doing its >> > > > > > > >> > job. >> >> > > > > > > >> > I could just leave this be and assume people aren't going >> > > > > > > >> > to be >> > > > > > > >> > randomly flipping their phone open and closed while they're >> > > > > > > >> > using my >> > > > > > > >> > app, but that seems pretty sloppy. I'd like to know what's >> > > > > > > >> > going on >> > > > > > > >> > here and fix it. >> >> > > > > > > >> > Any ideas? >> >> > > > > > > >> > Thanks, >> > > > > > > >> > Steve >> >> > > > > > > >> -- >> > > > > > > >> Romain Guywww.curious-creature.org >> >> > > > > > > -- >> > > > > > > Romain Guywww.curious-creature.org >> >> > > > -- Romain Guy www.curious-creature.org --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
