Re: [android-developers] Memory Leaks in application
On Thu, Apr 7, 2011 at 5:16 AM, NURAIZ yousuf_...@yahoo.com wrote: Why our native heap size is increased every time we run the application? Based on the detailed information you provided, I can conclude with confidence that it's because you're using more memory every time you run the application. - TreKing http://sites.google.com/site/rezmobileapps/treking - Chicago transit tracking app for Android-powered devices -- 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] Memory Leaks with a ListView
John,
I've seen something similar causing memory leaks, preventing GC from
working, although not in Android:
public class Item {
static HashtablegHash = new Hashtable();
private String key;
public Item(String key) {
this.key = key;
gHash.put(key, this);
}
public void finalize() {
gHash.remove(this.key);
}
}
In your example, there is a circular reference, but the entire object is
orphaned. GC should work here, so there must be more to it.
I'd recommend you try switching to a separate class for the adapter.
Making it an non-static inner class of GListView would be quite convenient.
-- Kostya
20.10.2010 8:53, John Gaby пишет:
I have a class 'GListView' which extends ListView and acts as it's own
adapter. It is declared thus:
public class GListView extends ListView implements ListAdapter
In it's constructor, I set it's adapter to itself as follows:
public GListView(Context context ...)
{
...
setAdapter(this);
...
}
I then add this GListView to a ViewGroup. Later I release all
references to the ViewGroup, and yet the ViewGroup and the GListView
are never garbage collected.
Now if I don't do the 'setAdapter(this)' call, everything the garbage
collection works as expected, so it seems that setting the adapter to
itself is creating some kind of circular references that the garbage
collector is not able to sort out
I have tried calling setAdapter(null) when I no longer need the view,
but that does not seem to help.
Is having my GListView act as it's own ListAdapter something I simply
cannot do, or is there some way to make this work?
Thanks.
--
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
Re: [android-developers] Memory Leaks
On Mon, Oct 18, 2010 at 4:58 PM, John Gaby jg...@gabysoft.com wrote: I appear to have a memory leak(s) in my application, and I am trying to get a handle on it by trying to understand more about garbage collection. I have created the following application. Here I have a class 'MyClass', and I create an instance of that class in my 'onCreate'. I then null out the pointer which should leave no references to that instance. In 'MyClass', I override the finalize method so that I can see when the object is destroyed. When I run this program, the finalize method is never called, even if I call System.gc(), from within my program, or use the 'Cause GC' button using DDMS. (This is the same behavior that I see in my full application, by the way). Can someone explain to me more about what is going on here. I believe that in my main application, that I have objects that are not being freed. Is there some strategy for identifying those objects? Thanks. Ok, few things first: - Android does not reclaim the memory straight away even after the application gets closed. - System.gc() does not guarantee garbage collection in a timely manner. - When overriding finalize() you have to call super.finalize(). The fact that you did not see the log from finalize() does not mean it did not happen. Daniel -- 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] Memory leaks in activities and views
There must be something else going on in your app. All standard apps rely on onDestroy() being called and certainly do not do all you mentioned in your message. Be very careful with what you do with the Context. An Activity is a Context and you might be leaking it without knowing it. What you are observing is definitely not a normal behavior. On Mon, May 17, 2010 at 3:20 PM, ls02 agal...@audible.com wrote: We found there are very nasty memory and resource leaks in activities and views that we don't know how to handle. I have test app that basically starts activity A, that immediately starts activity B and B starts A and so forth in infinite loop. Each activity displays its own bitmap in image view. After X cycles JVM runs out of memory. There are no static or any other references to bitmaps or views or anything else. It seems that when one activity launches another a new instance of that activity is created (constractor is called, then onCreate, then onResume, the launching activity is paused and its onPause is called). onDestroy is almost never called. When new instance is created old one probably still holds references to view and bitmap so they are not freed. The only way we found to prevent JVM from running out of memory is to do ALL this from onPause and onDestroy: 1. Get image view drawable and set its callback to null. 2. Set image view background drawable to null. 3. Set ANOTHER view to activity (probably this removes activity reference from the image view). 4. Get the bitmap, call its recycle() method, set its handle to null and then run GC with System.gc(). If ALL these steps are executed JVM flips these image activities infinitely without running out of memory. Obviously, it is very hard to implement this solution when you have complex view with zillion of different images and more then a dozen of activities. What's the best and proper solution to aforementioned problem? -- 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
