低内存处理

最新推荐文章于 2021-11-22 11:04:10 发布

zrhloveswallow

最新推荐文章于 2021-11-22 11:04:10 发布

阅读量1.2k

点赞数

分类专栏： iOS 内存文章标签：内存

本文链接：https://blog.csdn.net/zrhloveswallow/article/details/21370993

版权

本文介绍了iOS系统内存警告的四个等级及其影响，强调在接收到内存警告时，尤其是level 1，应用需要释放不必要的内存。低内存处理的思路包括移除不可见view controllers和释放缓存数据。在iOS不同版本中，`applicationDidReceiveMemoryWarning`和`viewDidUnload`的处理方式有所不同，iOS 6.0后不再调用`viewDidUnload`。文中还给出了处理内存警告的实例代码，并提醒开发者注意内存回收的细节，如使用weak引用和在`didReceiveMemoryWarning`中适当地处理内存。最后，介绍了如何在模拟器中模拟低内存警告。

摘要由CSDN通过智能技术生成

1.系统有四种内存警告，定义如下：

　　　　typedef enum {

　　　　OSMemoryNotificationLevelAny = -1,

　　　　OSMemoryNotificationLevelNormal = 0,

　　　　OSMemoryNotificationLevelWarning = 1,

　　　　OSMemoryNotificationLevelUrgent = 2,

　　　　OSMemoryNotificationLevelCritical = 3

　　　　} OSMemoryNotificationLevel;

　　但是这几种警告之间是怎么变化的，到达什么阈值时会从一个level跳到另外一个level，文章中没有提及。

　　通常我们在程序中接收到最多的就是Memory warning level 1，这个时候就证明系统内存紧张了，我们的程序必须做出相应，释放不必要的内存。通常如果我们处理得当的话，内存警告就会到此停止，恢复正常状态。如果我们在接收到memory warning level 1以后坐视不理的话，系统可能还会再尝试通知几次level 1，如果还是不去处理的话，系统将会发出更高一级的内存警告 level 2，通常的结果就是我们的App被强制退出，系统收回内存。当然系统在发出level 2的警告时，也会去尝试做一些清理内存的事，例如关闭不必要的后台程序等。很显然我们不该寄希望于系统自己清理，这就好比你的胳膊被划破了，身体肯定会有自修复功能，但是如果伤口比较大的话，肯定还是需要人工处理一下的。

　　到目前位置我还没有见过level 3的警告，根据stack over flow上面讲的“当发生level 3警告时，系统内核将会接管，很有可能关掉IOS的主界面进程（SpringBorad），甚至会重启”，照这个意思来说我们程序里面接收不到，也实属正常，系统自己的东西都被干掉了，我们肯定早被kill了。

2.low-memory 处理思路：

通常一个应用程序会包含多个view controllers，当从view跳转到另一个view时，之前的view只是不可见状态，并不会立即被清理掉，而是保存在内存中，以便下一次的快速显现。但是如果应用程序接收到系统发出的low－memory warning，我们久不得不把当前不可见状态下的views清理掉，腾出更多的可使用内存：当前可见的view controller也要合理释放掉一些缓存数据，比如图片资源和一些不是正在使用的资源，以避免应用程序崩溃。

3.low-memory 处理方法：

有限的内存空间，使得iOS设备的内存常常吃紧，这时系统会向运行中的应用发出低内存警告，从而调用UIApplicationDelegate的方法：

- (void)applicationDidReceiveMemoryWarning:(UIApplication*)application

实现这个代理方法时应该通过清除能够被重新创建或加载的缓存数据或对象来释放尽量多的内存。并且要结合UIViewController的didReceiveMemoryWarning方法和UIApplicationDidReceiveMemoryWarningNotification通知来使用。强烈建议你实现这个方法。如果你的应用在低内存条件下不释放足够多的内存，系统可能会彻底终止你的应用。

所以，如何正确实现这两个方法是保证应用在低内存环境下能够继续正常使用的关键。