iOS内存泄漏的几种情况
2017-05-09 本文已影响119人
娘亲Joanna
1.Delegate/NSNotification
-
在使用代理设计模式的时候，一定要注意将 delegate 变量声明为 weak 类型，像这样
-
如使用strong或别的类型修饰的话将会导致循环引用，导致dealloc()不会被调用。NSNotification没有移除通知等都会触发一些意想不到的后果。
2.Block
-
目前在项目中出现的内存泄漏大部分是因为block的问题。
-
在 ARC 下，当 block 获取到外部变量时，由于编译器无法预测获取到的变量何时会被突然释放，为了保证程序能够正确运行，让 block 持有获取到的变量，向系统声明：我要用它，你们千万别把它回收了！然而，也正因 block 持有了变量，容易导致变量和 block 的循环引用，造成内存泄露
[_sortButton setButtonSpreadPreAction:^BOOL{
if (_resultItems.count == 0) {
[progressHUD showText:@"xxxx"];
return NO;
}
return YES;
}];
-
这个例子的问题就在于在使用 block 的过程中形成了循环引用：self 持有 sortButton；sortButton 持有 block；block 持有 self。三者形成循环引用，内存泄露。
- 说明原理：self —> _sortButton —> block —> _resultItems (_resultItems属于self 相当于 block—>self)
-
GCD已经一些系统级的API并不会提示循环引用的警告，但通过测试发现，大部分系统提供block也是需要弱引用的__weak typeof(self) weakSelf = self;
项目中除了AFN的第三方组件在调用block时都是需要弱引用的。
3.NSTimer
- NSTimer在释放前，一定要调用[timer invalidate]，不调用的后果就是NSTimer无法释放其target，如果target正好是self，则会导致引用循环。
- (void)performSelector:(SEL)aSelector withObject:(id)anArgument afterDelay:(NSTimeInterval)delay
官方文档是这样说的:
This method sets up a timer to perform the aSelector message on the current thread’s run loop. The timer is configured to run in the default mode (NSDefaultRunLoopMode). When the timer fires, the thread attempts to dequeue the message from the run loop and perform the selector. It succeeds if the run loop is running and in the default mode; otherwise, the timer waits until the run loop is in the default mode.
大概意思是系统依靠一个timer来保证延时触发，但是只有在runloop在default mode的时候才会执行成功，否则selector会一直等待run loop切换到default mode。根据我们之前关于timer
的说法，在这里其实调用performSelector:afterDelay:同样会造成系统对target强引用，也即retain住。这样子，如果selector一直无法执行的话（比如runloop不是运行在default model下）,这样子同样会造成target一直无法被释放掉，发生内存泄露。怎么解决这个问题呢？其实很简单，我们在适当的时候取消掉该调用就行了，系统提供了接口:
+ (void)cancelPreviousPerformRequestsWithTarget:(id)aTarget
这里要补充一点，引用循环不是只能有两个对象，三个四个更多都是可以的，甚至环数也不一定只有一个，所以要养成良好的代码习惯，在NSTimer停用前调用invalidate方法。
