前言：
在處理完框架內存泄漏的問題后，見上篇：講述Sagit.Framework解決：雙向引用導致的IOS內存泄漏（中）- IOS不為人知的Bug
發現業務代碼有一個地方的內存沒釋放，原因很也簡單：
在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連的創業的也在繼續，歡迎大伙持續關注，謝謝！