何时在单声道触摸/mvvmcross 中释放对象 [英] when to release objects in mono touch / mvvmcross
问题描述
我们正在实施一个似乎存在严重内存泄漏的应用.例如，我们有一个视图及其对应的视图模型，该视图在单声道分析器中注册了 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 和漂亮的简单视图，那么你就不会出现任何内存泄漏.
In general, if you write nice simple ViewModels and nice simple Views, then you will not get any memory leaks.
但是，如果您有引用 ViewModel 的视图，而这些视图又具有以某种方式引用视图的回调，那么很可能会出现内存泄漏 - 特别是如果您的视图模型订阅了服务上的事件.
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-to-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...
找出泄漏的东西
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(或 MvvmCross 插件信使)之类的 Messenger - 它们的优点是它们通常使用
WeakReference类来避免泄漏. - 在适当的时间"处理某事" - 再次解决某事"和适当的时间"是其中的难点
无论发生什么，都不要惊慌，并从工程角度解决这个问题.这些泄漏也发生在非 MvvmCross 和非 MonoTouch 代码中 - 使用带有漂亮干净的 IoC 架构的 MvvmCross 应该会使它们更容易找到和删除.
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.
如果没有，那可能是因为其他东西正在泄漏并保留在您的视图上，然后在您的控件上.您需要解决该潜在问题，而不是过早地在控件上调用 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屋！
