最近通过Analyze
及Leaks
等工具对项目进行了内存泄漏问题的检测及修改,现对遇到的易造成内存泄漏的问题进行一些总结,每点中都列举了会造成内存泄漏的代码书写方式,并对其原因进行分析,最后给出了相关的解决方案。
接下来就开始进行总结:
一、 循环引用
循环引用是在iOS可能引起内存泄漏的主要原因,这类问题常见的出现在Block的使用中,由于Block会持有所使用到的变量,下面就总结下Block使用中需要注意的点:
1. 在Block中使用self
关键字
示例代码
@interface TestModel : NSObject
@property (nonatomic, copy) void(^TheBlock)(void);
@end
@implementation TestModel
@end
@interface TestViewController ()
@property (nonatomic, strong) TestModel *model;
@end
@implementation TestViewController
- (void)viewDidLoad {
[super viewDidLoad];
self.model = [[TestModel alloc] init];
self.model.TheBlock = ^{
NSLog(@"TestViewController->%@", self);
};
}
@end
问题分析
此类问题为最基本的循环引用问题,即TestViewController持有TestModel,TestModel持有Block,Block持有TestViewController。
解决方案
在Block中使用weakSelf打破循环引用。
2. 在Blcok中访问对象的实例变量
示例代码
@interface TestViewController ()
@property (nonatomic, copy) NSString *foo;
@end
@implementation TestViewController
- (void)viewDidLoad {
[super viewDidLoad];
void(^block)(void) = ^{
NSLog(@"foo->%@", _foo);
};
block();
}
@end
问题分析
该种写法不一定会造成内存泄漏,只有在TestViewController的持有链中持有block时才会造成内存泄漏。原因在于在Block中使用某个对象的实例变量时,会持有该对象。
解决方案
建议在Block中使用实例变量时显式指出self.
或weakSelf.
,通过显式指出,可以在一定程度上提示开发人员注意解决self持有问题。
3. 在Block中使用super
关键字
示例代码
@implementation TestViewController
- (void)viewDidLoad {
[super viewDidLoad];
void(^block)(void) = ^{
NSLog(@"description->%@", [super description]);
};
block();
}
@end
问题分析
该类问题与前一点类似,都是只有在TestViewController的持有链中持有block才会造成循环引用。问题原因在于,使用super
时,寻找的对应方法为父类中方法,即在最终转换为objc_msgSend
时,传入的第一个参数依旧为对象本身,从而使Block持有对象。
解决方案
(1) 使用super
时确保该Block不会被对象持有链持有。
(2) 将相关super
的调用包装成一个方法,在Block中使用weakSelf去调用该方法。
4. Block中使用宏定义
示例代码
#define TOP_TITLE_HEIGHT self.navigationController.navigationBar.frame.size.height
@implementation TestViewController
- (void)viewDidLoad {
[super viewDidLoad];
void(^block)(void) = ^{
NSLog(@"description->%@", @(TOP_TITLE_HEIGHT));
};
block();
}
@end
问题分析
该情况同样是在对象持有链中持有block才会引起循环引用,但该情况由于使用的是宏定义,很容易造成对self
使用检查的忽略。
解决方案
(1) 尽量避免在宏定义中使用self
关键字。
(2) 同时在Block中使用宏定义时做到全面的检查。
5. 在Block中使用持有Block的变量
示例代码
@interface TestModel : NSObject
@property (nonatomic, copy) void(^TheBlock)(void);
@end
@implementation TestModel
@end
@implementation TestViewController
- (void)viewDidLoad {
[super viewDidLoad];
TestModel *model = [[TestModel alloc] init];
model.TheBlock = ^{
NSLog(@"Model-->%@", model);
};
}
@end
问题分析
该问题同样是在Block中捕获了Block持有链中的对象,从而形成持有循环,造成无法释放。
解决方案
解决方案与第一点相同,打破持有循环就可以,推荐在block中使用weakModel。
二、 内存管理问题
1. MRC与ARC混编
示例代码
//使用MRC模式进行内存管理
+ (id)objectWithContentOfFile:(NSString *)path
{
NSData * data = [[NSData alloc] initWithContentsOfFile:path];
id object = [self objectWithData:data];
return object;
}
问题分析
在ARC推出这么久之后,我们的项目大多数使用ARC模式来管理内存,但是避免不了使用到一些MRC管理的文件,此时若在此类文件中遗忘掉内存管理,则会造成内存泄漏。
解决方案
(1) 对于使用--fno-objc-arc
明确指定的文件,要做到手动管理内存(关于内存管理的知识,可以参考这篇文章),同时建议对该文件提供的功能进行Leaks
检测。
(2) 同时对于已经进行release的对象,应当避免再次访问,以防止触发野指针访问。建议对release之后的变量进行置空操作。
2. CoreFoundation与Foundation的桥接
实例代码
NSString * name = (__bridge NSString *)ABRecordCopyCompositeName(person);
NSMutableDictionary *keychainQuery = [self foo];
SecItemDelete((__bridge_retained CFDictionaryRef)keychainQuery);
问题分析
上述代码出现内存泄漏的问题在于CoreFoundation下对象需要开发者自己管理。
第一段代码中,使用带copy字眼的函数创建了CoreFoundation对象,进而桥接为Foundation对象,此时Foundation对象由ARC负责管理,而CoreFoundation对象则没有对应的释放,进而造成内存泄漏。
第二段代码中,使用__bridge_retained
将Foundation对象桥接至CoreFoundation对象,此时Foundation对象由ARC负责管理,而CoreFoundation对象则没有对应的释放,进而造成内存泄漏。
解决方案
对于CoreFoundation与Foundation框架之间的桥接,可以使用下面三种方式:
1. __bridge
该桥接方法可以将CoreFoundation对象与Foundation对象进行桥接,桥接前后对于被桥接的对象没有计数的改变。
2. __bridge_retained
一般用在将Foundation对象桥接为CoreFoundation对象,该方法会使得对象计数增加,所以需要开发者对桥接后的CoreFoundation对象进行相应的计数减少。关于减少CoreFoundation对象计数的注意事项,有以下几点:
- 在将CoreFoundation对象进行计数减少后,为避免再次访问该对象可能造成野指针访问,建议及时将对象置为NULL。
- 对于CoreFoundation框架对象来说,可以使用
CFRelease
函数进行计数减少,需要注意的是,在调用该函数前要对对象进行NULL检查,CFRelease
函数在对NULL操作时会发生崩溃。 - 对于某些类型的CoreFoundation对象,可以使用特有的减少计数方法,例如:
CGImageRef
对象可以使用CGImageRelease
函数,CGFontRef
对象可以使用CGFontRelease
函数。但是具体函数是否封装了对NULL的检测,需要查看函数介绍,CGImageRef
与CFRelease
相同未检测NULL,CGFontRelease
函数说明为/* Equivalent to `CFRelease(font)', except it doesn't crash (as CFRelease does) if `font' is NULL. */
,封装了NULL的检测。
3. malloc的使用
实例代码
void *createWaveHeader()
{
struct wave_header *header = (struct wave_header *)malloc(sizeof(struct wave_header));
if (header == NULL) {
return NULL;
}
//do somethind
return header;
}
void foo()
{
NSMutableData *wavDatas = [[NSMutableData alloc] init];
void *header = createWaveHeader();
[wavDatas appendBytes:header length:44];
//do something
}
问题分析
这类问题主要为malloc申请内存未对应free导致内存泄漏。
解决方案
正常情况下我们在函数中使用malloc一般都会对应free,但在使用将malloc申请的内存作为返回值的函数时,很有可能遗忘对内存的释放。建议在使用返回指针的函数时要特别注重这类问题,同时函数的文档中也需要特别指出返回值需要调用者手动释放,避免调用者遗忘。
同时调用者在进行free之前,需要对指针进行NULL的检测。
在调用NSData
的+ (instancetype)dataWithBytesNoCopy:(void *)bytes length:(NSUInteger)length;
方法或+ (instancetype)dataWithBytesNoCopy:(void *)bytes length:(NSUInteger)length freeWhenDone:(BOOL)b;
且传入YES时,会对bytes进行释放,无需显示调用free来释放bytes。
三、 其余需要注意的内存泄漏问题
1. 使用NSTimer
@interface TestViewController ()
@property (nonatomic, strong) NSTimer *timer;
@end
@implementation TestViewController
- (void)viewDidLoad {
[super viewDidLoad];
[NSTimer scheduledTimerWithTimeInterval:1.0 target:self selector:@selector(timerAction) userInfo:nil repeats:YES];
}
- (void)timerAction
{
NSLog(@"timer action");
}
@end
问题分析
NSTimer会对target进行持有,若不停止Timer,那么Timer会一直执行下去并一直持有TestViewController,造成TestViewController无法释放,形成内存泄漏。
解决方案
(1) 在Timer持有的对象想要释放时手动停止Timer。
(2) 打破Timer对target的强持有,具体方案可参考YYWeakProxy。
2. 使用NSURLSessionTask及其子类
- (void)viewDidLoad {
[super viewDidLoad];
NSURLSession *session = [NSURLSession sharedSession];
NSURLSessionDataTask *dataTask = [session dataTaskWithURL:[NSURL URLWithString:@"http://www.baidu.com"]];
}
问题分析
在生成NSURLSessionTask
及其子类对象时,该对象会处于挂起状态,此时该对象会一直常驻内存,若代码失去对该对象的引用,那么就会造成内存泄漏。
解决方案
在代码对NSURLSessionTask
及其子类对象失去引用前,需要为该对象调用cancel
或resume
方法,使之脱离挂起状态。