c# - WPF 4 中仍然存在的内存泄漏

Question

我正计划构建一个 WPF MVVM 业务应用程序框架，并且在进行有关 WPF 平台内存泄漏的研究时，我遇到了很多文章。

A memory leak may occur when you use data binding in Windows Presentation Foundation
Avoiding a WPF memory leak with DataBinding (Black Magic)
Serious Memory Leaks Plague WPF
Top 5 Memory leaks in WPF and Silverlight
WPF Binding Bug leads to possible Memory Issues

但其中大部分可以追溯到 2007 年和 2008 年，所以我想知道其中哪些已经解决，哪些还没有。

换句话说，在构建我的框架或一般情况下(WPF 4.0、.NET 4.0)要注意的内存泄漏(可能发生)的可能来源是什么？

编辑:我会尝试更具体一些。我可以利用 WeakEventManager 吗？及其子类无需开发我自己的解决方案即可监听事件？

编辑 2:更具体。我可以使用 WeakEventManager 来解决由 .NET 中的事件引起的内存泄漏问题，而不仅仅是 WPF 吗？如果是这样，为什么它是 WPF 命名空间的一部分而不是一般的 .NET 命名空间？

Answer 1

首先想到的是:

• 来自 System.Windows.Interactivity.dll 的 System.Windows.Interactivity.Behavior:行为可能不会在您期望的时候分离，反之亦然，将添加的事件处理程序留在控件上以在 gc 中存活
• 根据您的描述，我很确定您将来会使用第三方组件，我们发现这是泄漏的一流候选对象

事实上，您在开始之前就考虑到了这一点，这是一个优势，投资于一个好的 MemoryProfiler 并定期从一开始就分析您的应用程序，您会没事的。

编辑:评论您的编辑:检查您的链接我认为您可以分离出三个主要主题:

• 实现 INotifyPropertyChanged 是必须的。你的第一个开发人员告诉你“这只是一个静态 View ，我的模型上的数据不会改变，我只是跳过了 INPC”，必须在公共(public)场合绘制和驻扎。更好的是，您的框架应该强制实现此接口(interface)，或者至少让开发人员尽可能轻松地使用它。
• 不要绑定(bind)到 PropertyDescriptors，这在一开始可能并不明显，但您的框架可能再次为开发人员设置了一条路径，仅使用它来绑定(bind)到自定义 View 模型属性。
• 始终注销您的事件处理程序，我认为这更多是代码卫生问题

至于您对弱事件的编辑，是的，这可能有效。就我个人而言，我不会考虑这种良好做法，因为它可能会导致您的模型公开您正在注册的事件比您预期的更早被清理。我建议多走一英里并有意识地注销您的处理程序。