我花了将近一整天的时间试图找出 Android 内存泄漏的原因。有一个活动我打开/关闭很多次（使用计时器）。过了一会儿，我收到了 OutOfMemory 错误：
每次活动打开时，我都看到 Xamarin Profiler 中的内存不断增加：
我确保没有可能卡在该活动中的属性或事件处理程序。我什至删除了每个图像、按钮等，试图检测导致内存泄漏的原因。还是一样……
然后我在主要活动的OnResume方法中做了GC.Collect()（打开有问题的活动的那个）。现在我可以看到内存按照它应该的方式上下波动。您可以在屏幕截图中看到结果：
根据Xamarin docs：
当次要堆内存不足时，GC 将运行以进行新分配
但这实际上并没有发生
【问题讨论】：
标签： android memory-leaks xamarin garbage-collection xamarin.android
您可能希望在帮助 GC 下的链接中进一步阅读：
The GC has an incomplete view of the process and may not run when memory is low because the GC doesn't know that memory is low. 和
Managed Callable Wrappers do not add additional instance members
基本上，看起来 BaseActivity 是一个 Android Callable Wrapper (ACW)，而 Mono GC 不知道它有多大，因此它不知道调用垃圾收集器。据我所知，ACW 是一种实现 Android 接口的方式。
正如您所发现的，解决方案是在使用 ACW 时手动调用 Xamarin 文档中推荐的垃圾收集器。
http://developer.xamarin.com/guides/android/advanced_topics/garbage_collection/
----
自从最初发布此答案以来，Xamarin 文档对这种情况的解释有所改进：
Java.Lang.Object 类型或派生类型的实例是 至少 20 字节大小。托管的可调用包装器不添加额外的实例 成员，所以当你有一个 Android.Graphics.Bitmap 实例时 指的是 10MB 的内存，Xamarin.Android 的 GC 不会知道 – GC 将看到一个 20 字节的对象并且无法确定 它与保持的 Android 运行时分配的对象相关联 10MB 内存。
这表明，无论对象是否设置为 null，如果您正在分配/释放 Callable Wrapper，您应该仍然手动调用 Xamarin GC可能会消耗大量内存。
在假设 Java Object 为 20 字节的情况下运行，如果要分配和空 100 个对象，每个对象消耗 10MB，Xamarin GC 认为 4000 字节的内存正在使用中。实际上，大约 1GB 正在使用中，可能会或可能不会调用 GC。
【讨论】：
调用垃圾回收并不能确保垃圾回收会运行或所有内存分配都会发生。很多时候它是关于删除对对象的引用。如果一个对象有对它的引用，它就不会被垃圾回收。我不得不以艰难的方式学习这一点。基本上要在任何时候解决这个问题，您可以随时清空一个对象，并在需要时设置它。示例：
CustomObject cusObj = null;
if (cusObj == null)
{
cusObj = new CustomObject();
}
只需确保将对象清空即可删除引用。但如上面的答案所述，您也可以收集垃圾。请记住，GC 不会垃圾收集带有引用的项目。 看看：
【讨论】：