memory - Swift UIKit 内存管理效率低下

Question

注意:如果有类似的问题，我深表歉意，但它们更具体，如“UIMapView Kit 内存泄漏问题”，我更关心并且真的想知道通用 Swift 和 ARC 以及它的内存管理问题。

我现在已经在 Xcode 中完成了几个应用程序，但它们都是在 Objective-C 中完成的。

UIKit 对象(包括 UIViews 和 UIViewControllers)的内存管理以及与此相关的任何其他对象在 Objective-C 中很容易处理，简单的意思是在学习过程中的某个时刻与它作斗争后习惯它曲线。

现在我正在与 Swift 合作，努力跟上“尖端”技术的步伐。然而，我注意到我在 Objective-C 内存管理中能够确定和控制的内容存在一个小问题。

Swift 说我们将更加专注于代码开发而不是像它的前身或即将成为前身的内存管理是多么容易。但是我还没有发现这个好处。我的新应用程序的内存管理一直很糟糕。只需创建一个带有几个 View 的简单 UIViewController 就可以堆积我不再需要的内存，一次只有几 Mb。

请记住，我一直在使用解构函数(Swift 中的 Deinit)，将 nil 分配给我不再需要使用的值，手动从 super View 中删除 subview ，认为这是问题所在，甚至使用 AutoReleasePool 代码段。

autoreleasepool{
//Code looping through Swift Native Objects that potentially might lead to leaking 
//But AutoReleasePool helps with this, supposedly.
}

现在的问题:这里的任何人都知道到底是什么问题？是我用我的代码做了一些可怕的事情吗？还是 Xcode 和快速内存管理中真的存在错误？有没有其他人遇到过这个问题，你解决了吗？

这是一个解释这种情况的链接。 Problems of ARC in Swift? ARC in Swift Apple Docs

---

更新:

你是对的，我应该发布更多关于我的情况的信息:所以就这样吧。

应用程序一启动，我的内存就从 ~5mb 开始。

一旦我开始在应用程序中导航。我注意到内存是如何开始一点一点堆积起来的。但是当我使用大约 25+ Mbs 的 UIMapView 时，最大的内存峰值开始堆积。

当我只使用一个普通的 UITableViewController 时，每次我推送(到 NavController)相同的 UITableViewController 时，它只会堆积 ~2mbs。当我选中 TableViewCell 时，它会打开另一个带有 UIMapView 的 ViewController，这是内存开始堆积的地方。

请记住，我只是在应用程序中来回导航。总共只有 4 个 UIViewControllers，包括我的菜单。

但事情是这样的......你看到的所有这些内存快照都是在我停止导航并返回主菜单后，我的导航 Controller 的 Root View Controller 。

Answer 1

Swift 使用 ARC 的方式与 ObjC 完全相同。如果您看到泄漏，您可能在某处创建了一个保留循环，并且您将以与 ObjC 中几乎完全相同的方式避免这些泄漏(使用 unowned 的附加选项，但它们与 unsafe_unretained 非常相似，所以即使这不是重大变化)。如果您熟悉 Cocoa 中的内存管理，那么您就会理解 Swift 中的内存管理。但根据您在此处提供的信息(这些信息似乎只是对 Cocoa 的评论)，我们无法提供帮助。

autoreleasepool{
//Code looping through Swift Native Objects that potentially might lead to leaking 
//But AutoReleasePool helps with this, supposedly.
}

综上所述，这条评论暗示了您的错误。自动释放池需要在您快速创建和销毁对象的内部循环中，而不是围绕它。直到池 block 结束或事件循环结束时，才会释放自动释放的对象。后者通常就足够了，但如果您要生成和释放大量对象，那么有时您必须更快地清空池。 Advanced Memory Management Programming Guide 中解释了自动释放池.也就是说，UIKit 对象通常不需要它们。

作为旁注，“Swift 中 ARC 的问题？”您提供的链接似乎不知道 cocoa 垃圾收集的历史。 Apple 在 Mac 上试用了 GC，但被 Cocoa 开发者拒绝了。 Apple 弃用了 GC，随后将其删除(当他们宣布弃用 GC 时我正在 WWDC；我们鼓掌)。对iOS就更不适用了。关于这个问题的精彩讨论在 Why mobile web apps are slow 中。 .我并不是说 GC 是一件坏事。我是说 Apple 很清楚这一点，并主动选择不合并它。他们不仅仅是错过了一个机会。

---

编辑:您更新的信息看起来像一个非常标准的保留循环。我将从 heap shot analysis 开始找出涉及的对象类型。确保你是 following the rules .然后从那里开始，主要是使用 Instruments(尤其是 Allocations 和 Leaks 工具)。一个关键是 View Controller 通常根本不应该保留其他 View Controller 。他们应该通过模型相互交谈。在 block 中使用 self 必须小心。正常的规则。它们在 ObjC 和 Swift 中是相同的。但堆射绝对是开始的地方。找出漏水的地方；然后找出原因。