J'ai une application Silverlight 4 qui a une classe ViewModel qui fuit. J'ai confirmé cela en utilisant WinDbg et la commande! Gcroot sur mon type ViewModel. Je ne pouvais pas cerner le point la cause exacte de la fuite de mémoire mais tenté de le résoudre en utilisant la ligne de code suivante dans la vue correspondante lorsqu'il est fermé:Silverlight 4 fuites de mémoire
HtmlPage.Window.Navigate(new Uri(MyTopLevelUri));
Cela force l'application pour redémarrer et donc le RootVisual est réinitialisé. Maintenant, quand j'utilise WinDbg, je vois qu'il n'y a plus de références sur la classe ViewModel après la fermeture de la vue. Cependant, lorsque je surveille l'utilisation de la mémoire de l'application (à l'aide de SysInternals), elle augmente continuelle- ment. Parfois, il peut baisser légèrement, mais si je continue à ouvrir et à fermer la vue suspecte, je finis avec un ensemble de mémoire d'octets privés de plus de 1.000.000K. De plus, même si j'ajoute du code pour forcer le GC, il ne récupère jamais vraiment toute la mémoire allouée. Devrais-je m'inquiéter?
Y a-t-il des fuites de mémoire inhérentes à SL4 et aux commandes? Je n'ai pas beaucoup de foi compte tenu du correctif qui a été publié récemment pour corriger les fuites de mémoire avec DataTemplates (version 4.0.60129.0 http://timheuer.com/blog/).
Désolé que cela vous dérange. Je l'ai enlevé pour vous Jeff. –
Juste trouvé des choses vraiment intéressantes ici: http://blogs.msdn.com/b/slperf/archive/2010/08/19/analyzing-silverlight-memory-usage-part-1-obtaining-mesures.aspx –
OK l'ont cloué à une liaison spécifique. Nous utilisons un modèle DataContextProxy (comme décrit ici: http://weblogs.asp.net/dwahlin/archive/2009/08/20/creating-a-silverlight-datacontext-proxy-to-simplify-data-binding-in -nested-controls.aspx). La fuite de mémoire disparaît dès que je supprime toutes les liaisons qui utilisent la ressource statique DataContextProxy. Je ne sais pas pourquoi cela provoque une fuite de mémoire. –