iOS开发中键盘问题

开发背景

在存在第一响应者的情况下，连续使用两次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(), ^{

        });

以上纯属猜测和供大家参考，如果大家有什么好的想法我们可以交流交流。