何时以单点触控/mvvmcross释放对象 [英] when to release objects in mono touch / mvvmcross

问题描述

我们正在实施一个似乎存在大量内存泄漏的应用程序.例如，我们有一个带有相应视图模型的视图，该视图在mono分析器中注册了38次，但应该对其进行垃圾回收.我们有很多自定义控件等，但是应该将它们放置在哪里-从ios 6开始，不再调用viewdidunload，所以我们应该在哪里进行清理?

We are implementing an app which seems to have major memory leaks. For an example we have a view with its corrosponding viewmodel that is registered 38 times in the mono profiler but it should be garbage collected. We have a lot of custom controls etc. but where should these be disposed - as of ios 6 viewdidunload is not called anymore so where should we do our cleanup?

致谢

推荐答案

这是一个大问题……对于一般情况来说，很难轻易回答.

This is a big question... and can't easily be answered for a general case.

通常，如果您编写漂亮的简单ViewModel和漂亮的简单View，则不会出现任何内存泄漏.

In general, if you write nice simple ViewModels and nice simple Views, then you will not get any memory leaks.

但是，如果您有引用ViewModel的View，而又有以某种方式引用View的回调，那么很可能会发生内存泄漏-特别是如果您的View模型订阅了服务上的事件.

However, if you have Views referencing ViewModels, which in turn have callbacks which somehow reference the Views, then it's very possible to get memory leaks - especially if your view models subscribe to events on services.

一个特别讨厌的情况是ObjC和C#都引用了对象.在 http:中对此有一些讨论: //forums.xamarin.com/discussion/97/correct-way-pop-a-dialogviewcontroller-mine-are-staying-in-Memory ，它还引用了我们曾经在SQL位示例中遇到的问题- https://github.com/slodge/MvvmCross/issues/19

One particularly nasty situation is when ObjC and C# both have references to objects. There's some discussion of this on http://forums.xamarin.com/discussion/97/correct-way-to-pop-a-dialogviewcontroller-mine-are-staying-in-memory which also references a problem we once had in the SQL bits example - https://github.com/slodge/MvvmCross/issues/19

您当前的泄漏可能不是这种情况，但是值得阅读Rolf的答案- http://forums.xamarin.com/discussion/comment/535/#Comment_535 -几次-这不是入门级的解释，但最终还是有道理的！

This may not be the case for your current leak, but it's worth reading Rolf's answer - http://forums.xamarin.com/discussion/comment/535/#Comment_535 - a few times - it's not an entry level explanation, but it makes sense eventually!

所以，为了解决您当前的问题...

So, in order to tackle your current problem...

1. 找出泄漏的内容

1. work out what is leaking

找出原因-保留引用的原因是什么.

work out why - what is it that is holding on to the references.

修复它.

关键是要投入大量的精力进行1和2的学习，然后再研究错误的3.是.

The key is to invest a decent amount of effort in doing the studying of 1 and 2, before diving in to the wrong fix for 3. There is no point in trying to 'fix it' without really knowing what 'it' is.

好消息是，Mono探查器(具有内置工具可以识别对哪些内容的引用)确实有助于完成这项工作.

The good news is that the Mono profiler - with its built-in tooling to identify what has references to what - is really good for helping with this job.

从您的描述中，我知道您已经找到了此工具-但对于其他任何人，请参阅-http://docs.xamarin.com/ios/Guides/Deployment%252c_Testing%252c_and_Metrics/Monotouch_Profiler

From your description, I know you've already found this tool - but for anyone else reading, please see - http://docs.xamarin.com/ios/Guides/Deployment%252c_Testing%252c_and_Metrics/Monotouch_Profiler

一旦您确定了泄漏的原因以及原因，那么第3步将需要一些思考，但希望会很容易回答.

Once, you've identified what is leaking and why, then step 3 will require some thinking, but will hopefully be easy to answer.

有时解决方案是:

• 只修复一行错误的代码...哪一行是硬代码.
• 使用后退"检测，确定何时断开绑定或事件.
• 使用'willappear'，'willdisappear'添加生命周期事件，以更改您订阅/取消订阅事件的方式
• 使用C#事件以外的替代方法-例如使用TinyMessenger之类的Messenger(或MvvmCross插件Messenger)-这些优点是它们通常使用WeakReference类来避免泄漏.
• 在适当的时间"处处置某物"-再次制定某物"和适当的时间"是这方面的困难部分

• Just fix one bad line of code... which line is the hard bit.
• Use 'back' detection, to work out when to disconnect bindings or events.
• Use 'willappear', 'willdisappear' to add lifecycle events to change the way you subscribe/unsubscribe from events
• Use an alternate method than C# events - e.g. use a Messenger such as TinyMessenger (or the MvvmCross plugin messenger) - these have the advantages that they typically use the WeakReference class to avoid leaks.
• Dispose 'something' at 'an appropriate time' - again working out the 'something' and the 'appropriate time' are the hard parts in this

无论发生什么，请不要惊慌，并从工程角度解决此问题.这些泄漏也会发生在非MvvmCross和非MonoTouch代码中-并且将MvvmCross与良好的干净IoC架构一起使用应该使它们更易于查找和删除.

Whatever happens, don't panic and do tackle this from an engineering perspective. These leaks happen in non-MvvmCross and non-MonoTouch code too - and using MvvmCross with a nice clean IoC architecture should make them easier to find and remove.

如果问题确实出在某个地方的MvvmCross绑定中，那么请务必将其记录为错误-我非常认真地对待这些问题！

If the problem does turn out to be in an MvvmCross binding somewhere, then please do log it as a bug - I take these issues very seriously!

关于MvvmCross回购的漫长讨论中仍然存在一个开放的错误，即我们是否不应该对所有绑定代码使用WeakReferences-请参见https://github.com/slodge/MvvmCross/issues/17 -我已经考虑过这样做-它可以帮助人们避免某些错误，但不是全部.这个问题仍然悬而未决.

There is still an open bug in a long discussion on the MvvmCross repo about whether we shouldn't use WeakReferences for all our binding code - see https://github.com/slodge/MvvmCross/issues/17 - I've considered doing this - it would help people avoid some bugs... but not all. That issue is still open.

更新:我没有回答

我们有很多自定义控件等，但是这些应该放在哪里

We have a lot of custom controls etc. but where should these be disposed

框架应为您处理这些问题.

The framework should dispose these for you.

如果不是，那可能是因为其他内容正在泄漏并保留在您的View上，然后再保留在您的Controls上.您需要解决该潜在问题，而不是过早在Controls上调用Dispose().内存泄漏调试并非易事，但有时很有趣

If it doesn't then that's probably because something else is leaking and holding on to your View which is then holding on to your Controls. You need to fix that underlying problem, rather than prematurely calling Dispose() on the Controls. Memory leak debugging isn't easy, but is kind of fun (sometimes)

这篇关于何时以单点触控/mvvmcross释放对象的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！