Here's what I do for my apps and it has solved all resource issues:
In each activity I have in onDestroy(), I do the following:
Release/clear all resources which have a release() or clear()
method.
Set all references to null.
When I write a custom view or any large data structure, I always add a
release() method which clears all references just to be really safe.
My code ends up looking like this:
protected void onDestroy() {
if (someList != null) {
someList.clear();
}
someList = null;
myPaint = null;
if (myCustomView != null) {
myCustomView.release();
}
myCustomView = null;
}
And follow romain's advice. Always delete references to Context or
anything that you passed the context to on clean-up. It's a huge one.
On Nov 30, 11:03 pm, Romain Guy <[EMAIL PROTECTED]> wrote:
> > 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 Guywww.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 [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
-~----------~----~----~----~------~----~------~--~---
