引
先前一段時間,就職于國內某知名創業公司的HF在重構歷史代碼的時候向我吐槽到:NStimer這個東西真的有那么麻煩么?
我:what?
HF:歷史遺留代碼中很多NSTimer的錯誤,說白了就是大量的循環引用導致不進入dealloc
我:額..可能忘了吧,習慣不太好.
HF:要不咱們來想個辦法,一來解決習慣不好/忘了等原因導致的循環引用.二來解決歷史遺留問題更方便.
我:好
開始
HF很快擼好了一個自定義的timer,內部target做了weak引用.循環引用的問題解決.然后達到了我們的目的了么?似乎沒有.
- 侵入性.這點在解決歷史遺留問題顯得比較嚴重,會大面積的修改
NSTimer為HFTimer.假設遇上一些類型檢測,可能會導致未知的問題. - 往深入的想,既然timer不retain target,那么當target釋放的時候,timer也就沒辦法執行action了,那么一旦因為各種原因忘了
inValidate,豈不是就crash了,似乎沒那么安全.
于是我們期望有一個東西,最好是timer的某個屬性,設置了以后,就可以不用retain target.并且是安全的,意味著當target釋放后,timer能夠感知并且自動的inValidate.
HFPrettyTimer
最終有HFPrettyTimer這個東西,看似黑魔法,實際上代碼也就一點點.
首先它的直觀感受是這樣的:
@PrettyTimer(self)
self.timer = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(test) userInfo:nil repeats:YES];
是的,然后就沒有然后了.只是一個宏定義而已.只要調用了這個宏,timer將不會retain target,并且會在target釋放的時候自動的停止(inValidate).當然,手動調用停止也沒問題.
并且,在一個方法的作作用域內,timer均有效,而非屬性,每個實例都要設置一次.出了作用域,則無效.例如:
- (IBAction)startTimer:(id)sender {
@PrettyTimer(self)
self.timer = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(changeNumber) userInfo:nil repeats:YES];
self.timer1 = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(changeNumber1) userInfo:nil repeats:YES];
}
Swizzle
顯而易見,沒有繼承timer,沒有新的類,沒有新的屬性.那么分類/繼承/重寫是沒辦法做到的.那么只能通過交換來做到了.
在HFPrettyTimer中,交換了除了init以外的其余新建NSTimer實例的方法.
交換的目的在于,將傳入的target weak化,雖然NSTimer必然會retain target,但是通過交換,我們有能力決定retain的target是哪一個target.
weak化是一個比較常見的技巧,YYKit里面也經常使用到.通過weak屬性切斷循環引用,通過方法轉發進行消息傳遞:
@interface HFWeakensTarget : NSObject
@property (nonatomic, weak) id target;
+ (HFWeakensTarget *)weakensTarget:(id)target;
@end
@implementation HFWeakensTarget
+ (HFWeakensTarget *)weakensTarget:(id)target {
HFWeakensTarget *weakens = [HFWeakensTarget new];
weakens.target = target;
return weakens;
}
- (BOOL)respondsToSelector:(SEL)aSelector {
return [self.target respondsToSelector:aSelector];
}
- (id)forwardingTargetForSelector:(SEL)aSelector {
return self.target;
}
- (Class)class {
return [self.target class];
}
- (BOOL)isKindOfClass:(Class)aClass {
return [self.target isKindOfClass:aClass];
}
- (BOOL)isMemberOfClass:(Class)aClass {
return [self.target isMemberOfClass:aClass];
}
- (BOOL)conformsToProtocol:(Protocol *)aProtocol {
return [self.target conformsToProtocol:aProtocol];
}
- (NSString *)description {
return [self.target description];
}
@end
切斷循環引用比較簡單,那么就即將進入第二步:感知target的釋放,在target釋放的時候inValidate.
Dealloc通知
釋放必然和dealloc打交道.所以對于這個問題,第一反應是,要不咱們把dealloc交換了?
額..這種NSObject的基礎中的基礎方法,危險性暫且不說.就為了做timer的這個需求,每個dealoc中都要進行判斷,本身效率上也無法接受.
想了想,只能充分利用ARC的特性.當一個Object釋放的時候,它身上的所有Object正常狀態下都會釋放.target我們無法控制,那能否讓一個我們能控制的東西和target產生聯系呢.
于是一個大家用爛了的東西出場:objc_setAssociatedObject
通過掛載一個自己的Object到target上,當target釋放后,自己的Object也同樣會釋放,通過自己的Object的dealloc方法,就能知道target的釋放了.
詳見源碼中:HFDeallocDetector文件.
交換標記
因為交換是針對于所有的NSTimer,這樣勢必會影響到iOS系統的使用和歷史代碼的使用,風險非常大.所以需要做個標記,當有這個標記的時候,才進行以上的邏輯.否則仍然是原聲NSTimer的邏輯.
還是objc_setAssociatedObject出場,給target設置一個對象.當檢測到這個對象的時候,則認為被標記,執行交換等操作,否則不執行.
對象的key只能盡量保證不沖突,但無法百分百保證.所以這里使用了一個MD5碼.
char *const HFWeakenIdentifier = "57fb44e903ebfc31d01d568fbbb2006b"; //handsomeCharles :)
作用域
基本上成型了,最后考慮到一個問題.因為給一個target打上了標記,那么一定需要刪除這個標記,在什么時候刪除呢?是使用后(通過標記判斷后)就刪除嗎?
可以,但是不太方便.假設有2個timer呢?所以希望是作用于完了之后刪除.遇是想到了sunny大介紹的神器:__attribute__((cleanup()))
于是有了PrettyTimer這個宏(宏是真寫的少,請原諒寫的low):
#define PrettyTimer(x)\
autoreleasepool {}\
__strong NSObject *strongX __attribute__((cleanup(removeWeakenIdentifier))) = x;\
objc_setAssociatedObject(strongX, HFWeakenIdentifier, @"", OBJC_ASSOCIATION_COPY_NONATOMIC);\
至于autoreleasepool,純粹想學RAC裝一下...
完結
經過一番調試,然后就完結了.
可以查看HF的github,read me就別管了...本來說用我蹩腳的英文寫一個,最近太忙.只能稍后了.
