This seems to be vaguely related to one of my other projects (Android Play Expansions library). When using RemoteViews, the gref count went up like anything.
Simply by doing ”expandedView.SetTextViewText” or “expandedView.SetViewVisibility”, where expandedView was a RemoteViews, caused the gref count to shoot up. This was especially painful as this view was actually the download progress indicator on a notification. On slow connections the progress was reported far more times (smaller increments) and caused the device to run out of allocations. A work around was to try and only update the UI when there was a bigger increment. eg: 10KB instead of every few bytes. Not too drastic, but it sometimes seems to allocate more than necessary? Matthew Sent from my Windows 8 PC <http://windows.microsoft.com/consumer-preview> *From:* Jonathan Pryor <[email protected]> *Sent:* 31 July 2012 09:15:57 PM *To:* Discussions related to Mono for Android <[email protected]> *Subject:* Re: [mono-android] How to handle garbage collection? 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
_______________________________________________ Monodroid mailing list [email protected] UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
