参考https://blog.csdn.net/clovejq/article/details/71107674
ios中引入自动ARC后会产生内存泄露的情况就是循环引用,相互等待,造成内存不能释放。
循环强引用也有可以用的地方,这样可以避免提前释放,但是自己一定要记住,用完后置为nil,让其自动释放
二、Block循环引用
【??strongself是为了防止内存提前释放,有兴趣的童鞋可深入了解,这里不做过多解释了。当然也可借助libextobjc库进行解决,书写为@weakify和@strongify会更方便些。】
三、delegate循环引用问题
delegate循环引用问题比较基础,只需注意将代理属性修饰为weak即可
1
|
@property (nonatomic, weak) id delegate;
|
下图比较形象的说明了使用weak修饰就是为了防止ViewController和UITableView相互强引用内存无法释放的问题:
delegate循环引用
四、NSTimer循环引用
在外部调用时,将其创建后5秒销毁。
1
2
3
4
|
TestNSTimer *timer = [[TestNSTimer alloc]init];
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
[timer release];
});
|
最后的执行结果为
我们都知道定时器使用完毕时需要将其停止并滞空,但cleanTimer方法到底何时调用呢?在当前类的dealloc方法中吗?并不是,若将cleanTimer方法调用在dealloc方法中会产生如下问题,当前类销毁执行dealloc的前提是定时器需要停止并滞空,而定时器停止并滞空的时机在当前类调用dealloc方法时,这样就造成了互相等待的场景,从而内存一直无法释放。因此需要注意cleanTimer的调用时机从而避免内存无法释放,如上的解决方案为将cleanTimer方法外漏,在外部调用即可。
1
2
3
4
5
|
TestNSTimer *timer = [[TestNSTimer alloc]init];
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
[timer cleanTimer];
[timer release];
});
|
打印结果
五、非OC对象内存处理
对于iOS开发,ARC模式已发扬光大多年,可能很多人早已忘记当年retain、release的年代,但ARC的出现并不是说我们完全可以忽视内存泄漏的问题。对于一些非OC对象,使用完毕后其内存仍需要我们手动释放。
五、地图类处理
若项目中使用地图相关类,一定要检测内存情况,因为地图是比较耗费App内存的,因此在根据文档实现某地图相关功能的同时,我们需要注意内存的正确释放,大体需要注意的有需在使用完毕时将地图、代理等滞空为nil,注意地图中标注(大头针)的复用,并且在使用完毕时清空标注数组等。
六、大次数循环内存暴涨问题
记得有道比较经典的面试题,查看如下代码有何问题:
1
2
3
4
5
6
|
for
(int i = 0; i < 100000; i++) {
NSString *string = @
"Abc"
;
string = [string lowercaseString];
string = [string stringByAppendingString:@
"xyz"
];
NSLog(@
"%@"
, string);
}
|
该循环内产生大量的临时对象,直至循环结束才释放,可能导致内存泄漏,解决方法为在循环中创建自己的autoReleasePool,及时释放占用内存大的临时变量,减少内存占用峰值。
1
2
3
4
5
6
7
8
|
for
(int i = 0; i < 100000; i++) {
@autoreleasepool {
NSString *string = @
"Abc"
;
string = [string lowercaseString];
string = [string stringByAppendingString:@
"xyz"
];
NSLog(@
"%@"
, string);
}
}
|