莫名的穿透

之前版本中出現(xiàn)一個bug配椭，個別的QA同事反映APP中的部分彈框(UIView)彈出來之后就沒法點擊了慎恒，然而這個彈框蒙層背后的界面依然可以正常交互和悦，好像出現(xiàn)了一種“穿透”效果：

穿透.gif

- (void)show {
    [[UIApplication sharedApplication].keyWindow addSubview:self];
}

這幾個UIView都是被加到了keyWindow上，當(dāng)時覺得問題也就出在這里了臀叙，因為加在UIWindow上的東西始終是展示在最上面的略水，可能某種情況下導(dǎo)致這些UIView無法被銷毀了，但至于是什么情況我也猜不到劝萤，最后將他們的展示方式都改為了:

    [self.tabBarController.view addSubview:self];

后來就沒有人反饋過類似的問題了渊涝，我的心里在還為自己又解決了一個“靈異”問題而自嗨了短暫的幾秒。

后來無意中被我找到了復(fù)現(xiàn)的規(guī)律床嫌，我發(fā)現(xiàn)只要我在某一個頁面彈出過一次UIAlertView以后跨释，其他只要是add到keyWindow上的彈框，100%會出現(xiàn)這種“穿透的效果”厌处，這也是我上面的demo中有一個按鈕是alert的原因鳖谈，后面會講到。

我跟旁邊的dj_rose同學(xué)提到了這個現(xiàn)象阔涉，他捕捉到了window這個關(guān)鍵字缆娃，告訴我在上個版本我們接入過一個第三方的推送組件，這個組件就是在UIWindow的基礎(chǔ)上做的瑰排，會不會是這個組件產(chǎn)生了影響贯要，這個線索很關(guān)鍵，于是我順著這條線椭住，在這個第三方組件的源碼里找到了蛛絲馬跡：

EBBanerWindow

        sharedWindow = [[self alloc] initWithFrame:CGRectZero];
        sharedWindow.windowLevel = UIWindowLevelAlert;
        sharedWindow.layer.masksToBounds = NO;
        UIWindow *originKeyWindow = UIApplication.sharedApplication.keyWindow;
        [sharedWindow makeKeyAndVisible];
        [originKeyWindow makeKeyAndVisible];

他會將原來的keyWindow保存到originKeyWindow這個臨時變量中，最后再向它發(fā)送一遍makeKeyAndVisible消息尖飞，這樣理應(yīng)keyWindow是不會被影響到的症副，作者之所以加上這步操作我猜他也是為了防止keyWindow被替換而帶來的不必要的麻煩店雅，這就奇怪了，也就是說在某種情況下我的keyWindow還是被偷偷替換了贞铣。

keyWindow和UIAlertView

那到底是誰替換了keyWindow呢闹啦？答案我在上面已經(jīng)留下過伏筆了，我復(fù)現(xiàn)的規(guī)律是只要在APP中任何一個頁面彈出來過一次UIAlertView之后辕坝，這個“穿透”就會發(fā)生窍奋，那肯定就是UIAlertView影響到了keyWindow，之前對UIAlertView的了解也就停留在“其實它也是一個Window”的級別上酱畅，至于它為什么會改變keyWindow并沒有研究過琳袄，隨即百度一番(百度雖然有點low但卻能解決現(xiàn)階段我的大部分問題，原因可能是我太low了吧)纺酸，找到了幾篇有用的文章挚歧，將他們的觀點總結(jié)一下：

1.使用UIAlertView的show時，系統(tǒng)使用了一個臨時的并且層級最高的UIWindow來展現(xiàn)UIAlertView吁峻，所以當(dāng)show彈窗時滑负，keyWindow已經(jīng)被替換為_UIAlertControllerShimPresenterWindow，打印了一下也的確是這樣用含。

UIAlertView替換keyWindow.png

windows數(shù)組的排列順序

一般的痴鳄，我們項目中在AppDelegate里都會有這樣幾句代碼：

   self.window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
  [self.window makeKeyAndVisible];

其實寫了這么多遍也沒細(xì)細(xì)分析過這句代碼，它其實就是給APP設(shè)置一個keyWindow缸夹，用來作為之后呈現(xiàn)的一切UIView的載體痪寻，這個window會排在windows數(shù)組里的第一個，一般項目中如果沒有特殊需求去自定義UIWindow的話虽惭，這個windows數(shù)組里的firstObject通常情況下始終會是我們在AppDelegate中創(chuàng)建的這個window(當(dāng)然也不排除有firstObject被系統(tǒng)偷偷替換的情況橡类，這也是我們另一個線上反饋很多次無法復(fù)現(xiàn)的bug的原因)：

通常情況下的windows數(shù)組

收到推送之后的windows數(shù)組

windowLevel的不同級別

makeKeyAndVisible和setHidden:

討論windows數(shù)組中元素的排列順序之前我們先來看一下蘋果官方文檔對于makeKeyAndVisible這個方法的解釋：

This is a convenience method to show the current window and position it in front of all other windows at the same level or lower. If you only want to show the window, change its hidden property to NO.

意思也就是這個方法可以讓一個window在跟它級別相等或者級別比它低的window中凸現(xiàn)出來，讓這個window中的view展示在其他window的上面窜醉，如果你只是想讓一個window展現(xiàn)出來宪萄，將它的hidden屬性設(shè)為NO就可以了，因為一個UIWindow被創(chuàng)建出來的時候hidden屬性是默認(rèn)為YES的榨惰。
其實在開發(fā)中我們也只需要將那個在AppDelegate中創(chuàng)建的window設(shè)為keyWindow拜英，其他的自定義window需要展現(xiàn)，只需要將它們的hidden屬性設(shè)為NO琅催，makeKeyAndVisible雖然是一個“convenience method”居凶，也能讓window展現(xiàn)，但是因為它會改變keyWindow藤抡，所以我個人是不建議使用侠碧。

回到windows數(shù)組的排列順序，前面說了缠黍，第一個是取決于windowLevel的大小弄兜，大的排后面，小的排前面瓷式，那么如果數(shù)組中兩個window的level相同替饿，那么誰排在前面，誰排在后面呢贸典？我在網(wǎng)上看到的一個答案說是最后一次調(diào)用makeKeyAndVisible或者setHidden:YES方法的那個window排在后面视卢，因為這兩個方法都會將一個window的hidden屬性改為YES，所以會影響這個window在數(shù)組中的順序瓤漏，最后一次調(diào)用這兩個方法中任何一個的window它也就類似于“最后一個被影響過”腾夯，所以它排在別人后面。

demoOne

我將原來EBBanerWindow.m中兩個自定義window的展現(xiàn)方式都改為了通過setHidden:的方式蔬充，并且代碼的順序改為emptyWindow在前，bannerWindow在后班利，因為這兩個window的level是相同的饥漫，按上面的觀點那bannerWindow肯定會在windows數(shù)組中排在emptyWindow的后面，我們來看看運行結(jié)果：

        UIWindow *originKeyWindow = UIApplication.sharedApplication.keyWindow;
        emptyWindow = [[EBEmptyWindow alloc] initWithFrame:CGRectZero];
        emptyWindow.windowLevel = UIWindowLevelAlert;
        [emptyWindow setHidden:NO];
        [originKeyWindow makeKeyAndVisible];
        
        bannerWindow = [[self alloc] initWithFrame:CGRectZero];
        bannerWindow.windowLevel = UIWindowLevelAlert;
        [bannerWindow setHidden:NO];
        [originKeyWindow makeKeyAndVisible];

demoOne

demoTwo

為了進一步證明這個觀點我將源碼中給emptyWindow和bannerWindow設(shè)置windowLevel的代碼注釋掉竿拆，這樣他們兩的level也變成了默認(rèn)值UIWindowLevelNormal，這樣[originKeyWindow makeKeyAndVisible]是最后調(diào)用的宾尚，那么按照最后調(diào)用排后面的原則是不是windows數(shù)組中UIWindow會跑到數(shù)組的最后一個去呢丙笋，let us see see：

        UIWindow *originKeyWindow = UIApplication.sharedApplication.keyWindow;
        emptyWindow = [[EBEmptyWindow alloc] initWithFrame:CGRectZero];
//        emptyWindow.windowLevel = UIWindowLevelAlert;
        [emptyWindow setHidden:NO];
        [originKeyWindow makeKeyAndVisible];
        
        bannerWindow = [[self alloc] initWithFrame:CGRectZero];
//        bannerWindow.windowLevel = UIWindowLevelAlert;
        [bannerWindow setHidden:NO];
        [originKeyWindow makeKeyAndVisible];

demoTwo

demoThree

根據(jù)這個假設(shè)我先改變了emptyWindow和bannerWindow的創(chuàng)建順序笙各，將bannerWindow放在了emptyWindow之前，但是他們調(diào)用setHidden:的順序還是不變础芍，bannerWindow在emptyWindow之后：

        UIWindow *originKeyWindow = UIApplication.sharedApplication.keyWindow;
        bannerWindow = [[self alloc] initWithFrame:CGRectZero];
        emptyWindow = [[EBEmptyWindow alloc] initWithFrame:CGRectZero];

        emptyWindow.windowLevel = UIWindowLevelAlert;
        [emptyWindow setHidden:NO];
        [originKeyWindow makeKeyAndVisible];
        
        bannerWindow.windowLevel = UIWindowLevelAlert;
        [bannerWindow setHidden:NO];
        [originKeyWindow makeKeyAndVisible];

這樣如果按先創(chuàng)建的順序bannerWindow應(yīng)該排在emptyWindow前面杈抢，如果按照后調(diào)用setHidden:的順序bannerWindow應(yīng)該排在emptyWindow后面，剛好形成了一個互斥者甲，也就是說決定因素只有一個春感，我們來看看結(jié)果:

demoThree

demoFour

demoFour

demoFive

那么windowlevel的高低和創(chuàng)建的順序這兩者哪一個優(yōu)先級更高呢宰缤？我將bannerWindow和emptyWindow的優(yōu)先級都改為了UIWindowLevelNormal颂翼，然后將AppDelegate中的self.window的level提高到了UIWindowLevelAlert，但創(chuàng)建順序self.window還是在兩個自定義window的后面慨灭，看一下運行結(jié)果：

    UIViewController *vc = [UIViewController new];
    self.bannerWindow = [[EBBannerWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
    self.bannerWindow.rootViewController = vc;
    [self.bannerWindow  setHidden:NO];
    self.emptyWindow = [[EBEmptyWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
    self.emptyWindow.rootViewController = vc;
    [self.emptyWindow setHidden:NO];
    self.window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
    self.window.windowLevel = UIWindowLevelAlert;

demoFive

穿透的原因

前面說了當(dāng)UIAlertView彈出來后keyWindow被替換成一個臨時的window并思，當(dāng)UIAlertViewdismiss之后這個臨時的window也隨即被銷毀庐氮，那么系統(tǒng)會去尋找一個新的keyWindow人選，這個候選人自然是來自windows數(shù)組宋彼，至于競選規(guī)則就是上面幾個demo總結(jié)出來的先優(yōu)先級后創(chuàng)建順序規(guī)則弄砍，按我們項目中最初的寫法，這個新的keyWindow人選是第三方組件的中的emptyWindow宙暇，因為它優(yōu)先級最高并且是最后一個被創(chuàng)建的输枯，同時這個emptyWindow的frame是CGRectZero，所以加上去的彈框的所有點擊事件都無法響應(yīng)了占贫，這個地方其實我仍然有點疑惑的是桃熄，為什么這個window的frame是CGRectZero添加到這個window上的view依然可以展示出來，只是不能響應(yīng)點擊事件而已型奥，但也正因為它的frame是CGRectZero瞳收，彈出來的被添加到emptyWindow上的這些UIView骇塘，并沒有阻斷其他window上控件的事件傳遞沐序，蓋在它們下面的控件依然可以正常點擊瘦癌，這也就是所謂的“穿透”效果眼俊。

解決方案

找到問題的原因之后我們對這個推送第三方組件進行了修改，因為他是一個單例荷辕，沒法在沒有推送的情況下去銷毀這兩個自定義的UIWindow伟阔，只能在彈出和消失的時候加以控制办桨。討論出來的方案是首先將bannerWindow和emptyWindow的windowLevel降為了默認(rèn)值UIWindowLevelNormal搭综，因為一個推送彈框只要讓用戶看見即可垢箕，它不存在交互，所以不需要那么高的級別兑巾，而且windowLevel會影響一個window在windows數(shù)組中的順序条获，而數(shù)組中的順序是影響keyWindow的關(guān)鍵因素。其次將這兩個自定義window的展現(xiàn)方式從makeKeyAndVisible改為setHidden:NO蒋歌，我猜想到原作者寫這句[originKeyWindow makeKeyAndVisible];代碼原因就只是想讓他的自定義window展現(xiàn)出來而不影響到keyWindow帅掘，所以調(diào)用setHidden:方法足矣，改了這兩個地方后堂油，emptyWindow修档、bannerWindow和appdelegate.window都是UIWindowLevelNormal級別的，但因為emptyWindow是最后被創(chuàng)建的府框，所以它還是會排在數(shù)組的最后面萍悴，只要UIAlertView彈出并消失后，它依然是keyWindow的最佳人選寓免，所以我們需要在推送框的的hide方法里癣诱，在hide動畫完成之后，手動的調(diào)用一次[appdelegate.window makeKeyAndVisible];方法袜香，將appdelegate.window置回keyWindow撕予，也就是讓emptyWindow把keyWindow的席位交出去，我們雖然不能改變它最佳候選人的位置蜈首，但卻可以讓它自己讓位实抡，這樣就避免了keyWindow的影響，另外我們也把所有add到keyWindow上的這類彈框的展現(xiàn)方式統(tǒng)一做了替換欢策，分別添加到對應(yīng)的VC.view或者tabbarVC.view上吆寨，對于UIAlertView，因為在iOS 9.0以后也被蘋果廢棄了踩寇，我猜蘋果可能也是發(fā)現(xiàn)了這種用UIWindow承載UIAlertView這種方式會對keyWindow產(chǎn)生影響啄清，另一方面UIAlertView的代理方法對代碼邏輯也是一種拆散，所以我們也將項目中使用UIAlertView的地方逐步的替換為更好的UIAlertController俺孙，畢竟UIAlertController是不會去改變keyWindow的辣卒。

面向bug開發(fā)

踩過這一個坑后我想說在使用國內(nèi)非大神寫的第三方組件上時一定要“三思”，其實這個組件確實寫的蠻厲害睛榄，替我們節(jié)省了很多開發(fā)時間荣茫，不過拋開這個組件其他地方不談，我能在初始化window這段源碼中看到作者的防御機制场靴，但感覺并沒有吃透UIWindow的一些用法和原理啡莉，才導(dǎo)致在和UIAlertView一起的時候出現(xiàn)了問題。其實也是因為這個bug才迫使我去一點一點了解UIWindow的東西旨剥，可能bug才是推動技術(shù)進步的第一要素咧欣，以上是我自己總結(jié)出來的一些心得，看到這些觀點的同學(xué)也務(wù)必要“三思”而后行泞边。

參考文章：
EBBannerView只需一行代碼：展示跟 iOS 系統(tǒng)一樣的推送通知橫幅
添加多個UIWindow時该押，使用keyWindow要注意一點
iOS 關(guān)于UIAlertController、UIAlertView彈窗問題
UIWindow的windowLevel屬性