關於自定義tabBar時修改系統自帶tabBarItem屬性造成的按鈕順序錯亂的問題相關探究

測試代碼:http://git.oschina.net/Xiyue/TabBarItem_TEST

簡書地址:http://www.jianshu.com/users/f599d56f0592/latest_articles

---

序引

現在的主流框架中,在通常情況下,tabBar的屬性一般都在tabBarController中全局設定好,且設定后一般就不會去改動.此外,現在絕大部分的App中,tabBar都會自定義,重寫 layoutSubviews 方法以實現重新布局Item. 例如:

- (void)layoutSubviews{
[super layoutSubviews];

        CGFloat btnX = 0;
        CGFloat btnY = 0;
        CGFloat btnW = self.frame.size.width / 5;
        CGFloat btnH = self.frame.size.height;

        NSInteger index = 0;
        // 遍歷子控件
        for (UIView *tabBarButton in self.subviews) {
            if ([tabBarButton isKindOfClass:NSClassFromString(@"UITabBarButton")]) {
                if (index == 2) {
                    index += 1;
                }

                btnX = index * btnW;
                tabBarButton.frame = CGRectMake(btnX, btnY, btnW, btnH);

                index++;
            }
        }
}

 

但是,在這種情況下,如果存在需要tabBarController的子控制器中修改tabBarItem的屬性的情況,那么會發生一些意外的問題.什么問題呢,我們看圖:

  

Snip20160719_9.png

Snip20160719_11.png

---

問題提出

有沒有發現tabBarController中設置子控制器的順序與運行顯示的結果不一樣?我們設置的第一個控制器莫名奇妙跑到最后一個去了,但是在程序啟動后,默認顯示在window上的依然是第一個 "我"這個控制器的view.也就是說: selectedViewController沒有變,是默認tabBarController中設定子控制的順序的第1個(childViewControllers[0]).但是該子控制器所綁定的tabBarItem所在的位置卻發生了變化.

---

原因查找

什么原因引起的變化?測試發現,這個一個組合拳的效果:

• 條件 1:自定義tabBar並重寫 layoutSubviews 方法 並且 自定義布局;如果沒有重寫layoutSubviews方法,也不會出現此問題;
• 條件 2:修改系統自帶tabBarItem的屬性,以下對常用屬性舉例:
  • 2.1 title(tabBarItem.title)這個屬性如果修改的title與tabBarController中設定的title一致,不會發生此現象;修改為不一樣才能發生此現象.
  • 2.2 image及selectedImage及TitleTextAttributes及TitleTextAttributes等涉及狀態類的屬性,不管與先前的屬性是否相同,全部會發生此現象.特別是TitleTextAttributes,就算你傳進去的是一個空的字典,依然會造成此現象.

Snip20160719_12.png

---

探究

OK,既然重寫 layoutSubviews 方法 並且 自定義布局 會發生此狀況,而 重寫但不自定義布局 卻不會發生此狀況,那么我們就從這里入手深入探究一下原因好了.
以下是我自己寫的一些簡單的輸出Item的代碼,因為UITabBarButton是私有控件,我們沒辦法查看內部的屬性及實現邏輯,只能從一些蛛絲馬跡上探究端倪了:

- (void)layoutSubviews{
    for (UIView *tabBarButton in self.subviews) {
        if ([tabBarButton isKindOfClass:NSClassFromString(@"UITabBarButton")]) {
            NSLog(@"%@",tabBarButton);
        }
    }
     NSLog(@"---------------------------------------------");
    [super layoutSubviews];

        CGFloat btnX = 0;
        CGFloat btnY = 0;

        CGFloat btnW = self.frame.size.width / 5;
        CGFloat btnH = self.frame.size.height;
        NSInteger index = 0;
        // 遍歷子控件
        for (UIView *tabBarButton in self.subviews) {
            if ([tabBarButton isKindOfClass:NSClassFromString(@"UITabBarButton")]) {
                NSLog(@"%@",tabBarButton);
                if (index == 2) {
                    index += 1;
                }

                btnX = index * btnW;

                tabBarButton.frame = CGRectMake(btnX, btnY, btnW, btnH);

                index++;
            }
        }
    NSLog(@"----------------------------------------------");
    for (UIView *tabBarButton in self.subviews) {
        if ([tabBarButton isKindOfClass:NSClassFromString(@"UITabBarButton")]) {
            NSLog(@"%@",tabBarButton);
        }
    }
    NSLog(@"==============================================");
}

 

以下是打印結果:

Snip20160719_13.png

為了方便說明,在截圖中區分了ABCDEF六大區域,1-6留個標注frame變化點.
另外說明:
第一個等號(=)分割線之前的所有輸出都是第一次來到 layoutSubviews 方法的打印結果;
第一個等號(=)分割線之后的所有輸出都是修改tabBarItem屬性后再次來到 layoutSubviews 方法的打印結果;
第一個減號(-)分割線前是[super layoutSubviews] 之前的打印結果;
第二個減號(-)分割線前是[super layoutSubviews] 之后,自定義布局前的的打印結果;
第二個減號(-)分割線后是自定義布局后的的打印結果.

• 首先 從A與B兩個區域中,由標簽1及標簽2可以看出,系統默認的第一個UITabBarButton(系統的tabBarItem 類型為UITabBarButton類型)的位置坐標(origin)為(2,1),第一次自定義布局后變為(0,0),此時的這個UITabBarButton就是第一個子控制器('我')對應的tabBarItem,它的內存地址是:0x7fab39530010.(其他的內存地址也看一下,先有個印象,后面比較時會用上.layer層的內存地址也是一個比較依據.)
• 其次 再看C和D兩個區域看出,從標簽3 4 5看出:
  • 修改了tabBarItem的屬性后再次來到此方法時,已經找不到0x7fab39530010這個內存地址,而是多了一個0x7fab3961fc50內存地址,且是在tabBar.subviews數組的最后.layer層內存地址也是一樣現象.
  • 0x7fab39530010這個的frame是未進行第一次自定義布局前的frame.
  • 觀察其他tabBarItem的內存地址均未發生任何變化.layer層內存地址同樣如此.
  • 注意看紅色箭頭,不要被綠色標簽6誤導,它的內存地址顯示它是原本tabBar.subviews中的第二個元素.
• 再次 從BD兩個區域可以看出,第一次自定義布局完畢后與第二次自定義布局開始時的tabBar.subviews的frame已經不一樣,但是內存地址上看卻是,除去我們改變了屬性的那個tabBarItem的內存地址不一樣外,其他的全部一樣.

---

猜想

鑒於tabBar為私有控件,無法查看內部的代碼邏輯,再次對上述的一些顯現進行猜想分析:

• A: tabBar內部會對屬性進行set方法過濾,其中包括檢查即將修改的屬性與之前是否一致(除去state相關的,或者說state相關的都無法通過此過濾)
  因此才會出現當改變title屬性如果與tabBarController設定時的一致時不會出現此種情況的原因.邏輯內部如果通過了過濾,就執行某個處理,而這個處理就是造成這個現象的元凶
• B>而這個元凶到底是什么呢?從前面的分析及截圖中可以大概知道:雖然內存地址改變,但是指向的對象卻是一個與先前屬性完全相同的對象.這其實是 深拷貝 的套路對不對
  那么為什么當改變title屬性如果與tabBarController設定時的一致時不會出現此種情況的原因呢,既然有深拷貝,是不是對應的應該有淺拷貝?我們看下圖就知道了.

Snip20160719_15.png

由圖中可以看出,當修改的屬性內容與控制器設定的一樣(即:self.title = @"我";)時,全程的內存地址都是一樣的,沒有發生任何變化,僅僅是frame中途發生了一些改變,變回了系統默認的.
那么:我們是否可以猜想:
1 : 事實上,每次layoutSubviews,系統內部的默認(注意 '默認' 這個關鍵字)做法是 淺拷貝 系統默認(childViewControllers順序)的tabBarItem后重新計算frame,這是在[super layoutSubviews]中進行的; 
2 :當對tabBarItem的一些屬性進行修改時,就會執行set方法中的過濾;
(a)如果要修改成的屬性與當前的完全一致(除去state相關的,或者說state相關的都無法通過此過濾)時,就是 淺拷貝 ,(也就是默認情況);
(b)當要修改成的屬性與當前的完全不一致時,就是執行過濾后的邏輯,即 深拷貝;這就解釋了為什么當修改某些屬性時造成的原先的對象內存地址找不到了而是出現了另外一個新的內存地址,因為該tabBarItem指向的內存地址變成了指向深拷貝出來的那個對象的地址

• C : 至於為什么數組的順序發生了改變呢,這個在我想過好多,以下是認為最大可能的一種想法:
  未發生屬性改變的tabBarItem淺拷貝一份地址后當做Subviews的基礎數組,然后A深拷貝一份修改完數據后得到的新的數組A_new地址加到數組中,這樣就排在了最后一個位置,但是childViewControllers的順序沒有改變,所以selectedViewController依然是A實例,因此發生程序啟動后顯示的是排在最后的tabBarItem所對應的控制器的view.如下圖所示.

Snip20160719_17.png

最后,如果有多個tabBarItem的屬性被修改,那么修改的先后順序也是tabBarController控制器中設定子控制器時的順序.
以上均屬個人推測,系統內部做了什么只有蘋果官方知道,如有錯誤還望指正.

code: @XiYue on git.oschina.net.