講述Sagit.Framework解決：雙向引用導致的IOS記憶體流失（下）- block中任性用self，sagit.frameworkios

講述Sagit.Framework解決：雙向引用導致的IOS記憶體流失（下）- block中任性用self，sagit.frameworkios
前言：

在處理完架構記憶體流失的問題後，見上篇：講述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發生直接關係，那麼應該就不會有問題。

參考關聯性就變成：

第三方：強引用=》blockblock：強引用=》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連的創業的也在繼續，歡迎大夥持續關注，謝謝！