c# - Xamarin iOS 内存到处泄漏

Question

在过去的 8 个月里，我们一直在使用 Xamarin iOS，并开发了一个具有许多屏幕、功能和嵌套控件的重要企业应用程序。我们已经按照“推荐”完成了自己的 MVVM 架构、跨平台 BLL 和 DAL。我们在 Android 之间共享代码，甚至我们的 BLL/DAL 也用于我们的网络产品。

一切都很好，除了现在在项目的发布阶段，我们发现基于 Xamarin iOS 的应用程序中到处都是无法修复的内存泄漏。我们已遵循所有“指南”来解决此问题，但现实是 C# GC 和 Obj-C ARC 似乎是不兼容的垃圾收集机制，目前它们在 monotouch 平台上相互重叠。

我们发现的现实是，对于任何重要的应用程序， native 对象和托管对象之间的硬循环将发生并且频繁。例如，在您使用 lambda 或手势识别器的任何地方，这种情况都非常容易发生。加上 MVVM 的复杂性，这几乎是一个保证。只要错过其中一种情况，就永远不会收集到完整的对象图。这些图表会引诱其他对象进入并像癌症一样生长，最终导致 iOS 迅速无情地消灭它。

Xamarin 的回答是对该问题的不感兴趣的推迟以及“开发人员应避免这些情况”的不切实际的期望。仔细考虑这一点表明，这是承认 垃圾收集在 Xamarin 中基本上被破坏了。

我现在的认识是，在 Xamarin iOS 中，您并没有真正获得传统 c# .NET 意义上的“垃圾收集”。您需要采用“垃圾维护”模式来实际让 GC 运行并完成其工作，即使那样它也永远不会完美 - 非确定性。

我的公司投入了大量资金试图阻止我们的应用程序崩溃和/或内存不足。我们基本上不得不明确地递归地处理所有可见的东西，并在应用程序中实现垃圾维护模式，只是为了阻止崩溃并拥有一个我们可以销售的可行产品。我们的客户是支持和宽容的，但我们知道这不可能永远持续下去。我们希望 Xamarin 有一个专门的团队来解决这个问题，并一劳永逸地解决这个问题。不幸的是，看起来不像。

问题是，对于用 Xamarin 编写的重要企业级应用，我们的体验是异常(exception)还是规则？

更新

查看 DisposeEx 方法和解决方案的答案。

Answer 1

我发布了一个用 Xamarin 编写的重要应用程序。许多其他人也有。

“垃圾回收”并不神奇。如果您创建一个附加到对象图根的引用并且从不分离它，则不会收集它。不仅 Xamarin 如此，.NET、Java 等上的 C# 也是如此。

button.Click += (sender, e) => { ... } 是一种反模式，因为您没有对 lambda 的引用并且您永远无法删除Click 事件的事件处理程序。同样，在托管和非托管对象之间创建引用时，您必须小心理解自己在做什么。

至于“我们已经完成了我们自己的 MVVM 架构”，有一些知名度很高的 MVVM 库(MvvmCross、ReactiveUI 和 MVVM Light Toolkit)，所有这些库都非常重视引用/泄漏问题。