講述Sagit.Framework解決：雙向引用導致的IOS記憶體洩漏（下）- block中任性用self
前言：
發現業務程式碼有一個地方的記憶體沒釋放，原因很也簡單：
在block裡用到了self，造成雙向引用，然後就開始思考怎麼處理這個問題。
常規則思維，就是改程式碼，block不要用到self，或只用self的弱引用。
只是框架這裡特別，有一個特好用的系列，STLastXXX系列，是用巨集定義的，而且該巨集指向了self。
這麼好用的STLastXXXX巨集定義系列，我希望它可以不受限制的到處使用。
於是開始折騰之路：
折騰一：在程式碼中重新定義巨集？
上面的程式碼，說白了就是用到了self，我們看一下巨集定義：
通常的做法，遇到block，都伴隨有WeakSelf這東東，像這樣：
STWeakSelf的預設定義：
//block塊中用的引用 #define STWeakSelf __weak typeof(self) selfWeak = self;__weak typeof(selfWeak) this = selfWeak; #define STWeakObj(o) __weak typeof(o) o##Weak = o; #define STStrongObj(o) __strong typeof(o) o = o##Weak;
說白了，巨集定義就是編繹期的文字替換遊戲，如果我在block裡的第一行程式碼，重新定義sagit這個巨集會怎樣？
比如這樣定義：
然後這麼使用：
看來是我想多，編繹都過不去。
折騰二：將巨集定義指向一個函式
比如這樣定義：
#define sagit [Sagit share].Layout
然後跑到Sagit這個類裡定義一個UIView* Layout屬性，比如這樣：
然後，就是在各個基類(STController或STView)初始化時，將自身的self.baseView賦值給它。
PS：baseView是對UIView和UIViewController擴充套件的一個屬性，都指向View。
比如：
看起來有點效果，不過，要用這種方式，還得思考的更全面：
1：架框中每個STView都是baseView。 2：STView可以無限巢狀STView。 3：因此：在STView被初時化時，設定它為baseView，載入完後，如果STView有父的STView，交還控制權，（這裡就涉及到巢狀的控制流程，如果各個子View是非同步載入，那就悲催了）。 4：沒有繼承自STView的情況呢，怎麼攔截View的開始和結束呢？（Sagit已經慢慢弱化基類的功能，多數功能都是在原生的上做擴充套件，所以不用STView，很多功能也可以正常使用）
好吧，寫這麼多，就是說這個方法是可以的，但必須考慮的更仔細好多些！！！！
而且這個方法，只是避開了self，self仍然不允許被存在。
所以，這個方法，先暫放，看看有沒有辦法，打破self的迴圈引用先。
折騰三：思考如何打破block和self的雙向引用？
block和self，互相的強引用，要打破它，總得有一方要示弱。
既然block中要允許self中存，就意味著block對self必然是強引用，辣麼就只能思考，如果讓self對block只能是弱引用了，或者沒有引用！
先來看框架的一段程式碼：
被圈起來的程式碼，實現的下列圖中圈起來的功能：
對於Sagit中，實現表格的程式碼是不是覺的很簡單，不過教程還沒寫，這裡提前洩漏了。
還是說重點，重點為UITableView中，擴充套件了一個屬性AddCell的Block屬性，見程式碼如下：
@interface UITableView(ST) #pragma mark 核心擴充套件 typedef void(^AddTableCell)(UITableViewCell *cell,NSIndexPath *indexPath); typedef BOOL(^DelTableCell)(UITableViewCell *cell,NSIndexPath *indexPath); typedef void(^AfterTableReloadData)(UITableView *tableView); //!用於為Table追加每一行的Cell @property (nonatomic,copy) AddTableCell addCell; //!用於為Table移除行的Cell @property (nonatomic,copy) DelTableCell delCell; //!用於為Table reloadData 載入完資料後觸發 @property (nonatomic,copy) AfterTableReloadData afterReload; //!獲取Table的資料來源 @property (nonatomic,strong) NSMutableArray<id> *source; //!設定Table的資料來源 -(UITableView*)source:(NSMutableArray<id> *)dataSource;
雖然定義了一個addCell屬性，但是怎麼持有，還得看getter和setter怎麼實現：
@implementation UITableView(ST) #pragma mark 核心擴充套件 -(AddTableCell)addCell { //從第三方持有返回 } -(void)setAddCell:(AddTableCell)addCell { if(addCell!=nil) { //第三方持有addCell } else { } }
如果這裡，把存檔addCell這個block存到和UITableView無關的地方去了？
用一個第三方持有block，只要這個第三方不和和self發生直接關係，那麼應該就不會有問題。
引用關係就變成：
第三方：強引用=》block
block：強引用=》self
這裡的釋放關係，第三方活著，就不會釋放block，block活著，就不會釋放self。
所以結論：還是不釋放。
也就是說，一頓程式碼寫下來，雖然解除了關係，但還是沒釋放。
如果第三方對block是弱引用呢？
為了這個實驗，我新建了一個專案，然後在這個專案上，試了整整24小時：
實驗過程沒有得到的想要的結果，但瞭解block的原理，和認清自己的邏輯誤區。
實驗的得到的知識後面再分享，這裡先繼續：
由於這裡addCell，必須始終存活，因為你不知道什麼時候，可能又要UITableView的reloadData一下。
所以，addCell這個block，必須被強引用，而且生命週期得和UITableView一致。
所以，要打破這個核心，還是得有第三方行為事件來觸發破除關係，故事就轉變成為：由self去移除第三方。
如果一定義要由某個事件來觸發解除關係，那麼第三方也沒存在的必要了。
因為正常A和B互相引用無解，是指他們互相無解，但只要有第三者存在，對其中一個置nil就解了。
最後的最後，框架的程式碼是這樣的：
-(AddTableCell)addCell { return [self key:@"addCell"]; } -(void)setAddCell:(AddTableCell)addCell { if(addCell!=nil) { addCell=[addCell copy]; [self key:@"addCell" value:addCell]; } else { [self.keyValue remove:@"addCell"]; } }
仍然是用強引用來存檔block，這裡有一個注意事項：
如果你想將一個block持久化，先copy一下，不然你會死的很慘。
好吧，讓它們互相強引用吧，剩下的事，就是誰來當這個第三方，以及怎麼解除這層關係！！！
於是，到導航欄後退事件中，攔截，並做銷燬工作：
@implementation UINavigationController (ST) #pragma mark NavigationBar 的協議，這裡觸發 // fuck shouldPopItem 方法存在時，只會觸發導航欄後退，介面檢視卻不後退。 //- (BOOL)navigationBar:(UINavigationBar *)navigationBar shouldPopItem:(UINavigationItem *)item // same as push methods //{ //// //重設上一個Controller的導航（不然在二次Push後再Pop會Crash) //// NSInteger count=self.viewControllers.count; //// if(count>0)//發現這裡返回的viewControllers，已經是移掉了當前的Controller後剩下的。 //// { //// UIViewController *preController=self.viewControllers[count-1];//獲取上一個控制器 //// if([preController needNavBar]) //// { //// [preController reSetNav:self]; //// } //// } //// // return YES; //} //返回到當前頁面 - (void)navigationBar:(UINavigationBar *)navigationBar didPopItem:(UINavigationItem *)item { // if(navigationBar!=nil && [navigationBar.lastSubView isKindOfClass:[UIButton class]]) // { // // [navigationBar.lastSubView height:0];//取消自定義覆蓋的UIButton // } NSInteger count=self.viewControllers.count; if(count>0) { UIViewController *current=self.viewControllers[count-1]; self.navigationBar.hidden=![current needNavBar]; if(self.tabBarController!=nil) { self.tabBarController.tabBar.hidden=![current needTabBar]; } //檢測上一個控制器有沒有釋放 UIViewController *nextController=current.nextController; if(nextController!=nil) { [nextController dispose]; nextController=nil; } } } -(void)dealloc { NSLog(@"UINavigationController relase -> %@", [self class]); }
Sagit框架為：每個view和controller擴充套件了dispose方法，裡面清掉鍵值對，等於把block置為nil，解除了關係。
除了導航後退，還需要攔截多一個事件，就是presentViewController的事件跳轉時，也需要檢測並銷燬。
做好這兩步之後，以後就可以輕鬆的在block裡寫self了，愛引用就引用了，反正故事的結尾，都有一個第三者來收尾。
而且強引用有一個好處：
1：再也用不上WeakSelf這種定義了。 2：由於是強引用，就不用去管：裡面還要套個StrongSelf，去避開多執行緒時，self可能被移除時帶來的閃退問題。
最後：吐槽一個IOS的另一個坑，又是神祕的dealloc方法：
上一篇文章，講到，如果對UIView擴充套件了dealloc這方法，引發的命案是：
導航欄：二次後退就閃退。
這一篇，又被我發現，如果對UIViewController擴充套件dealloc這個方法，引發的命案：
UIAlertView：當alertViewStyle設定為帶文字框時就閃退。
給大夥上一個圖，先把dealloc開啟：
然後執行的效果：
坑吧，好在有上一次的經驗，趕緊新建了一個專案，然後用程式碼排除法，最終還是排到dealloc這裡來。
看到這文章的同學，你們又可以去忽悠同事了。
總結：
整體折騰完記憶體釋放問題後，Sagit框架也高效了很多，也許是錯覺。
IT連的創業的也在繼續，歡迎大夥持續關注，謝謝！