講述Sagit.Framework解決：雙向引用導致的IOS記憶體流失（中）- IOS不為人知的Bug，sagit.frameworkios

講述Sagit.Framework解決：雙向引用導致的IOS記憶體流失（中）- IOS不為人知的Bug，sagit.frameworkios
前言：

話說昨晚還是前晚，寫了一篇：講述Sagit.Framework解決：雙向引用導致的IOS記憶體流失（上）

文章寫到最後時，多了很多莫名奇妙的問題！！！

為瞭解決了這些莫名奇妙的問題，我又戰鬥了24小時〜〜〜

然後終於解決了問題，原來是IOS的隱藏性Bug，只想恨恨的說一聲fuck~~~

故事起源：

故事是這樣的，為了處理記憶體釋放的問題，正常人的思維，都是給對象的dealloc增加日誌輸出。

於是，UIView、UIViewController和兩個Sagit定義的基類STView、STController，自然而然就加上了這麼一行代碼：

-(void)dealloc{    NSLog(@"UIView relase -> %@", [self class]);}

然後就通過輸出的日誌，觀察該方法被執行與否，來確認對象是否正常被釋放。

在各種強引用、弱引用、循環參考、先強後弱引用的坑裡跳來跳去後，終於祭出了完美的殺招，來處理這些問題：

-(id)key:(NSString *)key{    id value=[self.keyValue get:key];    if(value==nil)    {        value=[self.keyValueWeak get:key];    }    return value;}-(UIView*)key:(NSString *)key valueWeak:(id)value{    [self.keyValueWeak set:key value:value];    return self;}-(UIView*)key:(NSString *)key value:(id)value{    [self.keyValue set:key value:value];    return self;}-(NSMapTable*)keyValueWeak{    NSMapTable *kv=[self.keyValue get:@"keyValueWeak"];    if(kv==nil)    {        kv=[NSMapTable mapTableWithKeyOptions:NSMapTableWeakMemory valueOptions:NSMapTableWeakMemory];        [self.keyValue set:@"keyValueWeak" value:kv];    }    return kv;//    NSMapTable *kv= (NSMapTable*)objc_getAssociatedObject(self, &keyValueWeakChar);//    if(kv==nil)//    {//        kv=[NSMapTable mapTableWithKeyOptions:NSMapTableWeakMemory valueOptions:NSMapTableWeakMemory];//        objc_setAssociatedObject(self, &keyValueWeakChar, kv,OBJC_ASSOCIATION_RETAIN);//    }//    return kv;}-(NSMutableDictionary<NSString*,id>*)keyValue{    NSMutableDictionary<NSString*,id> *kv= (NSMutableDictionary<NSString*,id>*)objc_getAssociatedObject(self, &keyValueChar);    if(kv==nil)    {        kv=[NSMutableDictionary<NSString*,id> new];        objc_setAssociatedObject(self, &keyValueChar, kv,OBJC_ASSOCIATION_RETAIN);    }    return kv;}

通過在強引用的Dictionary裡，儲存一個弱引用NSTableMap，來存檔一些需要弱引用的對象，比如View或Controller等對象。

正當我在思索上面的解法的時候：另一個要命的導覽列Crash問題也出現了，而且在以下三種情形都會Crash掉：

導覽列命案一：回退即Crash

 一開始是通過導覽列回退看日誌輸出，結果卻動不動給我來這個：

關鍵還什麼全域斷點、僵使對象等方法都無效，只能靠猜〜〜〜〜〜

處理這個問題呢，還好，我是把代碼折半注釋，最後定位到：

圈起來的代碼，是為每一個UI，都增加兩個屬性，前一個UI和後一個UI。

解決也很簡單，用弱引用存檔就好了（這個時候，強弱引用的問題已經被我完美解決了）：

// Name- (UIView*)preView{    return [self key:@"preView"];}- (UIView*)preView:(UIView*)view{    return [self key:@"preView" valueWeak:view];}- (UIView*)nextView{    return [self key:@"nextView"];}- (UIView*)nextView:(UIView*)view{    return [self key:@"nextView" valueWeak:view];}

導覽列命案2：回退兩次即Crash

上一次是引用問題，這一次呢？我X，錯誤的提示，還是和一樣，一個main含數裡讓你猜〜〜〜〜〜

而且一級就正常，二級就掛給你看〜〜〜真不要臉。

然後，就是針對這種靈異事件，各種渡，發現全世界都沒出現我這個問題〜〜〜〜這真神了去了。

然後又開始注釋代碼，神奇的發現，在彈回後退時，如果把上一個狀態列給重新設定一遍，即不會出現Crash現象。

所以，我是這麼思考導覽列問題的：

    1: 一個navigationCtroller只有一個navigationBar。    2: 每一個viewController，都會複寫前一個navigationBar。    3: 所以，到下一層時，UINavigationBar指向最後一個Controller    4: 當回退時，最後一個Controller被釋放後，navigationBar沒有被重繪的話，事件指向就會出問題。

然後又開始著手儲存目前狀態，然後後退時還原狀態這條路。

由於後退是自訂事件，所以可以在事件裡加代碼還原，但是如果是滑動返回呢？

千身萬苦之後，找到：shouldPopItem，在這裡可以做點事情：

@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.navigationBar.isHidden)//        {//            [current reSetNav:self];//        }        if(self.tabBarController!=nil)        {            self.tabBarController.tabBar.hidden=![current needTabBar];        }    }}-(void)dealloc{    NSLog(@"UINavigationController relase -> %@", [self class]);}@end

改完之後，發現一切又正常了，然後，又迎來了導覽列的第3波bug。

（PS：shouldPopItem 這個方法，是第二個超級Bug坑）

導覽列命案3：第一個頁面存在自訂按鈕，則Crash

以下這個介面，右上方一個小相機事件。

因為解決問題2的代碼中，並沒有還原第一個頁的導覽列，所以事故還是發生了。

然後又思考，這預設的第一個頁面狀態怎麼儲存？

直接儲存整個UIButtonBar或者整個NavigationBar，再還原，竟然不行！！！

簡直欲哭無淚，各種渡，仍無果，為啥全世界，都沒這種問題呢？

難道全世界寫代碼都是記憶體不釋放，所以木有這個問題？

這麼基礎的問題，不是到處都會遇到的嗎？

然後到了隔壁小夥的電腦上，把這種神奇的故事，在他電腦上重新示範了一遍！！！

果然還是和我電腦上的一樣！！！

果然這問題還是很常見，為啥呢，渡不出果呢？

不知道為什麼，作為一名新手，他跑去把這段代碼給注釋了：

//fuck dealloc 方法存在時，會影響導航的後退事件Crash，以下兩種情況：1:當前UI有自訂導覽按鈕時；2:Push兩層再回退。//-(void)dealloc//{////    if(self.gestureRecognizers.count>0)////    {////        if(self.gestureRecognizers!=nil)////        {////            for (NSInteger i=self.gestureRecognizers.count-1; i>=0; i--)////            {////                [self removeGestureRecognizer:self.gestureRecognizers[i]];////            }////        }////    }//    //[self.keyValueWeak removeAllObjects];//  //  [self.keyValue removeAllObjects];////    NSLog(@"UIView relase -> %@ name:%@", [self class],self.name);//}

然後，一切正常了〜〜〜〜咦！！！！

是dealloc裡的代碼有問題引發的？

然後內部代碼全注釋掉了，問題還是有！！！

把dealloc整個注釋掉，又正常了！！！

真相：IOS的Bug，不能擴充UIView的dealloc方法

到了這裡，真相終於出來了，只要擴充了UIView的dealloc方法，導覽列就敢死給你看！！！

我了個去，為了查記憶體釋放，所以要寫dealloc方法，但寫了這個方法，就引出來這麼多神奇的靈異事件。 

無語啊，這是為了讓我們不要管記憶體釋放問題，故意設下的坑麼。

IOS除了這個Bug，還有那個shouldPopItem事件，只要這個事件存在，預設return YES，就只返回導航頭，不會返回介面，也是個坑！！！

效果是這樣的：

總結：

真是人算不如天算，遇到這種坑，也是全宇宙第一人了。

這裡給大夥提供一個坑隊友的的新方法：

找個地方，對UIView擴充一個dealloc空方法。

然後就說這Bug很神奇，讓他幫忙看看，包對方頭大兩尺三〜〜〜

本來記憶體流失的問題，到此篇就結束的，不過還有一個任性的問題想解決：

希望在block裡，任性的寫self，也不會造成記憶體匯漏問題。

又經過48小時的奮戰，終於解決了。

同時又發現另一個IOS的坑，好吧，只好把此文改成中，準備再來一篇下。