巧妙的解決NSTimer的循環引用

一 發現問題

我們都知道NSTimer采用target-action的方式,通常target又是類本身,我們為了方便又把NSTimer聲明為屬性變量,這樣就難免會造成循環引用(需要反復執行計時任務時,如果是單次的任務就不會造成循環引用)。例如:

_timer = [NSTimer scheduledTimerWithTimeInterval:5.0
                                          target:self
                                        selector:@selector(startTimer) userInfo:nil
                                         repeats:YES];

深入理解,類有一個成員變量_timer,給_timer設置的target為這個類本身。這樣類保留_timer,_timer又保留了這個類,就會出現循環引用的問題,最后導致類無法正確釋放。

大家可能覺得解決這個問題很簡單,在合適的時機釋放NSTimer,大多人多會選擇viewWillDisappear,viewDidDisappear,dealloc。當然了如果選擇在dealloc釋放NSTimer的且覺得這樣沒問題的,那是你不夠了解dealloc的執行時間,科普下dealloc的執行時機是在self釋放之后執行的。這樣就排除了dealloc,那就只能選擇viewWillDisappear,viewDidDisappear(push和pop都會執行)。但是這兩個方法往往不能滿足需求。

二 解決問題

有去了解NSTimer循環引用的同學,知道有兩種常見的方法可以解決:

  1. 采用block封裝,target設置為NSTimer本身
  2. 既然是因為target是self本身造成的,那就把target設置為其他對象

(第一種block就不用說了,大家也比較喜歡這種方式,但是有時候就不想用block呢,想用第二種方法,但是用起來有很多不便之處,target是其他對象,action也要在其他對象,這樣在action想要訪問self的相關信息就很不方便。于是就有第三種方法誕生了。)

3.用一個含有weak屬性的對象A包裹self作為target,再對A進行消息轉發,訪問A就相當于訪問self,這樣就完美的解決了循環引用,且保留了target-action方式。

大家比較好奇的是有weak屬性的對象A的類怎么實現,下面來看看代碼:

#import <Foundation/Foundation.h>

#pragma mark -
#pragma mark - 內置weak對象(可用于分類定義weak屬性)
@interface XWWeakObject : NSObject

@property (nullable, nonatomic, weak, readonly) id weakObject;

- (instancetype _Nullable )initWeakObject:(id _Nullable )obj;

+ (instancetype _Nullable )proxyWeakObject:(id _Nullable )obj;

@end


#import "XWWeakObject.h"

@implementation XWWeakObject

-(instancetype)initWeakObject:(id)obj{
    _weakObject = obj;
    return self;
}

+(instancetype)proxyWeakObject:(id)obj{
    
   return  [[XWWeakObject alloc] initWeakObject:obj];
}


- (id)forwardingTargetForSelector:(SEL)selector {
    return _weakObject;
}

- (void)forwardInvocation:(NSInvocation *)invocation {
    void *null = NULL;
    [invocation setReturnValue:&null];
}

- (NSMethodSignature *)methodSignatureForSelector:(SEL)selector {
    return [NSObject instanceMethodSignatureForSelector:@selector(init)];
}

- (BOOL)respondsToSelector:(SEL)aSelector {
    return [_weakObject respondsToSelector:aSelector];
}

- (BOOL)isEqual:(id)object {
    return [_weakObject isEqual:object];
}

- (NSUInteger)hash {
    return [_weakObject hash];
}

- (Class)superclass {
    return [_weakObject superclass];
}

- (Class)class {
    return [_weakObject class];
}

- (BOOL)isKindOfClass:(Class)aClass {
    return [_weakObject isKindOfClass:aClass];
}

- (BOOL)isMemberOfClass:(Class)aClass {
    return [_weakObject isMemberOfClass:aClass];
}

- (BOOL)conformsToProtocol:(Protocol *)aProtocol {
    return [_weakObject conformsToProtocol:aProtocol];
}

- (BOOL)isProxy {
    return YES;
}

- (NSString *)description {
    return [_weakObject description];
}

- (NSString *)debugDescription {
    return [_weakObject debugDescription];
}
@end

XWWeakObject類有一個weak只讀weakObject對象(這個類也可以用于分類聲明weak屬性:分類是本身是不能聲明weak屬性的)。
用運行時對該類的對象做了消息轉發,對象轉發,在訪問XWWeakObject對象的時候相當于訪問其屬性weakObject對象。

最后看下怎么用代碼實現的:

- (void)viewDidLoad {
    [super viewDidLoad];
   
    XWWeakObject *target = [XWWeakObject proxyWeakObject:self];
    self.timer = [NSTimer scheduledTimerWithTimeInterval:1 target:target selector:@selector(timerCount) userInfo:nil repeats:YES];

}

-(void)timerCount{  
}

-(void)dealloc{
    
    [_timer invalidate];
     _timer = nil;
}

前提timer是self的一個屬性,創建一個XWWeakObject對象target,target是內部weak屬性指向self,相當于target擁有self且是weak,self的retain沒有加1,timer擁有XWWeakObject對象target,target的retain加1,timer和self的直接關系是timer僅是self的一個屬性,這樣看來并沒有形成循環引用。

三 寫在最后

雖然這種方式沒有block簡便,但不失為一種好的方法,保存了系統的方式。喜歡用target-action方式的或者不太熟悉block的可以學一學哦,且XWWeakObject能做的不僅僅這些,XWWeakObject可以解決很多類似的循環引用問題,解決分類定義weak屬性等等

有人可能有疑問,為什么都同樣是target-action方式button就不會出現循環引用的問題,有去研究的同學應該都知道UIControl的內部做了weak操作,即真正持有的時候是weak的并沒有導致retain加1,而NSTimer由于runloop的原因并沒有做weak操作。

閑言雜語

以上內容僅代表個人想法,如果您有更好的想法,更好的解決辦法,可以一起探討。如果您覺得我的想法不錯,可以加入群639762230一起探討哦~

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容