/Users/chenjiajiang/Desktop/截圖/大神班/Snip20160827_1.png ...

關於自定義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.如下圖所示.