ios 处理内存警告
iPhone下每个app可用的内存是被限制的,如果一个app使用的内存超过20M,则系统会向该app发送Memory Warning消息。收到此消息后,app必须正确处理,否则可能出错或者出现内存泄露。
app收到Memory Warning后会调用:UIApplication::didReceiveMemoryWarning -> UIApplicationDelegate::applicationDidReceiveMemoryWarning,然后调用当前所有的viewController进行处理。因此处理的主要工作是在viewController。
当我们的程序在第一次收到内存不足警告时,应该释放一些不用的资源,以节省部分内存。否则,当内存不足情形依然存在,iOS再次向我们程序发出内存不足的警告时,我们的程序将会被iOS kill掉。
iOS的UIViewController 类给我们提供了处理内存不足的接口。在iOS 3.0 之前,当系统的内存不足时,UIViewController的didReceiveMemoryWarining 方法会被调用,我们可以在didReceiveMemoryWarining 方法里释放掉部分暂时不用的资源。
从iOS3.0 开始,UIViewController增加了viewDidUnload方法。该方法和viewDIdLoad相配对。当系统内存不足时,首先UIViewController的didReceiveMemoryWarining 方法会被调用,而didReceiveMemoryWarining 会判断当前ViewController的view是否显示在window上,如果没有显示在window上,则didReceiveMemoryWarining 会自动将viewcontroller 的view以及其所有子view全部销毁,然后调用viewcontroller的viewdidunload方法。如果当前UIViewController的view显示在window上,则不销毁该viewcontroller的view,当然,viewDidunload也不会被调用了。但是到了ios6.0之后,这里又有所变化,ios6.0内存警告的viewDidUnload 被屏蔽,即又回到了ios3.0的时期的内存管理方式。
iOS3-iOS5.0以前版本收到内存警告:
调用didReceiveMemoryWarning内调用super的didReceiveMemoryWarning会将controller的view进行释放。所以我们不能将controller的view再次释放。
处理方法:
-(void)didReceiveMemoryWarning
{
[super didReceiveMemoryWarning];//如没有显示在window上,会自动将self.view释放。
// ios6.0以前,不用在此做处理,self.view释放之后,会调用下面的viewDidUnload函数,在viewDidUnload函数中做处理就可以了。
}
-(void)viewDidUnload
{
// Release any retained subviews of the main view.不包含self.view
//处理一些内存和资源问题。
[super viewDidUnload]; }
iOS6.0及以上版本的内存警告:
调用didReceiveMemoryWarning内调用super的didReceiveMemoryWarning调只是释放controller的resouse,不会释放view
处理方法:
-(void)didReceiveMemoryWarning
{
[super didReceiveMemoryWarning];//即使没有显示在window上,也不会自动的将self.view释放。
// Add code to clean up any of your own resources that are no longer necessary. // 此处做兼容处理需要加上ios6.0的宏开关,保证是在6.0下使用的,6.0以前屏蔽以下代码,否则会在下面使用self.view时自动加载viewDidUnLoad if ([[UIDevice currentDevice].systemVersion floatValue] >= 6.0) { //需要注意的是self.isViewLoaded是必不可少的,其他方式访问视图会导致它加载 ,在WWDC视频也忽视这一点。 if (self.isViewLoaded && !self.view.window)// 是否是正在使用的视图
{
// Add code to preserve data stored in the views that might be
// needed later. // Add code to clean up other strong references to the view in
// the view hierarchy.
self.view = nil;// 目的是再次进入时能够重新加载调用viewDidLoad函数。
} }
}
但是似乎这么写相对于以前并不省事。最终我们找到一篇文章,文章中说其实并不值得回收这部分的内存,原因如下:
1. UIView是UIResponder的子类,而UIResponder有一个CALayer的成员变量,CALayer是具体用于将自己画到屏幕上的。
2. CALayer是一个bitmap图象的包装类,当UIView调用自身的drawRect时,CALayer才会创建这个bitmap图象类。
3. 具体占内存的其实是一个bitmap图象类,CALayer只占48bytes, UIView只占96bytes。而一个iPad的全屏UIView的bitmap类会占到12M的大小!
4.在iOS6时,当系统发出MemoryWarning时,系统会自动回收bitmap类。但是不回收UIView和CALayer类。这样即回收了大部分内存,又能在需要bitmap类时,根据CALayer类重建。
所以,iOS6这么做的意思是:我们根本没有必要为了几十byte而费力回收内存。
PS:
1、关于这个的官方文档:https://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/ViewLoadingandUnloading/ViewLoadingandUnloading.html
2、zon2012貌似都没有ios6的这个兼容(其实view是没问题的,关键是资源)
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
移动设备终端的内存极为有限,应用程序必须做好low-memory处理工作,才能避免程序因内存使用过大而崩溃。
low-memory 处理思路
通常一个应用程序会包含多个view controllers,当从view跳转到另一个view时,之前的view只是不可见状态,并不会立即被清理掉,而是保存在内存中,以便下一次的快速显现。但是如果应用程序接收到系统发出的low-memory warning,我们就不得不把当前不可见状态下的views清理掉,腾出更多的可使用内存;当前可见的view controller也要合理释放掉一些缓存数据,图片资源和一些不是正在使用的资源,以避免应用程序崩溃。
思路是这样,具体的实施根据系统版本不同而略有差异,本文将详细说明一下iOS 5与iOS 6的low-memory处理。
iOS 5 的处理
在iOS 6 之前,如果应用程序接收到了low-memory警告,当前不可见的view controllers会接收到viewDidUnload消息(也可以理解为自动调用viewDidUnload方法),所以我们需要在 viewDidUnload 方法中释放掉所有 outlets ,以及可再次创建的资源。当前可见的view controller 通过didReceiveMemoryWarning 合理释放资源,具体见代码注释。
举一个简单的例子,有这样一个view controller:
@interface MyViewController : UIViewController {
NSArray *dataArray;
}
@property (nonatomic, strong) IBOutlet UITableView *tableView;
@end
对应的处理则为:
#pragma mark -
#pragma mark Memory management - (void)didReceiveMemoryWarning {
// Releases the view if it doesn't have a superview.
[super didReceiveMemoryWarning]; // Relinquish ownership any cached data, images, etc that aren't in use.
} - (void)viewDidUnload {
// Relinquish ownership of anything that can be recreated in viewDidLoad or on demand.
// For example: self.myOutlet = nil;
self.tableView = nil;
dataArray = nil; [super viewDidUnload];
}
iOS 6 的处理
iOS 6 废弃了viewDidUnload方法,这就意味着一切需要我们自己在didReceiveMemoryWarning中操作。
具体应该怎么做呢?
1.将 outlets 置为 weak
当view dealloc时,没有人握着任何一个指向subviews的强引用,那么subviews实例变量将会自动置空。
@property (nonatomic, weak) IBOutlet UITableView *tableView;
2.在didReceiveMemoryWarning中将缓存数据置空
#pragma mark -
#pragma mark Memory management - (void)didReceiveMemoryWarning
{
[super didReceiveMemoryWarning];
// Dispose of any resources that can be recreated.
dataArray = nil;
}
不要忘记一点,每当tableview reload 的时候,需要判断一下 dataArray ,若为空则重新创建。
兼容iOS 5 与 iOS 6
好吧,重点来了,倘若希望程序兼容iOS 5 与 iOS 6怎么办呢? 这里有一个小技巧,我们需要对didReceiveMemoryWarning 做一些手脚:
#pragma mark -
#pragma mark Memory management - (void)didReceiveMemoryWarning
{
[super didReceiveMemoryWarning]; if ([self isViewLoaded] && self.view.window == nil) {
self.view = nil;
} dataArray = nil;
}
判断一下view是否是window的一部分,如果不是,那么可以放心的将self.view 置为空,以换取更多可用内存。
这样会是什么现象呢?假如,从view controller A 跳转到 view controller B ,然后模拟low-memory警告,此时,view controller A 将会执行self.view = nil ; 当我们从 B 退回 A 时, A 会重新调用一次 viewDidLoad ,此时数据全部重新创建,简单兼容无压力~~
Note:
如果你好奇Apple为什么废弃viewDidUnload,可以看看Apple 的解释:
Apple deprecated viewDidUnload for a good reason. The memory savings from setting a few outlets to nil just weren’t worth it and added a lot of complexity for little benefit. For iOS 6+ apps, you can simply forget about view unloading and only implement didReceiveMemoryWarning if the view controller can let go of cached data that you can recreate on demand later.
ios 处理内存警告的更多相关文章
- iOS基础 - 内存分析
一.内存的重要性 程序是否可用的最根本的制约因素. 十分影响用户体验. 程序的crash有很多情况都是内存的原因. 二.iOS平台内存警告机制 iOS系统不支持虚拟内存,一旦出现内存不足的情况,iOS ...
- ios系统 处理内存警告
iPhone下每个app可用的内存是被限制的,如果一个app使用的内存超过20M,则系统会向该app发送Memory Warning消息.收到此消息后,app必须正确处理,否则可能出错或者出现内存泄露 ...
- UIViewController的生命周期及iOS程序执行顺序 和ios6 处理内存警告
当一个视图控制器被创建,并在屏幕上显示的时候. 代码的执行顺序1. alloc 创建对象,分配空间2.init (initWithN ...
- iOS开发那些事-响应内存警告
好的应用应该在系统内存警告情况下释放一些可以重新创建的资源.在iOS中我们可以在应用程序委托对象.视图控制器以及其它类中获得系统内存警告消息. 1.应用程序委托对象 在应用程序委托对象中接收内存警告消 ...
- IOS内存警告处理
IPhone下每个app可用的内存是被限制的,如果一个app使用的内存超过20M,则系统会向该app发送Memory Warning消息.收到此消息后,app必须正确处理,否则可能出错或者出现内存泄露 ...
- 解读AppIcon图标设置置信息和App内存警告临界值
前面有同学问到了iOS内存警告临界值和工程项目里AppIcon的一些配置信息,相信对刚入行的同学来说,可能都会碰到类似的问题,记录一下供后来者查询. 1.先简单说下AppIcon的图标的配置信息 1) ...
- IOS应用内存释放机制
这是由iOS系统管理决定的,但APP退出在后台后,只有10秒的持续运行时间,然后暂停.但该APP还在内存中,当出现内存警告,也就是别的APP要运行,而此时内存又不足的情况下,系统会回收停在后台APP所 ...
- iOS ARC内存管理
iOS的内存管理机制,只要是iOS开发者,不管多长的时间经验,都能说出来一点,但是要深入的理解.还是不简单的.随着ARC(自动管理内存)的流行.iOS开发者告别了手动管理内存的复杂工作.但是自动管理内 ...
- [转]ios平台内存常见问题
本文转自CocoaChina,说的满详细的: 链接地址:http://www.cocoachina.com/bbs/read.php?tid=94017&keyword=%C4%DA%B4%E ...
随机推荐
- CS193p Lecture 9 - Animation, Autolayout
Animation(动画) Demo Dropit续 Autolayout(自动布局) 三种添加自动布局的方法: 使用蓝色辅助虚线,右键选择建议约束(Reset to Suggested Constr ...
- js函数式编程(三)-compose和pointFree
compose即函数嵌套组合 组合compose在第一篇已经初见端倪,可以感受一下.compose函数的实现用闭包的方法.不完善实现如下: const compose = (f, g) => { ...
- vue 使用element-ui实现城市三级联动
<template> <div> <el-select v-model="prov" style="width:167px;margin-r ...
- 【dp 状态压缩 单调栈】bzoj3591: 最长上升子序列
奇妙的单调栈状压dp Description 给出1~n的一个排列的一个最长上升子序列,求原排列可能的种类数. Input 第一行一个整数n. 第二行一个整数k,表示最长上升子序列的长度. 第三行k个 ...
- Windows10系统可以禁止的服务(按名称排序)
1.Application LayerGateway Service(Windows必须禁止的10项服务) 2.Bluetooth Handsfree Service(没有蓝牙的用户可以关闭) 3.B ...
- html块级元素和行级元素的区别和使用
行内.块状元素区别: 1.行内元素与块级函数可以相互转换,通过修改display属性值来切换块级元素和行内元素,行内元素display:inline,块级元素display:block. 2.行内元素 ...
- Appium切换webview时候报chromedriver版本问题
前言 用appium切换webview的时候报chrome和chromedriver版本的问题:session not created exception: Chrome version must b ...
- hdu2046
递推题目,由于只有一种瓷砖,1*2规格的,所以一块2*2的面积上只能有2种摆放方式,然后就跟上台阶那个差不多,上一步或者上两部. 就是f[n]=f[n-1]+f[n-2]; 另外注意__int64的问 ...
- iOS知识列表
Xib和StoryBoard,自动布局地图导航,实时公交,第三方地图应用本地推送通知,网络推送通知,真机调试,应用上传绘图,图表,曲线图 Xcode使用技巧多线程,runtime机制编码解码,加密设备 ...
- 【Luogu】P1352没有上司的舞会(树形DP)
题目链接 设f[i][0]表示第i个人不去舞会时子树的最大欢乐度,f[i][1]表示第i个人去舞会时子树的最大欢乐度. 则有状态转移方程:f[i][0]+=∑max(f[to][0],f[to][1] ...