前言
創(chuàng)新互聯(lián)是一家專注于網(wǎng)站制作、成都做網(wǎng)站與策劃設(shè)計(jì),石屏網(wǎng)站建設(shè)哪家好?創(chuàng)新互聯(lián)做網(wǎng)站,專注于網(wǎng)站建設(shè)十多年,網(wǎng)設(shè)計(jì)領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:石屏等地區(qū)。石屏做網(wǎng)站價(jià)格咨詢:028-86922220在iOS 11發(fā)布之后,出現(xiàn)了一系列適配相關(guān)的問題,UIScrollView在pagingEnabled=YES時(shí)滑動(dòng)手勢不靈敏,UITableView的滑動(dòng)刪除功能變動(dòng),UIImagePickerViewController的取消按鈕點(diǎn)擊區(qū)域變小等,本文介紹其中一個(gè)UIAlertView問題,分享其發(fā)現(xiàn)、定位和解決。
正文
1、問題產(chǎn)生
問題的最初,是iOS 11正式版發(fā)布后不久,測試的同學(xué)提了一個(gè)iOS 11相關(guān)的BUG,表現(xiàn)是:在直播間內(nèi)發(fā)送聊天信息,如果被禁言,會(huì)彈出“被禁言”提示,鍵盤收回去,然后就彈不出來。
開發(fā)在接到這個(gè)BUG的時(shí)候,先把問題抽象出來幾個(gè)要素:直播間內(nèi)、鍵盤彈出、彈出提示、鍵盤收回、鍵盤無法彈出。
“彈出提示是用的UIAlertView的方式。在鍵盤出現(xiàn)時(shí)彈出UIAlertView的提示,鍵盤會(huì)收起,UIAlertView消失后,鍵盤會(huì)再次彈出,是一次正常的表現(xiàn)?!?/p>
2、問題復(fù)現(xiàn)
按照復(fù)現(xiàn)路徑做一次嘗試,發(fā)現(xiàn)BUG可以復(fù)現(xiàn),確定問題存在;
根據(jù)經(jīng)驗(yàn),猜測問題可能出現(xiàn)在鍵盤和UIAlertView上,與“禁言”的業(yè)務(wù)無關(guān)。
在直播間內(nèi)嘗試其他非“禁言”的場景,同樣是在鍵盤出現(xiàn)的時(shí)候,彈出UIAlertView的提示,也會(huì)造成后續(xù)鍵盤無法彈出的情況。
在嘗試完其他非直播間的主場景之后,發(fā)現(xiàn)問題可以描述為:
iOS 11的機(jī)器只要彈出來一次UIAlertView,之后再通過becomeFirstResponder無法呼起鍵盤;必須手動(dòng)點(diǎn)擊輸入?yún)^(qū)域,觸發(fā)系統(tǒng)的鍵盤彈出行為,或者切入后臺(tái)再切回來,才能正常彈出來鍵盤。
部分頁面在點(diǎn)擊評(píng)論后,會(huì)添加一層透明maskView,并彈出鍵盤。點(diǎn)擊透明的maskView會(huì)調(diào)用resignFirstResponder,在鍵盤消失的notification中消除maskView。因?yàn)殒I盤無法彈出(也無法收到鍵盤消失的notification,但maskView還是正常添加),導(dǎo)致這部分頁面無法進(jìn)行后續(xù)的交互。
3、問題評(píng)估
在復(fù)現(xiàn)問題后,需要對(duì)問題的嚴(yán)重性進(jìn)行評(píng)估,確定BUG修復(fù)的優(yōu)先級(jí)。
從已知的表現(xiàn)來看,iOS 11下的使用影響較大(UIAlertView的提示較多)。
用iOS 11的機(jī)器下載外網(wǎng)版本進(jìn)行測試,發(fā)現(xiàn)BUG竟然無法復(fù)現(xiàn)!
雖然很詭異,但是問題的優(yōu)先級(jí)可以降到更低,排入正常的BUG解決列表中。
4、問題解析
外網(wǎng)版本是Xcode8編譯的本,本地版本使用的Xcode9 GM編譯的,難道是Xcode 9編譯導(dǎo)致?
1、新建一個(gè)demo,只有輸入框和按鈕,模擬UIAlertView彈出,發(fā)現(xiàn)demo是正常的;
2、把a(bǔ)pp的工程設(shè)置復(fù)制到demo,把對(duì)輸入框的屬性設(shè)置同樣復(fù)制到demo,demo依舊正常;
3、把demo代碼復(fù)制到app,并把a(bǔ)pp的rootViewController賦值為demo中的VC,依舊正常;
可以確定是app中某部分代碼導(dǎo)致的鍵盤無法彈出的。
經(jīng)過二分注釋的方式,迅速(4、5次左右)定位到問題是app中的某個(gè)Service類導(dǎo)致。
仔細(xì)排插Service類的屬性,發(fā)現(xiàn)里面有一個(gè)屬性的是繼承UIWindow并且level比UIWindowLevelStatusBar高。
自此,根據(jù)所學(xué)和蘋果UIKit的文檔,我們可以對(duì)問題進(jìn)行一次回溯。
5、問題回溯
蘋果官網(wǎng)上響應(yīng)鏈和UIWindow的說明,里面關(guān)于becomeFirstResponder()的解釋是:Asks UIKit to make this object the first responder in its window.
對(duì)于UIAlertView的iOS 11系統(tǒng)行為,猜測:
1、在UIAlertView彈出的時(shí)候,會(huì)搶占系統(tǒng)的keyWindow,所以會(huì)出現(xiàn)鍵盤在UIAlertView的時(shí)候收回(因?yàn)閗eyWindow改變);
2、在UIAlertView消失的時(shí)候,會(huì)遍歷所有Window,找到其中z軸最高作為keyWindow,所以會(huì)出現(xiàn)鍵盤在UIAlertView消失后彈出(keyWindow變成原來的);
通過寫代碼調(diào)試app,確定了上面的猜測。
在iOS 11,如果UIAlertView彈出時(shí),存在windowLevel 大于 UIWindowLevelNormal 的UIWindow,就會(huì)觸發(fā)這個(gè)鍵盤無法彈出的BUG。
6、問題修復(fù)
1、保證app中,沒有常駐的UIWindow;
2、修復(fù)鍵盤無法彈出時(shí),maskView無法消除的BUG;
3、UIAlertView在后續(xù)的版本替換掉;
總結(jié)
這次問題從產(chǎn)生、復(fù)現(xiàn)、定位、評(píng)估再到修復(fù)的時(shí)間,和寫這篇文章的時(shí)間差不多。
BUG的解決流程各不相同,借此提醒自己對(duì)于BUG的解決要有目的性和優(yōu)先級(jí)。
以上就是本文的全部內(nèi)容,希望對(duì)大家的學(xué)習(xí)有所幫助,也希望大家多多支持創(chuàng)新互聯(lián)建站。
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)建站www.cdcxhl.com,海內(nèi)外云服務(wù)器15元起步,三天無理由+7*72小時(shí)售后在線,公司持有idc許可證,提供“云服務(wù)器、裸金屬服務(wù)器、建站服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案,具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢,專為企業(yè)上云打造定制,能夠滿足用戶豐富、多元化的應(yīng)用場景需求。