block系列
在 ARC 下，當 block 獲取到外部變量時，由于編譯器無法預測獲取到的變量何時會被突然釋放，為了保證程序能夠正確運行，讓 block 持有獲取到的變量，向系統顯明：我要用它，你們千萬別把它回收了！然而，也正因 block 持有了變量，容易導致變量和 block 的循環引用，造成內存泄露！
對于 block 中的循環引用通常有兩種解決方法:
1、將對象置為 nil ，消除引用，打破循環引用；
（這種做法有個很明顯的缺點，即開發者必須保證 _networkFetecher = nil; 運行過。若不如此，就無法打破循環引用。
但這種做法的使用場景也很明顯，由于 block 的內存必須等待持有它的對象被置為 nil 后才會釋放。所以如果開發者希望自己控制 block 對象的生命周期時，就可以使用這種方法。）
2、將強引用轉換成弱引用，打破循環引用；
（__weak __typeof(self) weakSelf = self;如果想防止 weakSelf 被釋放，可以再次強引用 __typeof(&weakSelf) strongSelf = weakSelf;代碼 __typeof(&weakSelf) strongSelf 括號內為什么要加 &* 呢？主要是為了兼容早期的 LLVM
block 的內存泄露問題包括自定義的 block，系統框架的 block 如 GCD 等，都需要注意循環引用的問題。
有個值得一提的細節是，在種類眾多的 block 當中，方法名帶有 usingBlock 的 Cocoa Framework 方法或 GCD 的 API ，如
- enumerateObjectsUsingBlock:
- sortUsingComparator:
這一類 API 同樣會有循環引用的隱患，但原因并非編譯器做了保留，而是 API 本身會對傳入的 block 做一個復制的操作。
delegate系列
@property (nonatomic, weak) id delegate;
說白了就是循環使用的問題，假如我們是寫的strong,那么 兩個類之間調用代理就是這樣的啦
BViewController *bViewController = [[BViewController alloc] init];
bViewController.delegate = self; //假設 self 是AViewController
[self.navigationController pushViewController:bViewController animated:YES];
/**
假如是 strong 的情況
bViewController.delegate ===> AViewController (也就是 A 的引用計數 + 1)
AViewController 本身又是引用了 ===> delegate 引用計數 + 1
導致： AViewController Delegate ，也就循環引用啦
*/
Delegate創建并強引用了 AViewController；(strong ==> A 強引用、weak ==> 引用計數不變)
所以用 strong的情況下，相當于 Delegate 和 A 兩個互相引用啦，A 永遠會有一個引用計數 1 不會被釋放，所以造成了永遠不能被內存釋放，因此weak是必須的。
performSelector 系列
performSelector 顧名思義即在運行時執行一個 selector，最簡單的方法如下
- (id)performSelector:(SEL)selector;
這種調用 selector 的方法和直接調用 selector 基本等效，執行效果相同
[object methodName];
[object performSelector:@selector(methodName)];
但 performSelector 相比直接調用更加靈活
SEL selector;
if (/* some condition */) {
selector = @selector(newObject);
} else if (/* some other condition */) {
selector = @selector(copy);
} else {
selector = @selector(someProperty);
}
id ret = [object performSelector:selector];
這段代碼就相當于在動態之上再動態綁定。在 ARC 下編譯這段代碼，編譯器會發出警告
warning: performSelector may cause a leak because its selector is unknow [-Warc-performSelector-leak]
正是由于動態，編譯器不知道即將調用的 selector 是什么，不了解方法簽名和返回值，甚至是否有返回值都不懂，所以編譯器無法用 ARC 的內存管理規則來判斷返回值是否應該釋放。因此，ARC 采用了比較謹慎的做法，不添加釋放操作，即在方法返回對象時就可能將其持有，從而可能導致內存泄露。
以本段代碼為例，前兩種情況（newObject, copy）都需要再次釋放，而第三種情況不需要。這種泄露隱藏得如此之深，以至于使用 static analyzer 都很難檢測到。如果把代碼的最后一行改成
[object performSelector:selector];
不創建一個返回值變量測試分析，簡直難以想象這里居然會出現內存問題。所以如果你使用的 selector 有返回值，一定要處理掉。
還有一種情況就是performSelector的延時調用[self performSelector:@selector(method1:) withObject:self.myView afterDelay:5];，performSelector關于內存管理的執行原理是這樣的，當執行[self performSelector:@selector(method1:) withObject:self.myView afterDelay:5];的時候，系統將myView的引用計數加1，執行完這個方法之后將myView的引用計數減1，而在延遲調用的過程中很可能就會出現，這個方法被調用了，但是沒有執行，此時myView的引用計數并沒有減少到0，也就導致了切換場景的dealloc方法沒有被調用，這也就引起了內存泄漏。
NSTimer
NSTimer會造成循環引用，timer會強引用target即self，在加入runloop的操作中，又引用了timer，所以在timer被invalidate之前，self也就不會被釋放。
所以我們要注意，不僅僅是把timer當作實例變量的時候會造成循環引用，只要申請了timer，加入了runloop，并且target是self，雖然不是循環引用，但是self卻沒有釋放的時機。如下方式申請的定時器，self已經無法釋放了。
NSTimer *timer = [NSTimer timerWithTimeInterval:5 target:self selector:@selector(commentAnimation) userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];
解決這種問題有幾個實現方式，大家可以根據具體場景去選擇：
增加startTimer和stopTimer方法，在合適的時機去調用，比如可以在viewDidDisappear時stopTimer，或者由這個類的調用者去設置。
每次任務結束時使用dispatch_after方法做延時操作。注意使用weakself，否則也會強引用self。
- (void)startAnimation
{
WS(weakSelf);
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
[weakSelf commentAnimation];
});
}
使用GCD的定時器，同樣注意使用weakself。
WS(weakSelf);
timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, dispatch_get_main_queue());
dispatch_source_set_timer(timer, DISPATCH_TIME_NOW, 5 * NSEC_PER_SEC, 1 * NSEC_PER_SEC);
dispatch_source_set_event_handler(timer, ^{
[weakSelf commentAnimation];
});
dispatch_resume(timer);
