什么時候在 block 中不需要使用 weakSelf
我們知道，在使用 block 的時候，為了避免產生循環(huán)引用，通常需要使用 weakSelf 與 strongSelf，寫下面這樣的代碼：
__weak typeof(self) weakSelf = self;
[self doSomeBlockJob:^{
__strong typeof(weakSelf) strongSelf = weakSelf;
if (strongSelf) {
...
}
}];
那么請問：什么時候在 block 里面用 self，不需要使用 weak self？
當 block 本身不被 self 持有，而被別的對象持有，同時不產生循環(huán)引用的時候，就不需要使用 weak self 了。最常見的代碼就是 UIView 的動畫代碼，我們在使用 UIView 的
animateWithDuration:animations方法 做動畫的時候，并不需要使用 weak self，因為引用持有關系是：
- UIView 的某個負責動畫的對象持有了 block
- block 持有了 self
因為 self 并不持有 block，所以就沒有循環(huán)引用產生，因為就不需要使用 weak self 了。
[UIView animateWithDuration:0.2 animations:^{
self.alpha = 1;
}];
當動畫結束時，UIView 會結束持有這個 block，如果沒有別的對象持有 block 的話，block 對象就會釋放掉，從而 block 會釋放掉對于 self 的持有。整個內存引用關系被解除。
為什么 weakSelf 需要配合 strong self 使用
我們知道，在使用 block 的時候，為了避免產生循環(huán)引用，通常需要使用 weakSelf 與 strongSelf，寫下面這樣的代碼：
__weak typeof(self) weakSelf = self;
[self doSomeBlockJob:^{
__strong typeof(weakSelf) strongSelf = weakSelf;
if (strongSelf) {
...
}
}];
為什么 block 里面還需要寫一個 strong self，如果不寫會怎么樣？
在 block 中先寫一個 strong self，其實是為了避免在 block 的執(zhí)行過程中，突然出現 self 被釋放的尷尬情況。通常情況下，如果不這么做的話，還是很容易出現一些奇怪的邏輯，甚至閃退。
我們以 AFNetworking 中
AFNetworkReachabilityManager.m的一段代碼舉例：
__weak __typeof(self)weakSelf = self;
AFNetworkReachabilityStatusBlock callback = ^(AFNetworkReachabilityStatus status) {
__strong __typeof(weakSelf)strongSelf = weakSelf;
strongSelf.networkReachabilityStatus = status;
if (strongSelf.networkReachabilityStatusBlock) {
strongSelf.networkReachabilityStatusBlock(status);
}
};
如果沒有 strongSelf 的那行代碼，那么后面的每一行代碼執(zhí)行時，self 都可能被釋放掉了，這樣很可能造成邏輯異常。
特別是當我們正在執(zhí)行 strongSelf.networkReachabilityStatusBlock(status); 這個 block 閉包時，如果這個 block 執(zhí)行到一半時 self 釋放，那么多半情況下會 Crash。
block 什么時候需要構造循環(huán)引用
有沒有這樣一個需求場景，block 會產生循環(huán)引用，但是業(yè)務又需要你不能使用 weak self? 如果有，請舉一個例子并且解釋這種情況下如何解決循環(huán)引用問題。
需要不使用 weak self 的場景是：你需要構造一個循環(huán)引用，以便保證引用雙方都存在。比如你有一個后臺的任務，希望任務執(zhí)行完后，通知另外一個實例。在我們開源的 YTKNetwork 網絡庫的源碼中，就有這樣的場景。
在 YTKNetwork 庫中，我們的每一個網絡請求 API 會持有回調的 block，回調的 block 會持有 self，而如果 self 也持有網絡請求 API 的話，我們就構造了一個循環(huán)引用。雖然我們構造出了循環(huán)引用，但是因為在網絡請求結束時，網絡請求 API 會主動釋放對 block 的持有，因此，整個循環(huán)鏈條被解開，循環(huán)引用就被打破了，所以不會有內存泄漏問題。代碼其實很簡單，如下所示：
// YTKBaseRequest.m
- (void)clearCompletionBlock {
// nil out to break the retain cycle.
self.successCompletionBlock = nil;
self.failureCompletionBlock = nil;
}
總結來說，解決循環(huán)引用問題主要有兩個辦法：
- 第一個辦法是「事前避免」，我們在會產生循環(huán)引用的地方使用 weak 弱引用，以避免產生循環(huán)引用。
- 第二個辦法是「事后補救」，我們明確知道會存在循環(huán)引用，但是我們在合理的位置主動斷開環(huán)中的一個引用，使得對象得以回收。
weak 的內部實現原理
weak 變量在引用計數為0時，會被自動設置成 nil，這個特性是如何實現的？
在 Friday QA 上，有一期專門介紹 weak 的實現原理。https://mikeash.com/pyblog/friday-qa-2010-07-16-zeroing-weak-references-in-objective-c.html
《Objective-C高級編程》一書中也介紹了相關的內容。
簡單來說，系統(tǒng)有一個全局的 CFMutableDictionary 實例，來保存每個對象的 weak 指針列表，因為每個對象可能有多個 weak 指針，所以這個實例的值是 CFMutableSet 類型。
剩下我們要做的，就是在引用計數變成 0 的時候，去這個全局的字典里面，找到所有的 weak 指針，將其值設置成 nil。如何做到這一點呢？Friday QA 上介紹了一種類似 KVO 實現的方式。當對象存在 weak 指針時，我們可以將這個實例指向一個新創(chuàng)建的子類，然后修改這個子類的 release 方法，在 release 方法中，去從全局的
CFMutableDictionary字典中找到所有的 weak 對象，并且設置成 nil。我摘抄了 Friday QA 上的實現的核心代碼，如下：
Class subclass = objc_allocateClassPair(class, newNameC, 0);
Method release = class_getInstanceMethod(class, @selector(release));
Method dealloc = class_getInstanceMethod(class, @selector(dealloc));
class_addMethod(subclass, @selector(release), (IMP)CustomSubclassRelease, method_getTypeEncoding(release));
class_addMethod(subclass, @selector(dealloc), (IMP)CustomSubclassDealloc, method_getTypeEncoding(dealloc));
objc_registerClassPair(subclass);
當然，這并不代表蘋果官方是這么實現的，因為蘋果的這部分代碼并沒有開源。《Objective-C高級編程》一書中介紹了 GNUStep 項目中的開源代碼，思想也是類似的。所以我認為雖然實現細節(jié)會有差異，但是大致的實現思路應該差別不大。
備注:本文摘自IOS開發(fā)by唐巧->block的使用，略有刪改,僅供學習使用。
