silverlight prism/unity 中的内存泄漏
我们正在使用 SL4、PRISM 和 MVVM 构建 LOB 应用程序。我最近注意到我的应用程序没有释放任何内存。如果我切换黑白页面，它开始时约为 150MB，并且会很快增长到 1 GB 以上。我们的设计涉及 3 个模块，每个模块都有一个 Controller 类（Unity 单例），用于侦听事件并将视图注入适当的区域。这就是当触发事件以注入视图时这些控制器中发生的情况。
var v = Container.resolve<view>()
var vm = Container.resolve<viewmodel>()
v.datacontext = vm;
myregion.addtoregion(v);
因此对该视图的 100 次调用将执行 100 次。在 addviewregion 方法中，我将在添加新视图之前删除所有现有视图。看到内存问题后，我将 view 和 view 都设置为对于需要删除的所有视图，在 addviewtoregion 方法中将 viewmodel 设置为 null。内存消耗仍然相同。 Unity ContainerControllled...对象（我的控制器）是否持有对这些对象的引用？
We are building a LOB application using SL4, PRISM and MVVM. I noticed very lately that my App is not releasing any memory. It starts around 150MB and grows to 1 GB+ very fast if I switch b/w pages. Our design involves 3 modules each having a Controller class (Unity singleton) which listens for events and injects views into the appropriate region. So this is whats happening in those controllers when an event is fired to inject a view.
var v = Container.resolve<view>()
var vm = Container.resolve<viewmodel>()
v.datacontext = vm;
myregion.addtoregion(v);
so 100 calls for this view will exceute this 100 times. And in addviewregion method, I'm removing all existing views before adding the new one. And after seeing the memory problem, I set both view & viewmodel to null in addviewtoregion method for all the views needed to be removed. Still memory consumption is same.
Is Unity ContainerControllled... objects (my controllers) holding references to these objects?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您是否注册以处理这些动态视图上的事件，但在删除视图之前忘记取消注册它们？处理事件会创建对对象的隐式引用，这通常是托管内存泄漏的来源。
您应该查看 本指南使用 WinDbg 检查堆和 GC 根。
Are you registering to handle events on these dynamic views and forgetting to unregister them before you remove the view? Handling an event creates an implicit reference to the object, and that is typically where managed memory leaks come from.
You should check out this guide to tracking down leaky Silverlight controls using WinDbg to examine the heap and GC roots.