La question principale: est-ce un problème réel? Les éboueurs sont, par nature, non déterministes, donc l'utilisation de la mémoire variera beaucoup. Ce n'est pas nécessairement un problème. C'est juste une partie de la façon dont les choses sont. Si vous manquez régulièrement de références globales ou épuisiez le tas de processus, c'est un problème. Si vous constatez simplement une augmentation du nombre de grefs, mais qu'ils diminuent quand une collection se produit naturellement, cela ne vaut peut-être pas la peine de vous inquiéter.
Si c'est un problème, nous avons besoin de détails sur le problème. Par exemple, Bitmap instances peuvent facilement exhaust memory, et solutions for Bitmaps ne sont pas nécessairement applicables à tout en général.
Pour obtenir plus d'informations, vous pouvez activer Global Reference Messages pour voir quand les références globales sont créées et détruites.
Par ailleurs, nous mettons constamment à jour les heuristiques GC. Mono pour Android 4.1.0 a introduit un changement dans lequel GC.Collet() est appelée automatiquement une fois que nous avons atteint un seuil gref de 80% de la valeur gref maximale pour la plate-forme (1800 grefs sur l'émulateur). Cela devrait éliminer une grande partie de la nécessité pour OnDestroy() d'appeler GC.Collect(), bien que (comme toujours) le GC peut lancer à des "moments inopportuns", de sorte qu'un GC.Collect() explicite peut être préférable de toute façon.
Pouvez-vous fournir plus d'informations sur votre recherche? –
Je peux fournir quelques liens qui im se référant au même problème – arkmetal
http://docs.xamarin.com/android/advanced_topics/garbage_collection#Helping_the_GC – arkmetal