在 Apple documentation ，它说:
The AppKit and UIKit frameworks process each event-loop iteration (such as a mouse down event or a tap) within an autorelease pool block. Therefore you typically do not have to create an autorelease pool block yourself, or even see the code that is used to create one.
现在，这应该是显而易见的，但无论如何我都会要求确认。
如果我正在开发最终的后台进程(通过 Grand Central Dispatch)，但为了简单起见，我首先将其放在第一个加载 View 的 viewDidLoad 中，这样我的 View 实际上不会显示在直到所有(比如说)2 分钟的处理完成，然后在这两分钟内所有默认自动释放池永远不会被释放，因为它还没有经历事件循环迭代，对吧？听到“不”简直是疯了，但我陷入了这个日益严重的内存问题，所以我要请求确认并希望得到一个好消息。
如果是这样，我应该放置我自己的自动释放 block 。如果处理是通过 GCD 在后台进程中完成的，我仍然需要自动释放 block ，对吧？
最佳答案
我会尽力为您提供两个问题的完整答案。
第一部分。首先注意主线程中长时间运行的操作。例如，如果您的操作需要两分钟，则主线程将被阻塞，直到它完成。从用户的角度来看，应用程序将在两分钟内没有响应。 无论如何，是的，在应用程序委托(delegate)中有一个插入自动释放对象的池。当循环结束时，池内的对象将被释放，因为池会自动耗尽。 如果你有内存问题，你可以看看Use Local Autorelease Pool Blocks to Reduce Peak Memory Footprint 。正如文档中所写，您应该将操作包装在自动释放 block 中。在 block 的末尾，临时对象被释放，这通常会导致它们的释放，从而减少程序的内存占用。
关于 GCD 问题我会说不。在处理 GCD 时，您不必创建自动释放池。通常，也如 Do you need to create an NSAutoreleasePool within a block in GCD? 中所写。 ，GCD 自动管理每个队列的自动释放池。因此，如果您的对象很少，则不必担心，但如果您创建了很多对象，是的，请创建一个自动释放池。后者还允许您减少内存占用。
So for this entire two minutes where the app will not be responsive, it is when the loop has not ended, and the pool is not drained during these two minutes, right?
应用程序没有响应，因为主线程(通过运行循环)按顺序执行任务。如果您阻止运行循环，应用程序将卡住，直到长时间运行的操作完成(我认为如果超过特定时间段，应用程序将被 iOS 杀死)。为了避免这种情况，您可以在不同的线程中执行(如您所写)长时间运行的操作。
使用线程的目标是使应用程序具有高度响应能力，但它可能会导致各种问题，例如数据不一致(竞争条件)或死锁。
有关更多信息，我强烈建议阅读 The pogo stick of NSRunLoop , Understanding NSRunLoop和 NSDefaultRunLoopMode vs NSRunLoopCommonModes .
关于objective-c - iOS编程自动释放池，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12218949/