IOS内存泄漏检测方式和泄漏场景
内存泄漏是很常见的问题,虽然在ARC后苹果为我们解决了大量的烦恼,但是一个不小心还是会陷进去。这段时间在公司做了一些内存泄漏排查与修改的工作,介绍一下用到的一些检测方式和常见的场景。
内存泄漏的检测方式
1. 静态检测
使用XCode分析功能,Product->Analyze
使用静态检测可以检查出一些明显的没有释放的内存,包括NSObject和CF开头的内存泄漏,最常见问题有2种,这些问题都不复杂,需要的是细心:
- MRC的文件,经常遗漏release或者autorelease
- C方式申请的内存,忘记释放了
static inline NSString* iphone_device_info(){
size_t size;
sysctlbyname("hw.machine", NULL, &size, NULL, 0);
char *machine = (char*)malloc(size);
sysctlbyname("hw.machine", machine, &size, NULL, 0);
NSString *platform = [NSString stringWithCString:machine encoding:NSASCIIStringEncoding];
...
}
if (alpha != 1) {
CGColorSpaceRef colorSpaceRef = CGColorSpaceCreateDeviceRGB();
CGColorRef color = CGColorCreate(colorSpaceRef, (CGFloat[]){255, 255, 255, 0.3});
[btn.layer setBorderColor:color];
}
不过在修改的时候需要注意:
- 这些场景是否真的泄漏了,以免造成重复释放。
- 注意该文件是MRC还是ARC,需要不同的内存处理方式。
- 如果是C申请的内存,注意new delete, malloc free的配对处理。
比如我们的代码中有这样的问题:
if ([self.itemOutput hasNewPixelBufferForItemTime:currentTime]) {
[self displayPixelBuffer:[self.itemOutput copyPixelBufferForItemTime:currentTime itemTimeForDisplay:NULL]];
[_program useGlProgram];
}
在进行静态检测时,会报“copyPixelBufferForItemTime”内存泄漏,copy后的内存需要释放。可事实上,在“displayPixelBuffer”函数中已经对传入对内存进行了释放,
我们姑且不论这样对写法是否合理,只是切记在修改时注意结合上下文处理需要释放的内存
。
2. 动态检测
使用instruments,这个工具网上的介绍比较多,可以参考如下
在Allocation中我们主要关注的是Persistent和Persistent Bytes,分别表示当前时间段,申请了但是还没释放的内存数量和大小。
记住当前这两个值,然后进入某个新页面,退出该页面,观察这两个值是否增加。需要注意的是,由于有些图片调用本身是有缓存的,如果是用SDWebImage管理,则网络图片都会缓存在内存中。因此退出页面后内存有增加是正常的,而且还有些单例的内存也是不会释放的,我们可以再次进入同一个页面,在图片都加载过的情况下,反复进入退出查看内存状况,如果持续增加,则说明有泄漏。
3. 第三方工具MLeaksFinder
主要检查UI方面的泄漏,集成简单,在我看来主要的好处有3点:
1.不同于instrument的分析功能,需要人工观察,这个工具自动检测,发现有泄漏后可以实时进行提示,虽然主要是针对UI,但对于一般的工程来说,内存泄漏的场景中还是以UI居多,因此可以解决很大部分的问题。
2.在新功能的开发过程和解决bug的过程中,出现内存泄漏都可以很轻松的检测出来。
3.可以给测试同学打包时开启这个功能,帮助测试发现问题。
具体特点,原理和集成方式可以参考如下博客的内容:
内存泄漏的常见场景
CF类型内存
注意以creat,copy
作为关键字的函数都是需要释放内存的,注意配对使用。比如:CGColorCreate<-->CGColorRelease
MRC内存使用
这部分不做详细介绍,也是注意配对使用,需要说明的是,如果代码中有部分文件是MRC的,在已有文件中加代码的时候注意一下,不能都按照ARC的方式处理。
ARC内存使用
ARC已经为我们做了很多封装,我们不必再显示的调用retain,release,但是还是要注意循环引用的场景。
在此,常规的对象间的互相引用和block的循环引用大家都比较了解,这里就不赘述了,罗列几个我们代码中的错误。
1. NSTimer
NSTimer会造成循环引用,timer会强引用target即self,一般self又会持有timer作为属性,这样就造成了循环引用。
那么,如果timer只作为局部变量,不把timer作为属性呢?同样释放不了,因为在加入runloop的操作中,timer被强引用。而timer作为局部变量,是无法执行invalidate的,所以在timer被invalidate之前,self也就不会被释放。
所以我们要注意,不仅仅是把timer当作实例变量的时候会造成循环引用,只要申请了timer,加入了runloop,并且target是self,虽然不是循环引用,但是self却没有释放的时机。如下方式申请的定时器,self已经无法释放了。
NSTimer *timer = [NSTimer timerWithTimeInterval:5 target:self selector:@selector(commentAnimation) userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];
解决这种问题有几个实现方式,大家可以根据具体场景去选择:
- 增加startTimer和stopTimer方法,在合适的时机去调用,比如可以在viewDidDisappear时stopTimer,或者由这个类的调用者去设置。
- 每次任务结束时使用dispatch_after方法做延时操作。注意使用weakself,否则也会强引用self。
- (void)startAnimation
{
WS(weakSelf);
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
[weakSelf commentAnimation];
});
}
- 使用GCD的定时器,同样注意使用weakself。
WS(weakSelf);
timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, dispatch_get_main_queue());
dispatch_source_set_timer(timer, DISPATCH_TIME_NOW, 5 * NSEC_PER_SEC, 1 * NSEC_PER_SEC);
dispatch_source_set_event_handler(timer, ^{
[weakSelf commentAnimation];
});
dispatch_resume(timer);
我的另外一篇文章对各种解决方式和其他的定时器操作做了总结(https://www.jianshu.com/p/ca579c502894),大家可以参考。
2. NSNotification
使用block的方式增加notification,引用了self,在删除notification之前,self不会被释放,与timer的场景类似,其实这段代码已经声明了weakself,但是调用_eventManger方法还是引起了循环引用。
也就是说,即使我们没有调用self方法,_xxx
也会造成循环引用。
[[NSNotificationCenter defaultCenter] addObserverForName:kUserSubscribeNotification object:nil queue:nil usingBlock:^(NSNotification *note) {
if (note) {
Model *model=(Model *)note.object;
if ([model.subId integerValue] == [weakSelf.subId integerValue]) {
[_eventManger playerSubsciption:NO];
}
}
}
3. __block
__block
在MRC
中是不会增加引用的,可是在ARC
中会增加,所以在ARC中,只能使用__weak去打破循环引用。
__block MyViewController *weaksef = self;
_myViewController.editBlock = ^(){
[weaksef refreshUI];
};
另外声明一点,并非所有的block都需要使用weak来打破循环引用,如果self没有持有block就不会造成循环引用。而有些地方之所以使用了__weak,是为了在[self dealloc]之后就不再执行了。在这种场景下使用weakself时,也需要注意,如果self被释放了会不会引起异常。比如下面这段代码把weakself取到的值作为入参,如果self释放了,传nil,引起crash:
[[HttpCore sharedInstance] getRequestWithPath:url target:self params:params success:^(NSDictionary *result, NSURLRequest *request, NSHTTPURLResponse *response) {
} failure:^(NSError *error) {
dispatch_group_leave(weakSelf.startGroup);
}];