一個(gè)BUG的發(fā)現(xiàn)、定位和解決

作者：落影l(fā)oyinglin 2017-10-10 15:14:23

在iOS 11發(fā)布之后，出現(xiàn)了一系列適配相關(guān)的問(wèn)題，UIScrollView在pagingEnabled=YES時(shí)滑動(dòng)手勢(shì)不靈敏，UITableView的滑動(dòng)刪除功能變動(dòng)，UIImagePickerViewController的取消按鈕點(diǎn)擊區(qū)域變小等，本文介紹其中一個(gè)UIAlertView問(wèn)題，分享其發(fā)現(xiàn)、定位和解決。

前言

正文

1、問(wèn)題產(chǎn)生

問(wèn)題的最初，是iOS 11正式版發(fā)布后不久，測(cè)試的同學(xué)提了一個(gè)iOS 11相關(guān)的BUG，表現(xiàn)是：在直播間內(nèi)發(fā)送聊天信息，如果被禁言，會(huì)彈出“被禁言”提示，鍵盤(pán)收回去，然后就彈不出來(lái)。

開(kāi)發(fā)在接到這個(gè)BUG的時(shí)候，先把問(wèn)題抽象出來(lái)幾個(gè)要素：直播間內(nèi)、鍵盤(pán)彈出、彈出提示、鍵盤(pán)收回、鍵盤(pán)無(wú)法彈出。

彈出提示是用的UIAlertView的方式。在鍵盤(pán)出現(xiàn)時(shí)彈出UIAlertView的提示，鍵盤(pán)會(huì)收起，UIAlertView消失后，鍵盤(pán)會(huì)再次彈出，是一次正常的表現(xiàn)。

2、問(wèn)題復(fù)現(xiàn)

按照復(fù)現(xiàn)路徑做一次嘗試，發(fā)現(xiàn)BUG可以復(fù)現(xiàn)，確定問(wèn)題存在;

根據(jù)經(jīng)驗(yàn)，猜測(cè)問(wèn)題可能出現(xiàn)在鍵盤(pán)和UIAlertView上，與“禁言”的業(yè)務(wù)無(wú)關(guān)。
在直播間內(nèi)嘗試其他非“禁言”的場(chǎng)景，同樣是在鍵盤(pán)出現(xiàn)的時(shí)候，彈出UIAlertView的提示，也會(huì)造成后續(xù)鍵盤(pán)無(wú)法彈出的情況。

在嘗試完其他非直播間的主場(chǎng)景之后，發(fā)現(xiàn)問(wèn)題可以描述為：

iOS 11的機(jī)器只要彈出來(lái)一次UIAlertView，之后再通過(guò)becomeFirstResponder無(wú)法呼起鍵盤(pán);必須手動(dòng)點(diǎn)擊輸入?yún)^(qū)域，觸發(fā)系統(tǒng)的鍵盤(pán)彈出行為，或者切入后臺(tái)再切回來(lái)，才能正常彈出來(lái)鍵盤(pán)。
部分頁(yè)面在點(diǎn)擊評(píng)論后，會(huì)添加一層透明maskView，并彈出鍵盤(pán)。點(diǎn)擊透明的maskView會(huì)調(diào)用resignFirstResponder，在鍵盤(pán)消失的notification中消除maskView。因?yàn)殒I盤(pán)無(wú)法彈出(也無(wú)法收到鍵盤(pán)消失的notification，但maskView還是正常添加)，導(dǎo)致這部分頁(yè)面無(wú)法進(jìn)行后續(xù)的交互。

3、問(wèn)題評(píng)估

在復(fù)現(xiàn)問(wèn)題后，需要對(duì)問(wèn)題的嚴(yán)重性進(jìn)行評(píng)估，確定BUG修復(fù)的優(yōu)先級(jí)。
從已知的表現(xiàn)來(lái)看，iOS 11下的使用影響較大(UIAlertView的提示較多)。
用iOS 11的機(jī)器下載外網(wǎng)版本進(jìn)行測(cè)試，發(fā)現(xiàn)BUG竟然無(wú)法復(fù)現(xiàn)!
雖然很詭異，但是問(wèn)題的優(yōu)先級(jí)可以降到更低，排入正常的BUG解決列表中。

4、問(wèn)題解析

外網(wǎng)版本是Xcode8編譯的本，本地版本使用的Xcode9 GM編譯的，難道是Xcode 9編譯導(dǎo)致?

新建一個(gè)demo，只有輸入框和按鈕，模擬UIAlertView彈出，發(fā)現(xiàn)demo是正常的;
把a(bǔ)pp的工程設(shè)置復(fù)制到demo，把對(duì)輸入框的屬性設(shè)置同樣復(fù)制到demo，demo依舊正常;
把demo代碼復(fù)制到app，并把a(bǔ)pp的rootViewController賦值為demo中的VC，依舊正常;

可以確定是app中某部分代碼導(dǎo)致的鍵盤(pán)無(wú)法彈出的。

經(jīng)過(guò)二分注釋的方式，迅速(4、5次左右)定位到問(wèn)題是app中的某個(gè)Service類(lèi)導(dǎo)致。

仔細(xì)排插Service類(lèi)的屬性，發(fā)現(xiàn)里面有一個(gè)屬性的是繼承UIWindow并且level比UIWindowLevelStatusBar高。

自此，根據(jù)所學(xué)和蘋(píng)果UIKit的文檔，我們可以對(duì)問(wèn)題進(jìn)行一次回溯。

5、問(wèn)題回溯

蘋(píng)果官網(wǎng)上響應(yīng)鏈和UIWindow的說(shuō)明，里面關(guān)于becomeFirstResponder()的解釋是：

Asks UIKit to make this object the first responder in its window.

對(duì)于UIAlertView的iOS 11系統(tǒng)行為，猜測(cè)：

在UIAlertView彈出的時(shí)候，會(huì)搶占系統(tǒng)的keyWindow，所以會(huì)出現(xiàn)鍵盤(pán)在UIAlertView的時(shí)候收回(因?yàn)閗eyWindow改變);
在UIAlertView消失的時(shí)候，會(huì)遍歷所有Window，找到其中z軸***作為keyWindow，所以會(huì)出現(xiàn)鍵盤(pán)在UIAlertView消失后彈出(keyWindow變成原來(lái)的);

通過(guò)寫(xiě)代碼調(diào)試app，確定了上面的猜測(cè)。

在iOS 11，如果UIAlertView彈出時(shí)，存在windowLevel 大于 UIWindowLevelNormal 的UIWindow，就會(huì)觸發(fā)這個(gè)鍵盤(pán)無(wú)法彈出的BUG。

6、問(wèn)題修復(fù)