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.Behavior 来自 System.Windows.Interactivity.dll：行为可能不会在您期望的情况下分离，反之亦然，从而在控件上添加事件处理程序以在 gc 中继续存在
• 仅根据您的描述，我很确定您将来会使用第三方组件，我们发现这是一流的泄漏候选对象

您在开始之前考虑这一点是一个优势，投资一个好的 MemoryProfiler 并定期从一开始就对您的应用进行分析，您会没事的。

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

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

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