在iOS應(yīng)用開發(fā)中，有三類視圖對(duì)象會(huì)打開虛擬鍵盤，進(jìn)行輸入操作，但如何關(guān)閉虛擬鍵盤，卻沒有提供自動(dòng)化的方法。這個(gè)需要我們自己去實(shí)現(xiàn)。這三類視圖對(duì)象分別是UITextField,UITextView和UISearchBar。
這里介紹一下UITextField中關(guān)閉虛擬鍵盤的幾種方法。

(原文鏈接: http://mikixiyou.iteye.com/blog/1753330 )

第一種方法，使用它的委托UITextFieldDelegate中的方法textFieldShouldReturn:來關(guān)閉虛擬鍵盤。
在UITextField視圖對(duì)象如birdNameInput所在的類中實(shí)現(xiàn)這個(gè)方法。

 這樣，在輸入框birdNameInput中打開虛擬鍵盤后，輕擊鍵盤的return鍵就會(huì)自動(dòng)關(guān)閉掉虛擬鍵盤。

第二種方法，將birdNameInput的屬性中Return Key修改為done，再定義一個(gè)方法和Done鍵的Did End On Exit連接。通過輕擊done鍵觸發(fā)這個(gè)事件來關(guān)閉虛擬鍵盤。
定義的方法如下：

這兩個(gè)方法都是輕擊虛擬鍵盤上一個(gè)鍵來關(guān)閉它。這屬于精確操作，而手指不像鼠標(biāo)，做這種操作不容易。因此就UI層面而言，這兩個(gè)方法都不是最好的方法。
在iphone或ipad屏幕上，虛擬鍵盤占用的面積大小是有限的。通過輕擊虛擬鍵盤之外的區(qū)域而關(guān)閉虛擬鍵盤。

第三種方法，通過輕擊鍵盤之外的空白區(qū)域關(guān)閉虛擬鍵盤。
在birdNameInput所屬的視圖控制器類的viewDidLoad方法中定義一個(gè)UITapGestureRecognizer的對(duì)象，然后將它賦值為它的視圖。

再定義一下選擇器調(diào)用的方法dismissKeyboard。

如果屏幕上有多個(gè)textField的話，一個(gè)一個(gè)地列出來就有些麻煩。那么將方法修改一下，如下：

如果這個(gè)屏幕上的視圖對(duì)象很復(fù)雜的話，另當(dāng)別論。
這個(gè)方法是編碼新建一個(gè)手勢(shì)對(duì)象。也可以直接使用interface builder圖形化開發(fā)工具，在storyboard中拉入一個(gè)手勢(shì)對(duì)象到視圖控制器類中，再將此手勢(shì)對(duì)象建立一個(gè)IBACTION，名稱可以是dismissKeyboard。

第四種方法，通過輕擊鍵盤之外的空白區(qū)域關(guān)閉虛擬鍵盤。
將屏幕上的view也就是textField的父視圖拖一個(gè)touch down事件出來，和一個(gè)能關(guān)閉虛擬鍵盤的方法連接。如果視圖沒有touch down事件，可將view的父類從UIView修改為UIButton。
首先定義并實(shí)現(xiàn)一個(gè)方法backgroundTap：。

然后選擇背景視圖的Touch Down事件，連接 backgroundTap：即可。這樣只要輕擊一下虛擬鍵盤之外的區(qū)域，就能關(guān)閉虛擬鍵盤。這些方法都是使用resignFirstResponder方法來關(guān)閉虛擬鍵盤，還有其他的方法。

第五種方法，使用endEditing：方法
在所在的視圖控制器類中，覆蓋這個(gè)方法。

This method looks at the current view and its subview hierarchy for the text field that is currently the first responder. If it finds one, it asks that text field to resign as first responder. If the force parameter is set to YES, the text field is never even asked; it is forced to resign.
但是，如果這個(gè)屏幕很復(fù)雜，虛擬鍵盤之外的區(qū)域中有很多按鈕。輕擊這些區(qū)域時(shí)可能會(huì)輕擊到這些按鈕，這樣虛擬鍵盤就不能關(guān)閉。
要是找到一個(gè)沒有按鈕的空白區(qū)域都不容易且還有隱藏的視圖對(duì)象時(shí)，通過輕擊虛擬鍵盤之外的區(qū)域關(guān)閉虛擬鍵盤的方法實(shí)現(xiàn)起來就難了。

第六種方法，覆蓋hitTest:withEvent:方法關(guān)閉虛擬鍵盤

在stackoverflow.com上，有人這樣總結(jié)。說使用hitTest:withEvent:方法是最好的，也是最容易的解決方法。

I think the easiest (and best) way to do this is to subclass your global view and use hitTest:withEvent method to listen to any touch. 
Touches on keyboard aren't registered, so hitTest:withEvent is only called when you touch/scroll/swipe/pinch... somewhere else, then call [self endEditing:YES].
This is better than using touchesBegan because touchesBegan are not called if you click on a button on top of the view. 
It is better than UITapGestureRecognizer which can't recognize a scrolling gesture for example. It is also better than using a dim screen because in a complexe and dynamic user interface, you can't put dim screen every where. Moreover, it doesn't block other actions, you don't need to tap twice to select a button outside (like in the case of a UIPopover).
Also, it's better than calling [textField resignFirstResponder], because you may have many text fields on screen, so this works for all of them.

因此，我再建立一個(gè)繼承UIView的視圖類。在這個(gè)視圖類中，覆蓋hitTest:withEvent:方法，增加[self endEditing:YES]方法。

我將視圖控制器的主視圖所屬類修改為這個(gè)新建視圖類。這樣在屏幕上輕擊任何位置都會(huì)關(guān)閉虛擬鍵盤。
這個(gè)方法是最簡(jiǎn)單，也是最好的關(guān)閉虛擬鍵盤的方法。
使用好hitTest:withEvent:這個(gè)方法，還可以實(shí)現(xiàn)很多很復(fù)雜的功能。
The implementation of hitTest:withEvent: in UIResponder does the following:

•     It calls pointInside:withEvent: of self
•     If the return is NO, hitTest:withEvent: returns nil. the end of the story.
•     If the return is YES, it sends hitTest:withEvent: messages to its subviews. it starts from the top-level subview, and continues to other views until a subview returns a non-nil object, or all subviews receive the message.
•     If a subview returns a non-nil object in the first time, the first hitTest:withEvent: returns that object. the end of the story.
•     If no subview returns a non-nil object, the first hitTest:withEvent: returns self

This process repeats recursively, so normally the leaf view of the view hierarchy is returned eventually.
However, you might override hitTest:withEvent to do something differently. In many cases, overriding pointInside:withEvent: is simpler and still provides enough options to tweak event handling in your application.