[android-developers] Re: Memory Leak with a ListView revisited
I have already tried making the ListAdapter a completely separate
public class, and it does not seem to help. I can post that code, if
it would be helpful (perhaps I have something wrong with it).
Thanks.
On Oct 21, 5:33 pm, Mark Murphy wrote:
> Move your ListAdapter to a public class or a static inner class of
> your Activity, and see if that helps. A ListView being its own adapter
> is not a well-trod path.
>
>
>
> On Thu, Oct 21, 2010 at 8:04 PM, John Gaby wrote:
> > I am still struggling with a memory leak associated with a ListView.
> > I have created the following small program which exhibits this
> > behavior.
>
> > What I do is create 2 LinearLayouts. The first has a Button and a
> > GListView control. The code for GListView is below, but it just sub-
> > classes ListView, and implements the ListAdapter interface. When the
> > GListView is created, it sets it's adapter to itself.
>
> > Now when you press the button I switch to the second LinearLayout.
> > This layout has only a single button. When you press this button, I
> > create a new 1st layout with a new GListView and set it as the active
> > view.
>
> > Run the program, and switch between the two views 20 times. Then
> > bring up the DDMS and force a garbage collection. Then Dump the heap,
> > and use the Memory Analyzer and you will find 21 GListView objects
> > remaining. That is, the 20 GListViews that are not longer connected
> > to anything have NOT been freed.
>
> > Now if I comment out the 'setAdapter(this)' function in the GListView
> > constructor and repeat the above, I find that there is only 1
> > GListView that remains. That is, in this case, all of the unused
> > GListViews have been properly recycled.
>
> > Someone suggested that I create a private class within my GListView to
> > handle the ListAdapter interface, and I tried that, but it did not
> > help.
>
> > Surely there is some way to make these objects go away when they are
> > no longer used anywhere. (Isn't that what garbage collection is all
> > about?)
>
> > Any help would be appreciated. I am really pulling my hair out on
> > this one.
>
> > Thanks.
>
> > /*
> > * Activity
> > */
>
> > package com.gabysoft.memoryleak;
>
> > import android.app.Activity;
> > import android.os.Bundle;
> > import android.view.View;
> > import android.widget.Button;
> > import android.widget.LinearLayout;
> > import android.widget.ListView;
>
> > public class MemoryLeak extends Activity implements
> > android.view.View.OnClickListener
> > {
> > LinearLayout ll2;
> > boolean page2 = false;
>
> > private LinearLayout CreateLayout()
> > {
> > LinearLayout ll = new LinearLayout(this);
>
> > Button btn1 = new Button(this);
> > ListView lv = new GListView(this);
>
> > btn1.setText("Press");
> > btn1.setLayoutParams(new LinearLayout.LayoutParams(100, 40));
> > btn1.setOnClickListener(this);
>
> > ll.addView(btn1);
> > ll.addView(lv);
>
> > return(ll);
> > }
>
> > /** Called when the activity is first created. */
> > �...@override
> > public void onCreate(Bundle savedInstanceState)
> > {
> > super.onCreate(savedInstanceState);
>
> > CreateLayout();
>
> > LinearLayout ll = CreateLayout();
> > ll2 = new LinearLayout(this);
>
> > Button btn2 = new Button(this);
>
> > btn2.setText("Back");
> > btn2.setLayoutParams(new LinearLayout.LayoutParams(100, 40));
> > btn2.setOnClickListener(this);
>
> > ll2.addView(btn2);
>
> > setContentView(ll);
> > }
>
> > �...@override
> > public void onClick(View v)
> > {
> > if (page2)
> > {
> > LinearLayout ll = CreateLayout();
>
> > setContentView(ll);
>
> > page2 = false;
> > }
> > else
> > {
> > setContentView(ll2);
> > page2 = true;
> > }
> > }
>
> > }
>
> > /*
> > * GListView
> > */
> > package com.gabysoft.memoryleak;
>
> > import android.content.Context;
> > import android.database.DataSetObserver;
> > import android.view.View;
> > import android.view.ViewGroup;
> > import android.widget.AdapterView;
> > import android.widget.ListAdapter;
> > import android.widget.ListView;
> > import android.widget.TextView;
>
> > public class GListView extends ListView implements ListAdapter
> > {
> > Context m_context;
> > DataSetObserver m_observer = null;
>
> > public GListView(Context context)
> > {
> > super(context);
>
> > m_context = context;
>
> > setAdapter(this);
>
> > setChoiceMode(CHOICE_MODE_SINGLE);
> > }
>
> > /*
> > * ListAdapter
> > */
>
> > �...@override
> > public boolean areAllItemsEnabled()
> > {
> > return true;
> > }
>
> > �...@override
> > public boolean isEnabled(int position)
> > {
> > return true;
> > }
>
> > �...@override
> > public int getCount()
> > {
> >
[android-developers] Re: Memory Leak with a ListView revisited
As an experiment, I tried removing the GListView from it's parent
LinearLayout when I no longer needed it. When I did this, the garbage
collector was then able to recycle the parent (the LinearLayout), but
the GListView remained in memory and was not freed.
Using the Memory Analyzer, I can list the incoming references for one
of the GListViews which should be freed but is not:
Class
Name |
Shallow Heap | Retained Heap
---
com.gabysoft.system.GListView @ 0x43e6fec8
Unknown | 672 | 3,432
|- host android.view.View$ScrollabilityCache @
0x43e701b8 | 80 | 584
|- this$0 android.widget.AbsListView$RecycleBin @
0x43e70488| 40 |96
|- mCallback android.graphics.drawable.StateListDrawable @
0x43e70500 | 64 | 1,464
|- this$0 android.widget.AdapterView$AdapterDataSetObserver @
0x43e70d10| 16 |16
'- Total: 4
entries
| |
---
Does this give anyone a clue as to where the problem might be? Surly
I must be doing something wrong here. There cannot be this kind of
leak in general can there?
Thanks.
On Oct 21, 5:47 pm, John Gaby wrote:
> I have already tried making the ListAdapter a completely separate
> public class, and it does not seem to help. I can post that code, if
> it would be helpful (perhaps I have something wrong with it).
>
> Thanks.
>
> On Oct 21, 5:33 pm, Mark Murphy wrote:
>
> > Move your ListAdapter to a public class or a static inner class of
> > your Activity, and see if that helps. A ListView being its own adapter
> > is not a well-trod path.
>
> > On Thu, Oct 21, 2010 at 8:04 PM, John Gaby wrote:
> > > I am still struggling with a memory leak associated with a ListView.
> > > I have created the following small program which exhibits this
> > > behavior.
>
> > > What I do is create 2 LinearLayouts. The first has a Button and a
> > > GListView control. The code for GListView is below, but it just sub-
> > > classes ListView, and implements the ListAdapter interface. When the
> > > GListView is created, it sets it's adapter to itself.
>
> > > Now when you press the button I switch to the second LinearLayout.
> > > This layout has only a single button. When you press this button, I
> > > create a new 1st layout with a new GListView and set it as the active
> > > view.
>
> > > Run the program, and switch between the two views 20 times. Then
> > > bring up the DDMS and force a garbage collection. Then Dump the heap,
> > > and use the Memory Analyzer and you will find 21 GListView objects
> > > remaining. That is, the 20 GListViews that are not longer connected
> > > to anything have NOT been freed.
>
> > > Now if I comment out the 'setAdapter(this)' function in the GListView
> > > constructor and repeat the above, I find that there is only 1
> > > GListView that remains. That is, in this case, all of the unused
> > > GListViews have been properly recycled.
>
> > > Someone suggested that I create a private class within my GListView to
> > > handle the ListAdapter interface, and I tried that, but it did not
> > > help.
>
> > > Surely there is some way to make these objects go away when they are
> > > no longer used anywhere. (Isn't that what garbage collection is all
> > > about?)
>
> > > Any help would be appreciated. I am really pulling my hair out on
> > > this one.
>
> > > Thanks.
>
> > > /*
> > > * Activity
> > > */
>
> > > package com.gabysoft.memoryleak;
>
> > > import android.app.Activity;
> > > import android.os.Bundle;
> > > import android.view.View;
> > > import android.widget.Button;
> > > import android.widget.LinearLayout;
> > > import android.widget.ListView;
>
> > > public class MemoryLeak extends Activity implements
> > > android.view.View.OnClickListener
> > > {
> > > LinearLayout ll2;
> > > boolean page2 = false;
>
> > > private LinearLayout CreateLayout()
> > > {
> > > LinearLayout ll = new LinearLayout(this);
>
> > > Button btn1 = new Button(this);
> > > ListView lv = new GListView(this);
>
> > > btn1.setText("Press");
> > > btn1.setLayoutParams(new LinearLayout.LayoutParams(100, 40));
> > > btn1.setOnClickListener(this);
>
> > > ll.addView(btn1);
> > > ll.addView(lv);
>
> > > return(ll);
> > > }
>
> > > /** Called when the activity is first created. */
> > > �...@override
> > > public void onCreate(Bundle savedInstanceState)
> > > {
> > > super.onCreate(savedInstanceState);
>
> > > CreateLayout();
>
> > > LinearLayout ll = CreateLayout();
> > > ll2 = new LinearLayout(this);
>
> > > Button btn2 = new Button(this);
>
> > > b
[android-developers] Re: Memory Leak with a ListView revisited
On Oct 21, 9:29 pm, John Gaby wrote: > There cannot be this kind of leak in general can there? No, there cannot. You strategy looks foreign to me. Can you explain in english what you're trying to do and the strategy you're using to implement it? Why are you calling your CreateLayout twice in onCreate? And even worse, why are you calling it at all in an your onClick handler? Doug -- 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: Memory Leak with a ListView revisited
First, let me say that this is just a very simple sample application to illustrate the problem. My real application is far more complex, but exhibits this same behavior. What I need to be able to do is to be able to destroy a given page and then re-create it later. There are several reasons for this, but one of the main ones is that I want to free up the memory of a page which is no longer being actively used. Then when the user loads that page again, I simply re-create it. In Java, of course, there is really no way (that I know of) to free objects, you simply stop referring to them and the the garbage collector magically disposes of them at it's leisure. The problem is that it is simply NOT doing that for my GListView objects. I realize that this application doesn't represent something that you might actually do, but the fact is that if you take this program and run it, the GListView objects are NEVER freed, causing a memory leak. This is what I am trying to address. If I can understand why this is happening in this simple case, I might be able to figure out how to fix it in my actual program. Thanks. On Oct 22, 1:26 am, Doug wrote: > On Oct 21, 9:29 pm, John Gaby wrote: > > > There cannot be this kind of leak in general can there? > > No, there cannot. > > You strategy looks foreign to me. Can you explain in english what > you're trying to do and the strategy you're using to implement it? > Why are you calling your CreateLayout twice in onCreate? And even > worse, why are you calling it at all in an your onClick handler? > > Doug -- 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: Memory Leak with a ListView revisited
I too am finding a memory leak with the listview but no one has been able to tell me if I am doing anything wrong. I made a post on stackoverflow about it with sample code (dead simple example of a listview leaking there is a link to the whole project as a zip on the post as well). http://stackoverflow.com/questions/4218359/my-simple-listview-app-is-leaking-memory-what-am-i-doing-wrong If anyone could point out what im doing so terribly wrong with my code it would be much appreciated. TZ On Oct 22, 5:41 am, John Gaby wrote: > First, let me say that this is just a very simple sample application > to illustrate the problem. My real application is far more complex, > but exhibits this same behavior. > > What I need to be able to do is to be able to destroy a given page and > then re-create it later. There are several reasons for this, but one > of the main ones is that I want to free up the memory of a page which > is no longer being actively used. Then when the user loads that page > again, I simply re-create it. In Java, of course, there is really no > way (that I know of) to free objects, you simply stop referring to > them and the the garbage collector magically disposes of them at it's > leisure. The problem is that it is simply NOT doing that for my > GListView objects. > > I realize that this application doesn't represent something that you > might actually do, but the fact is that if you take this program and > run it, the GListView objects are NEVER freed, causing a memoryleak. > This is what I am trying to address. If I can understand why this is > happening in this simple case, I might be able to figure out how to > fix it in my actual program. > > Thanks. > > On Oct 22, 1:26 am, Doug wrote: > > > On Oct 21, 9:29 pm, John Gaby wrote: > > > > There cannot be this kind ofleakin general can there? > > > No, there cannot. > > > You strategy looks foreign to me. Can you explain in english what > > you're trying to do and the strategy you're using to implement it? > > Why are you calling your CreateLayout twice in onCreate? And even > > worse, why are you calling it at all in an your onClick handler? > > > Doug > > -- 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: Memory Leak with a ListView revisited
Why did you set setAdapter(this)? You implement ListAdapter for your ListView where getView(int position, View convertView, ViewGroup parent) it is already implemented. could you try without setAdapter. Example below, you make it in every place, it is not very nice. LinearLayout ll = CreateLayout(); setContentView(ll); My issue for you is create own class and implement ListAdapter, implement it and after that set as setAdapter(). On 24 Лис, 00:15, TZ wrote: > I too am finding a memory leak with the listview but no one has been > able to tell me if I am doing anything wrong. > > I made a post on stackoverflow about it with sample code (dead simple > example of a listview leaking there is a link to the whole project as > a zip on the post as well). > > http://stackoverflow.com/questions/4218359/my-simple-listview-app-is-... > > If anyone could point out what im doing so terribly wrong with my code > it would be much appreciated. > > TZ > > On Oct 22, 5:41 am, John Gaby wrote: > > > > > > > > > First, let me say that this is just a very simple sample application > > to illustrate the problem. My real application is far more complex, > > but exhibits this same behavior. > > > What I need to be able to do is to be able to destroy a given page and > > then re-create it later. There are several reasons for this, but one > > of the main ones is that I want to free up the memory of a page which > > is no longer being actively used. Then when the user loads that page > > again, I simply re-create it. In Java, of course, there is really no > > way (that I know of) to free objects, you simply stop referring to > > them and the the garbage collector magically disposes of them at it's > > leisure. The problem is that it is simply NOT doing that for my > > GListView objects. > > > I realize that this application doesn't represent something that you > > might actually do, but the fact is that if you take this program and > > run it, the GListView objects are NEVER freed, causing a memoryleak. > > This is what I am trying to address. If I can understand why this is > > happening in this simple case, I might be able to figure out how to > > fix it in my actual program. > > > Thanks. > > > On Oct 22, 1:26 am, Doug wrote: > > > > On Oct 21, 9:29 pm, John Gaby wrote: > > > > > There cannot be this kind ofleakin general can there? > > > > No, there cannot. > > > > You strategy looks foreign to me. Can you explain in english what > > > you're trying to do and the strategy you're using to implement it? > > > Why are you calling your CreateLayout twice in onCreate? And even > > > worse, why are you calling it at all in an your onClick handler? > > > > Doug -- 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: Memory Leak with a ListView revisited
In my particular case, I discovered that the leak ONLY happens when I am debugging the application. So my conclusion was that my issue, at least, had to do with some sort of issue with the debugger. On Nov 23, 2:15 pm, TZ wrote: > I too am finding a memory leak with the listview but no one has been > able to tell me if I am doing anything wrong. > > I made a post on stackoverflow about it with sample code (dead simple > example of a listview leaking there is a link to the whole project as > a zip on the post as well). > > http://stackoverflow.com/questions/4218359/my-simple-listview-app-is-... > > If anyone could point out what im doing so terribly wrong with my code > it would be much appreciated. > > TZ > > On Oct 22, 5:41 am, John Gaby wrote: > > > First, let me say that this is just a very simple sample application > > to illustrate the problem. My real application is far more complex, > > but exhibits this same behavior. > > > What I need to be able to do is to be able to destroy a given page and > > then re-create it later. There are several reasons for this, but one > > of the main ones is that I want to free up the memory of a page which > > is no longer being actively used. Then when the user loads that page > > again, I simply re-create it. In Java, of course, there is really no > > way (that I know of) to free objects, you simply stop referring to > > them and the the garbage collector magically disposes of them at it's > > leisure. The problem is that it is simply NOT doing that for my > > GListView objects. > > > I realize that this application doesn't represent something that you > > might actually do, but the fact is that if you take this program and > > run it, the GListView objects are NEVER freed, causing a memoryleak. > > This is what I am trying to address. If I can understand why this is > > happening in this simple case, I might be able to figure out how to > > fix it in my actual program. > > > Thanks. > > > On Oct 22, 1:26 am, Doug wrote: > > > > On Oct 21, 9:29 pm, John Gaby wrote: > > > > > There cannot be this kind ofleakin general can there? > > > > No, there cannot. > > > > You strategy looks foreign to me. Can you explain in english what > > > you're trying to do and the strategy you're using to implement it? > > > Why are you calling your CreateLayout twice in onCreate? And even > > > worse, why are you calling it at all in an your onClick handler? > > > > Doug -- 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
