Which android version is this?
On Jul 31, 2012, at 12:33 PM, craig <[email protected]> wrote:
> It seems that there is some fundamental issue with garbage collection or else
> some fundamental knowledge that I am lacking.
http://docs.xamarin.com/android/advanced_topics/architecture
http://docs.xamarin.com/android/advanced_topics/garbage_collection
> I've read the articles about Mono for Android GC on the support site but it
> didn't really help me to understand what is happening here.
Let's try to clarify that.
> Here is a very simplified version with source code that behaves the same way.
> Can you please take a look. Thanks.
>
> *Activity Code*
> http://codeviewer.org/view/code:2890
The problem: as per the documentation, whenever you create a Java.Lang.Object
subclass (e.g. TextView), you allocate a Java instance and a global reference
(to associate the C# instance with the Java instance).
Which brings us to:
for (int i = 0; i < 50; i++)
{
TextView v = new TextView(this);
v.Text = (count * 50 + i).ToString();
layout.AddView(v);
}
This requires using 50 grefs (one per TextView). This is (in general) wasteful,
as all 50 items won't be displayed at once; only ~25 will (depending in display
size; I see 25 on my Galaxy Nexus, 21 on my API 15 emulator). Make the list
longer and things only get worse: the number of items that can be displayed is
fixed, while the number of items that can be in the list is variable. Requiring
a gref for invisible items in the list is wasteful, and this is where
BaseAdapter comes in.
I found that adding an explicit GC.Collect() to the end of the Button.Click
event handler caused the gref count to stabilize at 61 grefs. I'm still not
entirely sure how you got a 2200+ gref count on the emulator; that's puzzling.
:-/
- Jon
_______________________________________________
Monodroid mailing list
[email protected]
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
