通过附加行为防止内存泄漏

我在我的WPF应用程序中创建了一个"附加行为",它允许我处理Enter按键并移动到下一个控件.我将其称为EnterKeyTraversal.IsEnabled,您可以在此处查看我博客上的代码.

我现在主要担心的是我可能有内存泄漏,因为我正在处理UIElements上的PreviewKeyDown事件,并且从未明确地"取消"该事件.

什么是防止这种泄漏的最佳方法(如果有的话)？我应该保留我正在管理的元素列表,并在Application.Exit事件中取消挂起PreviewKeyDown事件吗？有没有人在自己的WPF应用程序中成功附加行为,并提出了一个优雅的内存管理解决方案？

1> Arcturus..：

---

我不同意DannySmurf

一些WPF布局对象可能会堵塞您的内存,并且当您的应用程序没有被垃圾回收时,它们会非常慢.所以我发现单词的选择是正确的,你正在泄漏内存给你不再使用的对象.您希望这些项目是垃圾收集的,但它们不是,因为某处有一个引用(在本例中是来自事件处理程序).

现在回答真实的答案:)

我建议您阅读MSDN上的这篇WPF性能文章

不删除对象上的事件处理程序可能会使对象保持活动状态

对象传递给其事件的委托实际上是对该对象的引用.因此,事件处理程序可以使对象保持比预期更长的时间.在执行已注册侦听对象事件的对象的清理时,必须在释放该对象之前删除该委托.保持不需要的对象活动会增加应用程序的内存使用量.当对象是逻辑树或可视树的根时尤其如此.

他们建议您查看弱事件模式

另一种解决方案是在完成对象后删除事件处理程序.但我知道,对于附加属性,这一点可能并不总是很清楚.

希望这可以帮助!

---

我正在投票,因为答案与实际问题无关.每个人都知道内存泄漏的坑及其原因,特别是由于你提到的事件处理程序.@Matt在这里想知道的是如何在使用内部附加行为时安全地处理事件处理程序.我很快就会回答这个问题.

2> John Fenton..：

---

除了哲学辩论之外，在查看OP的博客文章时，我在这里看不到任何泄漏：

ue.PreviewKeyDown += ue_PreviewKeyDown;

的硬引用ue_PreviewKeyDown存储在中ue.PreviewKeyDown。

ue_PreviewKeyDown是一种STATIC方法，不能GCed。

没有硬引用ue被存储，因此没有什么阻止它GCed。

那么...泄漏在哪里？

---

这是常见的误解。ue.PreviewKeyDown + = ue_PreviewKeyDown保留了对ue的强大引用，并且因为us_PreviewKeyDown是静态的，并且ue将永远不会被收集。