開發背景

在存在第一響應者的情況下，連續使用兩次UIAlertView造成alertView的選項被鍵盤擋住，使介面無法進行操作，只能退出程式重新進入APP。

問題描述

APP開發中遇到這樣的問題，在介面中如果存在第一響應者，在彈出UIAlertView時，鍵盤主動收回。當UIAlertView消失的時候對應的控制元件又會變回第一響應者，鍵盤會彈出來。如果這個時候沒有第二次的提示操作是完全可以的，但當有第二次UIAlertView提示，那麼鍵盤並不會像第一次一樣消失，如果恰好鍵盤擋住按鈕操作就悲劇了。

你會說在彈框的時候取消第一響應者，當時我也是這麼想的，我一定是沒有取消第一響應者，然後我發現我取消了[self.view endEditing:YES];

我也去查看了API也沒看出個什麼了，如果有大神看明白了，可以告訴我。我們可以大膽猜測一下，在不取消第一響應者每次都顯示一個UIAlertView，鍵盤交替出現消失，可以看出UIAlertView的出現時是有記錄第一響應者的情況的。第一個view的消失要還原第一響應者，第二個view出現繼承了第一響應者狀態，而鍵盤的出現動畫是2的倍數時的view出現沒能及時的去將鍵盤暫時性的隱藏。（猜測）

而在取消第一響應者和顯示UIAlertView時，在只顯示一次的情況下，當UIAlertView消失時，鍵盤會彈出一下再消失，這個佐證了我們上面的猜測，第一響應者的狀態被記錄了，而取消第一響應者的操作在UIAlertView顯示時間內被掛起了，也有可能時阻塞主執行緒。我們在看如果我們每次都彈出一個新的UIAlertView時，第一響應者會在第三次的UIAlertView出現時被取消了，哈神奇了！！！我們就可以猜測UIAlertView出現時是阻塞主執行緒，而在UIAlertView交替顯示的間隙主執行緒抽空去處理了我們取消第一響應者的請求！

如果我們將彈UIAlertView和取消第一響應者的呼叫順序對換位置，那麼情況是一樣的，可以看出這兩個方法的處理是非同步執行緒處理的。

解決方式

最好是別出現我在一開頭就說的那種擋住操作按鈕的情況，如果真的出現這種情況，又不想改介面方案時可以嘗試我解決的方案：
方案宗旨：在等待第一響應者完全取消後再進行UIAlertView的show操作。
有的同學可能會說“我怎知道什麼時候第一響應者已經完全取消了呢？”在這裡我們可以小小的利用一下鍵盤通知，這裡面有我們想要的一切！

NSDictionary *info = [notification userInfo];

CGFloat duration = [[info objectForKey:UIKeyboardAnimationDurationUserInfoKey] floatValue];

CGRect
 
 endKeyboardRect = [[info objectForKey:UIKeyboardFrameEndUserInfoKey] CGRectValue];

dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(duration * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{

        });

以上純屬猜測和供大家參考，如果大家有什麼好的想法我們可以交流交流。