一個iOS 11BUG的發現、定位和解決
在iOS 11釋出之後，出現了一系列適配相關的問題，UIScrollView在pagingEnabled=YES時滑動手勢不靈敏，UITableView的滑動刪除功能變動，UIImagePickerViewController的取消按鈕點選區域變小等，本文介紹其中一個UIAlertView問題，分享其發現、定位和解決。
正文
1、問題產生
問題的最初，是iOS 11正式版釋出後不久，測試的同學提了一個iOS 11相關的BUG，表現是：在直播間內傳送聊天資訊，如果被禁言，會彈出“被禁言”提示，鍵盤收回去，然後就彈不出來。
開發在接到這個BUG的時候，先把問題抽象出來幾個要素：直播間內、鍵盤彈出、彈出提示、鍵盤收回、鍵盤無法彈出。
彈出提示是用的UIAlertView的方式。在鍵盤出現時彈出UIAlertView的提示，鍵盤會收起，UIAlertView消失後，鍵盤會再次彈出，是一次正常的表現。
2、問題復現
按照復現路徑做一次嘗試，發現BUG可以復現，確定問題存在；
根據經驗，猜測問題可能出現在鍵盤和UIAlertView上，與“禁言”的業務無關。
在直播間內嘗試其他非“禁言”的場景，同樣是在鍵盤出現的時候，彈出UIAlertView的提示，也會造成後續鍵盤無法彈出的情況。
在嘗試完其他非直播間的主場景之後，發現問題可以描述為：
iOS 11的機器只要彈出來一次UIAlertView，之後再通過becomeFirstResponder無法呼起鍵盤；必須手動點選輸入區域，觸發系統的鍵盤彈出行為，或者切入後臺再切回來，才能正常彈出來鍵盤。
部分頁面在點選評論後，會新增一層透明maskView，並彈出鍵盤。點選透明的maskView會呼叫resignFirstResponder，在鍵盤消失的notification中消除maskView。因為鍵盤無法彈出（也無法收到鍵盤消失的notification，但maskView還是正常新增），導致這部分頁面無法進行後續的互動。
3、問題評估
在復現問題後，需要對問題的嚴重性進行評估，確定BUG修復的優先順序。
從已知的表現來看，iOS 11下的使用影響較大（UIAlertView的提示較多）。
用iOS 11的機器下載外網版本進行測試，發現BUG竟然無法復現！
雖然很詭異，但是問題的優先順序可以降到更低，排入正常的BUG解決列表中。
4、問題解析
外網版本是Xcode8編譯的本，本地版本使用的Xcode9 GM編譯的，難道是Xcode 9編譯導致？
1、新建一個demo，只有輸入框和按鈕，模擬UIAlertView彈出，發現demo是正常的；
2、把app的工程設定複製到demo，把對輸入框的屬性設定同樣複製到demo，demo依舊正常；
3、把demo程式碼複製到app，並把app的rootViewController賦值為demo中的VC，依舊正常；
可以確定是app中某部分程式碼導致的鍵盤無法彈出的。
經過二分註釋的方式，迅速（4、5次左右）定位到問題是app中的某個Service類導致。
仔細排插Service類的屬性，發現裡面有一個屬性的是繼承UIWindow並且level比UIWindowLevelStatusBar高。
自此，根據所學和蘋果UIKit的文件，我們可以對問題進行一次回溯。
5、問題回溯
蘋果官網上響應鏈和UIWindow的說明，裡面關於becomeFirstResponder()的解釋是：Asks UIKit to make this object the first responder in its window.
對於UIAlertView的iOS 11系統行為，猜測：
1、在UIAlertView彈出的時候，會搶佔系統的keyWindow，所以會出現鍵盤在UIAlertView的時候收回（因為keyWindow改變）；
2、在UIAlertView消失的時候，會遍歷所有Window，找到其中z軸最高作為keyWindow，所以會出現鍵盤在UIAlertView消失後彈出（keyWindow變成原來的）；
通過寫程式碼除錯app，確定了上面的猜測。
在iOS 11，如果UIAlertView彈出時，存在windowLevel 大於 UIWindowLevelNormal 的UIWindow，就會觸發這個鍵盤無法彈出的BUG。
6、問題修復
1、保證app中，沒有常駐的UIWindow；
2、修復鍵盤無法彈出時，maskView無法消除的BUG；
3、UIAlertView在後續的版本替換掉；
總結
這次問題從產生、復現、定位、評估再到修復的時間，和寫這篇文章的時間差不多。
BUG的解決流程各不相同，藉此提醒自己對於BUG的解決要有目的性和優先順序。
想要了解更多請關注公眾號
