iOS: didReceiveMemoryWarning的帮助：

Question

在我的开发过程中，我正在跟踪崩溃和内存泄漏。作为一种策略，您会在didReceiveMemoryWarning:中添加任何NSLog消息或通知吗？此方法的文档相当稀疏。在崩溃发生之前，UIViewController会触发该方法，这样说准确吗？在开始使用Instruments之前，这是一个起点吗？

Answer 1

好的，有几件事需要注意：

将在内存不足崩溃之前调用

• didReceiveMemoryWarning。而不是其他的崩溃。如果正确处理警告并释放内存，则可以避免出现内存不足的情况，并且不会崩溃。
• 您可以在模拟器的硬件菜单下手动触发内存警告。强烈建议这样做，以测试您对didReceiveMemoryWarning.
• Instruments的处理可以帮助您调试泄漏(尽管不是所有泄漏)-它对于崩溃并不是那么有用。
• 不，我个人并不使用NSLog -我只是在调试时断点内存警告。

Answer 2

更新从iOS 6开始，不再卸载UIViewController视图以响应内存警告。相反，只要尽最大努力在调用didReceiveMemoryWarning时释放您可以合理重新创建的任何资源(例如缓存数据)即可。

更新

当我还是一个愤怒的年轻人时，我写下了我最初的答案；时代已经变了，基本上，这是错误的。

如果你有一个只有一个视图控制器的应用程序，并且你收到了一个内存警告，那么你能做的就不多了。但是，如果您有多个视图控制器，情况就会发生巨大变化，因为您可以卸载所有与非最前端控制器关联的状态()。事实上，[UIViewController didReceiveMemoryWarning]会通过为你卸载不可见的视图来推动你朝着正确的方向前进(令人惊讶！)当最前面的视图控制器被关闭时，底层视图被重新加载，最多用户应该只知道延迟，即使在内部您的应用程序可能已经完成了完全重启。

这不是你可以轻松修改的细节，你需要从一开始就牢记内存使用情况，并将你的多视图应用程序设计成完全可卸载的UIViewController组件。事实上，仅仅为了使用模拟器的内存警告特性，保持代码与模拟器的兼容性是值得的。

当内存充足时，不会卸载任何东西，一切都很顺利，而当内存较低时，事情会继续工作，尽管速度会更慢。现在我要说的是，这个解决有限记忆问题的方案是理想的。

为了利用这个内存室技巧，重载UIViewController方法viewDidLoad，viewDidUnload和viewWillUnload (iOS5，如果卸载状态需要你的视图仍然存在，例如，如果你不想泄漏你的OpenGL纹理和渲染缓冲区，在iOS4上，你可以通过重载didReceiveMemoryWarning和跟踪视图的可见性来模拟)。

原创，更有胆量的答案

didReceiveMemoryWarning是完全没用的。

不能保证如果你释放内存(甚至所有内存)，你就不会被杀死。

在我的痛苦经历中，它在2.x/3.0上通常是这样工作的：

1. mediaserverd泄漏了一堆内存
2. 我的应用被杀死了

不幸的是，收割者从来没有想过要杀死梅迪亚斯维德。

因此，如果内存使用不是您的错，那么您实际上只有两个选择：

1. 要求用户重新启动(用户假设这是您的错误，写了一篇严厉的评论)
2. 希望罪魁祸首崩溃(mediaserverd经常要求！)

Answer 3

如果用户打开了一些应用程序，那么您可以使用的内存将非常少。所以有时didReceiveMemoryWarning只能在1MB使用后才能被系统调用。

系统在所有视图控制器上调用此方法，如果您在每个视图控制器中放置一个NSLog，您将注意到。

然后，系统将在所有视图控制器(而不是dealloc)上自动调用viewDidUnload方法。所以你必须把你所有的释放指令都放进去。

你必须做很多实验，因为如果你的应用程序很复杂，在管理好它之前，你会面临很多崩溃。