iOS 循环引用问题
来源:互联网 发布:百度云会员淘宝关键字 编辑:程序博客网 时间:2024/04/30 02:21
一、计时器NSTimer
方法一:
一方面,NSTimer经常会被作为某个类的成员变量,而NSTimer初始化时要指定self为target,容易造成循环引用。 另一方面,若timer一直处于validate的状态,则其引用计数将始终大于0。先看一段NSTimer使用的例子(ARC模式):
1 #import <Foundation/Foundation.h>2 @interface Friend : NSObject3 - (void)cleanTimer;4 @end
1 #import "Friend.h" 2 @interface Friend () 3 { 4 NSTimer *_timer; 5 } 6 @end 7 8 @implementation Friend 9 - (id)init10 {11 if (self = [super init]) {12 _timer = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(handleTimer:)13 userInfo:nil repeats:YES];14 }15 return self;16 }17 18 - (void)handleTimer:(id)sender19 {20 NSLog(@"%@ say: Hi!", [self class]);21 }22 - (void)cleanTimer23 {24 [_timer invalidate];25 _timer = nil;26 }27 - (void)dealloc28 {29 [self cleanTimer];30 NSLog(@"[Friend class] is dealloced");31 }
在类外部初始化一个Friend对象,并延迟5秒后将friend释放(外部运行在非arc环境下)
1 Friend *f = [[Friend alloc] init];2 dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 5*NSEC_PER_SEC), dispatch_get_main_queue(), ^{4 [f release];5 });
我们所期待的结果是,初始化5秒后,f对象被release,f的dealloc方法被调用,在dealloc里面timer失效,对象被析构。但结果却是如此:
2015-03-18 18:00:35.300 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:36.299 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:37.300 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:38.299 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:39.299 WZLCodeLibrary[41422:3390529] Friend say: Hi!
//运行了5次后没按照预想的停下来
2015-03-18 18:00:40.299 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:41.300 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:42.300 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:43.299 WZLCodeLibrary[41422:3390529] Friend say: Hi!
2015-03-18 18:00:44.300 WZLCodeLibrary[41422:3390529] Friend say: Hi!<br>.......根本停不下来.....
这是为什么呢?主要是因为从timer的角度,timer认为调用方(Friend对象)被析构时会进入dealloc,在dealloc可以顺便将timer的计时停掉并且释放内存;但是从Friend的角度,他认为timer不停止计时不析构,那我永远没机会进入dealloc。循环引用,互相等待,子子孙孙无穷尽也。问题的症结在于-(void)cleanTimer函数的调用时机不对,显然不能想当然地放在调用者的dealloc中。一个比较好的解决方法是开放这个函数,让Friend的调用者显式地调用来清理现场。如下:
Friend *f = [[Friend alloc] init];
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 5*
NSEC_PER_SEC
), dispatch_get_main_queue(), ^{
[f cleanTimer];
[f release];
});
方法二:
- @interface NSTimer (EOCBlocksSupport)
- + (NSTimer *)eoc_scheduledTimerWithTimeInterval:(NSTimeInterval)interval
- block:(void(^)())block
- repeats:(BOOL)repeats;
- @end
- @implementation NSTimer (EOCBlocksSupport)
- + (NSTimer *)eoc_scheduledTimerWithTimeInterval:(NSTimeInterval)interval
- block:(void(^)())block
- repeats:(BOOL)repeats
- {
- return [self scheduledTimerWithTimeInterval:interval
- target:self
- selector:@selector(eoc_blockInvoke:)
- userInfo:[block copy]
- repeats:repeats];
- }
- + (void)eoc_blockInvoke:(NSTimer*)timer {
- void (^block)() = timer.userInfo;
- if (block) {
- block();
- }
- }
方法三:
__weak id weakSelf = self; timer = [NSTimer scheduledTimerWithTimeInterval:30.0f target:weakSelf selector:@selector(tick) userInfo:nil repeats:YES];
(2)block
block在copy时都会对block内部用到的对象进行强引用(ARC)或者retainCount增1(非ARC)。在ARC与非ARC环境下对block使用不当都会引起循环引用问题,一般表现为,某个类将block作为自己的属性变量,然后该类在block的方法体里面又使用了该类本身,简单说就是self.someBlock = ^(Type var){[self dosomething];或者self.otherVar = XXX;或者_otherVar = ...};block的这种循环引用会被编译器捕捉到并及时提醒。举例如下,依旧以Friend类为例子:
#import "Friend.h"@interface Friend ()@property (nonatomic) NSArray *arr;@end@implementation Friend- (id)init{ if (self = [super init]) { self.arr = @[@111, @222, @333]; self.block = ^(NSString *name){ NSLog(@"arr:%@", self.arr); }; } return self;}
我们看到,在block的实现内部又使用了Friend类的arr属性,xcode给出了warning, 运行程序之后也证明了Friend对象无法被析构:
网上大部分帖子都表述为"block里面引用了self导致循环引用",但事实真的是如此吗?我表示怀疑,其实这种说法是不严谨的,不一定要显式地出现"self"字眼才会引起循环引用。我们改一下代码,不通过属性self.arr去访问arr变量,而是通过实例变量_arr去访问,如下:
由此我们知道了,即使在你的block代码中没有显式地出现"self",也会出现循环引用!只要你在block里用到了self所拥有的东西!但对于这种情况,目前我不知道该如何排除掉循环引用,因为我们无法通过加__weak声明或者__block声明去禁止block对self进行强引用或者强制增加引用计数。对于self.arr的情况,我们要分两种环境去解决:
1)ARC环境下:ARC环境下可以通过使用_weak声明一个代替self的新变量代替原先的self,我们可以命名为weakSelf。通过这种方式告诉block,不要在block内部对self进行强制strong引用:(如果要兼容ios4.3,则用__unsafe_unretained代替__weak,不过目前基本不需考虑这么low的版本)
1 self.arr = @[@111, @222, @333];2 __weak typeof(self) weakSelf=self;3 self.block = ^(NSString *name){4 NSLog(@"arr:%@", weakSelf.arr);5 };
2)MRC环境下:解决方式与上述基本一致,只不过将__weak关键字换成__block即可,这样的意思是告诉block:小子,不要在内部对self进行retain了!
(3)委托delegate
在委托问题上出现循环引用问题已经是老生常谈了,本文也不再细讲,规避该问题的杀手锏也是简单到哭,一字诀:声明delegate时请用assign(MRC)或者weak(ARC),千万别手贱玩一下retain或者strong,毕竟这基本逃不掉循环引用了!
- iOS 循环引用问题
- iOS 循环引用问题
- iOS循环引用问题
- ios block循环引用问题
- ios block循环引用问题
- ios block循环引用问题
- ios block循环引用问题
- ios- block循环引用问题
- ios- block循环引用问题
- iOS block循环引用问题
- iOS循环引用问题集合
- ios中循环引用问题
- [iOS]ARC下循环引用的问题
- [iOS]ARC下循环引用的问题
- [iOS]ARC下循环引用的问题
- [IOS]ARC下循环引用的问题
- iOS复习笔记7:循环引用问题
- [iOS]ARC下循环引用的问题
- C++中typename和class的区别
- Android中触摸事件传递分发机制
- 数据结构Java实现 --单向链表的插入和删除
- sqlServer 的触发器的使用基础
- kernel版本更新追踪
- iOS 循环引用问题
- TTL电路与CMOS电路对比
- 完整java开发中JDBC连接数据库代码和步骤
- Android和Linux kernel版本对应表
- POJ 1006 Biorhythms
- ROS(10):mac 下树莓派Raspberry Pi 烧录 img
- noi2014 起床困难综合症(未完成)
- 数据结构Java实现 ----循环链表、仿真链表
- 类型转换扯的淡