在處理完框架記憶體泄漏的問題後，發現業務代碼有一個地方的記憶體沒釋放，原因很也簡單：block和self互相強引用了，接下來。。。。。。 ...

前言：

在處理完框架記憶體泄漏的問題後，見上篇：講述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連的創業的也在繼續，歡迎大伙持續關註，謝謝！

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

前言：