3
私は漏れやすいViewModelクラスを持つSilverlight 4アプリケーションを持っています。私はWinDbgと！gcrootコマンドをViewModel型で使用してこれを確認しました。私は、メモリリークの正確な原因をピンポイントすることができませんでしたが、それが閉じているときに対応するビューで、次のコード行を使用して、それを解決しようとしてきた：Silverlight 4メモリリーク
HtmlPage.Window.Navigate(new Uri(MyTopLevelUri));
これは、したがって再起動するアプリを強制し、 RootVisualが再初期化されます。今私はWinDbgを使用すると、ビューが閉じられた後、ViewModelクラスに保持されている参照がなくなることがわかります。
しかし、（SysInternalsを使用して）アプリのメモリ使用量を監視すると、継続的に増加します。ときどきそれは少し落ちるかもしれませんが、私が疑わしいViewを開いたり閉じたりし続けると、私は最終的に1,000,000Kを超えるプライベートバイトメモリセットになります。また、GCを強制するコードを追加しても、割り当てられたすべてのメモリを本当に回復することはありません。私は心配すべきですか？
SL4とコントロールに固有のメモリリークがありますか？私は最近、DataTemplates（バージョン4.0.60129.0 http://timheuer.com/blog/）でメモリリークを修正するためにリリースされたパッチを受けて、多くの信念を持っていません。
ごめんなさい。私はあなたのためにそれを削除しました。 –
ちょっと面白いものが見つかりました：http://blogs.msdn.com/b/slperf/archive/2010/08/19/analyzing-silverlight-memory-usage-part-1-obtaining-measurements.aspx –
OK特定の拘束力に縛られています。 DataContextProxyパターンを使用しています（ここで説明されているように：http://weblogs.asp.net/dwahlin/archive/2009/08/20/creating-a-silverlight-datacontext-proxy-to-simplify-data-binding-in -nested-controls.aspx）。 DataContextProxy静的リソースを使用するすべてのバインディングを削除すると、メモリリークがなくなります。なぜこれがメモリリークを引き起こしているのかわかりません。 –