.net - 如果垃圾收集器在 Monotouch 4 中为 "more aggressive"，这意味着什么？

Question

我偶然发现了这个问题:Button in ContentView causes crash in MonoTouch runtime. Bug in Monotouch 4.0?并且询问者对 Monotouch 的“更积极的”垃圾收集器有问题。

• 有人可以解释为什么在查询者的情况下会发出错误(收集了什么以及为什么？)？
• “更具侵略性”是什么意思？我可能掉入哪些陷阱？我应该避免什么？
• 关于 iOS5:Apple 声称在 iOS5 中，该应用程序将收到一个内存警告，然后将被终止。与之前的任何其他版本不同，应用程序会收到三个警告。这对 Monotouch 意味着什么？它将如何处理这种行为？

也许 Xamarin 团队中的一员可以总结一些注意事项并给出一个很好的解释？

我目前正在从 MT 3.2.6 升级到 MT 4.1，想检查我的代码并检查必须更改的内容。

Answer 1

我们发现开发者有时会遇到一些奇怪的问题，比如对话框有时会停留在屏幕上，有时会消失得无影无踪，也没有解释为什么会这样。

这通常发生在您创建了一个 UIAlertView 并且没有保留对它的引用时，因此就 MonoTouch 而言，该对象是垃圾(您没有从您的代码中引用它，所以您没有使用它) .

但是对话框是立即还是稍后从您的屏幕上消失取决于垃圾收集器的试探法是否确定是时候运行收集了。如果您在集合之后创建了一个对话框，您的对话框很可能会保留在屏幕上。但是如果你非常接近一个集合，或者如果你有一个后台进程消耗内存，那么 GC 就会被触发。

这通常会让用户感到困惑，“为什么东西会随机消失”。答案是:如果您没有保留对它的引用，则 GC 会假定您不在乎。

为了让我们的用户更清楚这一点，当在模拟器上以 Debug模式运行 MonoTouch 时(并且有一个命令行选项可以控制任何构建)，我们在模拟器上添加了一个连续调用 GC.Collect 的线程() 每隔几秒。这使得您可能没有保留对您的对话的引用变得更加明显。

后来，我们发现一个非常有用和常见的模式是保留两种除了副作用之外没有任何用处的对话框:UIAlertView 和 UIActionSheet。我们更改了 MonoTouch，以便它在内部保留对这两者的引用，直到被取消为止。

因此，我们最终实现了两全其美:在开发周期中，您可以更早发现对所需对象的缺失引用，并且我们处理了两种最常见的情况，这两种情况仅对它们的副作用有用。