On Jul 31, 2012, at 9:56 AM, craig <[email protected]> wrote:
> http://mono-for-android.1047100.n5.nabble.com/file/n5711079/screen.png 

That looks like you're using a ListView or similar for the list at the bottom. 
Are you providing a custom BaseAdapter and overriding BaseAdapter.GetView(int 
position, View convertView, ViewGroup parent) method? If so, are you reusing 
the `convertView` parameter?

For example:

        
https://github.com/xamarin/monodroid-samples/blob/master/ApiDemo/Tutorials/GridViewTutorial.cs#L52
        
https://github.com/xamarin/monodroid-samples/blob/master/NotePad-Mono.Data.Sqlite/NoteAdapter.cs#L34

Reusing the `convertView` parameter will reduce gref count, reduce the number 
of objects that exist, and speed things up.

> I have implemented this but what I am seeing is that the application will 
> slowly eat more and more heap memory each time an arrow is clicked until the 
> point where starts to do constant, back-to-back, full Garbage collections.  
> This causes my app to run extremely slowly and crash.
> 
> http://mono-for-android.1047100.n5.nabble.com/file/n5711079/logcat.png 

That's...puzzling. The fact that it's running at 2173 grefs suggests that we 
think you're on an emulator, yet if you were on an emulator you would have 
crashed already (or our gref count is incorrect, which would be saddening).

Furthermore, given your followup (with explicit View disposal), that suggests 
that the GC isn't actually collecting the View instances; if it were, the gref 
count would decrease and the GC wouldn't be constantly running. Perhaps Java is 
referencing those instances elsewhere? (Or a GC bug?)

If you're not using BaseAdapter.GetView(), I would suggest enabling gref 
logging to see if any of your Views are ever collected (by looking for the -g- 
messages):

        http://docs.xamarin.com/android/advanced_topics/diagnostics
        
http://docs.xamarin.com/android/advanced_topics/diagnostics#Global_Reference_Messages

 - Jon

_______________________________________________
Monodroid mailing list
[email protected]

UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid

Reply via email to