iOS内存警告和内存优化集合二
2016-04-28 10:53
429 查看
iphone下每个app可用的内存是被限制的,如果一个app使用的内存超过20M,则系统会向该app发送Memory Warning消息。收到此消息后,app必须正确处理,否则可能出错或者出现内存泄露。
app收到Memory Warning后会调用:UIApplication::didReceiveMemoryWarning -> UIApplicationDelegate::applicationDidReceiveMemoryWarning,然后调用当前所有的viewController进行处理。因此处理的主要工作是在viewController。
当我们的程序在第一次收到内存不足警告时,应该释放一些不用的资源,以节省部分内存。否则,当内存不足情形依然存在,ios再次向我们程序发出内存不足的警告时,我们的程序将会被iOS
kill掉。
苹果给每个应用程序设置20M的内存警告量,30M的闪退量,游戏会略微放款10~20M,需要向系统申请。
这一条说明除了系统本身占用内存以外,任何程序几乎都不可能占用超过50M内存。←此句我着重解释一下,因为大家问题比较多,本来就是为了让更多纯小白玩家明白才这么写的。如果您完全不明白我说什么,无视红字即可。实际上,不是单个程序存在50M的内存使用上限,而是单线程使用上限是50M,同一个程序可以加载多个线程,同一个程序可以使用多个线程。剩下的我就不细说了。
//释放暂时不使用的内存,在控制器中实现下面的方法;
- (void)didReceiveMemoryWarning
{
[super didReceiveMemoryWarning];
// Dispose of any resources that can be recreated.
//当收到内存警告时,移除当前没有在屏幕上显示的视图.
//判断是否可以安全的移除视图控制器的view.
//判断当前的视图控制器的view是否是屏幕上显示.self.view.window
//判断当前视图控制器的view是否已经成功加载.isViewLoaded
if( self.view.window == nil && [self isViewLoaded]) {
//安全移除控制器的view;
self.view = nil;//[_view release];_view = nil;
}
//NSLog(@"%@",self.view.window);
}
=========================================
05十一
做iOS开发在模拟器上可以通过 Hardware -> Simulate Memory Warning 模拟内存警告,当我们使用真机的时候,或者说想给测试的同事也提供这样功能的时候,那我们就需要写程序,通过代码来实现了。
代码很简单,就一行:
但是请注意,最好只在测试的时候使用,发布到App Store的时候不要将上面的代码编译进去,使用这种没有文档化的方法有可能导致审核不通过,或者根本无法上传。
============================================
iOS 5内存警告原理:
app收到Memory Warning后会调用:
UIApplication::didReceiveMemoryWarning -> UIApplicationDelegate::applicationDidReceiveMemoryWarning,然后调用当前所有的viewController进行处理。因此处理的主要工作是在viewController。
我们知道,创建viewcontroller时,执行顺序是loadview -> viewDidLoad。
当收到内存警告时,如果viewcontroller未显示(在后台),会执行didReceiveMemoryWarning -> viewDidUnLoad;如果viewcontroller当前正在显示(在前台),则只执行didReceiveMemoryWarning。
当重新显示该viewController时,执行过viewDidUnLoad的viewcontroller(即原来在后台)会重新调用loadview -> viewDidLoad。
因此主要注意下面几个函数:
实际中如果viewcontroller是用xib生成的界面,则需要我们做的就比较少,主要是在viewDidLoad中恢复原来的界面状态。
如果是通过编程创建的界面,则需要做的工作就要更多些,上面4个函数中都需要进行正确处理。
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而费力回收内存。
=================================================
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 置为空,以换取更多可用内存。
==========================================
layoutsubviews的调用频次很高,一般不在里面做耗时的操作.
宏定义多的话,编译时间会加长,导致程序启动变慢.
app收到Memory Warning后会调用:UIApplication::didReceiveMemoryWarning -> UIApplicationDelegate::applicationDidReceiveMemoryWarning,然后调用当前所有的viewController进行处理。因此处理的主要工作是在viewController。
当我们的程序在第一次收到内存不足警告时,应该释放一些不用的资源,以节省部分内存。否则,当内存不足情形依然存在,ios再次向我们程序发出内存不足的警告时,我们的程序将会被iOS
kill掉。
苹果给每个应用程序设置20M的内存警告量,30M的闪退量,游戏会略微放款10~20M,需要向系统申请。
这一条说明除了系统本身占用内存以外,任何程序几乎都不可能占用超过50M内存。←此句我着重解释一下,因为大家问题比较多,本来就是为了让更多纯小白玩家明白才这么写的。如果您完全不明白我说什么,无视红字即可。实际上,不是单个程序存在50M的内存使用上限,而是单线程使用上限是50M,同一个程序可以加载多个线程,同一个程序可以使用多个线程。剩下的我就不细说了。
//释放暂时不使用的内存,在控制器中实现下面的方法;
- (void)didReceiveMemoryWarning
{
[super didReceiveMemoryWarning];
// Dispose of any resources that can be recreated.
//当收到内存警告时,移除当前没有在屏幕上显示的视图.
//判断是否可以安全的移除视图控制器的view.
//判断当前的视图控制器的view是否是屏幕上显示.self.view.window
//判断当前视图控制器的view是否已经成功加载.isViewLoaded
if( self.view.window == nil && [self isViewLoaded]) {
//安全移除控制器的view;
self.view = nil;//[_view release];_view = nil;
}
//NSLog(@"%@",self.view.window);
}
=========================================
iOS中使用代码模拟内存警告
05十一做iOS开发在模拟器上可以通过 Hardware -> Simulate Memory Warning 模拟内存警告,当我们使用真机的时候,或者说想给测试的同事也提供这样功能的时候,那我们就需要写程序,通过代码来实现了。
代码很简单,就一行:
[[UIApplication sharedApplication] performSelector:@selector(_performMemoryWarning)];
但是请注意,最好只在测试的时候使用,发布到App Store的时候不要将上面的代码编译进去,使用这种没有文档化的方法有可能导致审核不通过,或者根本无法上传。
============================================
iOS 5内存警告原理:
app收到Memory Warning后会调用:
UIApplication::didReceiveMemoryWarning -> UIApplicationDelegate::applicationDidReceiveMemoryWarning,然后调用当前所有的viewController进行处理。因此处理的主要工作是在viewController。
我们知道,创建viewcontroller时,执行顺序是loadview -> viewDidLoad。
当收到内存警告时,如果viewcontroller未显示(在后台),会执行didReceiveMemoryWarning -> viewDidUnLoad;如果viewcontroller当前正在显示(在前台),则只执行didReceiveMemoryWarning。
当重新显示该viewController时,执行过viewDidUnLoad的viewcontroller(即原来在后台)会重新调用loadview -> viewDidLoad。
因此主要注意下面几个函数:
loadView | 创建view,构建界面; |
viewDidLoad | 做些初始化工作。由于在初次创建viewcontroller和重新恢复时都会调用,因此这个函数需要注意区分不同的情况,设置正确的状态。 |
didReceiveMemoryWarning | 释放不必须的内存,比如缓存,未显示的view等。 |
viewDidUnLoad | 最大程度的释放可以释放的内存。比如应该释放view,这些view在调用loadview后可以重新生成。(其中成员变量释放后应设置为nil)。对于非界面的数据是否释放,需要具体分析,可以恢复的数据可以释放,不能恢复的数据就不要释放。 |
如果是通过编程创建的界面,则需要做的工作就要更多些,上面4个函数中都需要进行正确处理。
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而费力回收内存。
=================================================
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 置为空,以换取更多可用内存。
==========================================
layoutsubviews的调用频次很高,一般不在里面做耗时的操作.
宏定义多的话,编译时间会加长,导致程序启动变慢.
相关文章推荐
- iOS 启动图片的配置过程
- 在ios系统中查看模拟器和真机中的沙盒目录
- iOS 苹果推送(APNS)注意事项
- iOS 根据文字自适应高度
- 制作 cocoapods 类库
- iOS动画详解
- iOS 开发 证书总结 开发证书和生产证书的区别
- IOS工程配置
- iOS百度云推送问题
- 《Motion Design for iOS》(五)
- JS&iOS原生交互
- iOS 利用阿里云上传及下载图片
- ios-NSString总结
- IOS动画总结-Core Animation
- miss @end
- 浅谈iOS中的蓝牙技术(一) --GameKit.framework
- Ios中常见的问题
- iOS 调用地图导航
- iOS开发 ☞ 应用间跳转
- sdwebimage 图片大小 处理