關於自訂tabBar時修改系統內建tabBarItem屬性造成的按鈕順序錯亂的問題相關探究，tabbartabbaritem

關於自訂tabBar時修改系統內建tabBarItem屬性造成的按鈕順序錯亂的問題相關探究，tabbartabbaritem
 關於自訂tabBar時修改系統內建tabBarItem屬性造成的按鈕順序錯亂的問題相關探究

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

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

序引

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

 1 - (void)layoutSubviews{ 2 [super layoutSubviews]; 3  4         CGFloat btnX = 0; 5         CGFloat btnY = 0; 6         CGFloat btnW = self.frame.size.width / 5; 7         CGFloat btnH = self.frame.size.height; 8  9         NSInteger index = 0;10         // 遍曆子控制項11         for (UIView *tabBarButton in self.subviews) {12             if ([tabBarButton isKindOfClass:NSClassFromString(@"UITabBarButton")]) {13                 if (index == 2) {14                     index += 1;15                 }16 17                 btnX = index * btnW;18                 tabBarButton.frame = CGRectMake(btnX, btnY, btnW, btnH);19 20                 index++;21             }22         }23 }

 

但是,在這種情況下,如果存在需要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是私人控制項,我們沒辦法查看內部的屬性及實現邏輯,只能從一些蛛絲馬跡上探究端倪了:

 1 - (void)layoutSubviews{ 2     for (UIView *tabBarButton in self.subviews) { 3         if ([tabBarButton isKindOfClass:NSClassFromString(@"UITabBarButton")]) { 4             NSLog(@"%@",tabBarButton); 5         } 6     } 7      NSLog(@"---------------------------------------------"); 8     [super layoutSubviews]; 9 10         CGFloat btnX = 0;11         CGFloat btnY = 0;12 13         CGFloat btnW = self.frame.size.width / 5;14         CGFloat btnH = self.frame.size.height;15         NSInteger index = 0;16         // 遍曆子控制項17         for (UIView *tabBarButton in self.subviews) {18             if ([tabBarButton isKindOfClass:NSClassFromString(@"UITabBarButton")]) {19                 NSLog(@"%@",tabBarButton);20                 if (index == 2) {21                     index += 1;22                 }23 24                 btnX = index * btnW;25 26                 tabBarButton.frame = CGRectMake(btnX, btnY, btnW, btnH);27 28                 index++;29             }30         }31     NSLog(@"----------------------------------------------");32     for (UIView *tabBarButton in self.subviews) {33         if ([tabBarButton isKindOfClass:NSClassFromString(@"UITabBarButton")]) {34             NSLog(@"%@",tabBarButton);35         }36     }37     NSLog(@"==============================================");38 }

 

以下是列印結果:

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.