内存泄漏是很常见的问题，虽然在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);
}];
