Android 提供了 windowSoftInputMode 屬性來控制輸入法軟鍵盤窗口和 Activity 主窗口的交互，分為 窗口尺寸調(diào)整系列 和 輸入法軟鍵盤顯示控制系列。

窗口尺寸調(diào)整系列：

該系列參數(shù)用來控制當(dāng)軟鍵盤彈起時(shí)，Activity 主窗口的調(diào)整策略，因?yàn)槿绻徽{(diào)整主窗口，很可能會(huì)導(dǎo)致當(dāng)前輸入的控件被軟鍵盤遮擋。

adjustPan：

Activity的主窗口并不會(huì)重新調(diào)整大小來為輸入法騰出空間，而是窗口的內(nèi)容會(huì)自動(dòng)上下晃動(dòng)來保證當(dāng)前獲得焦點(diǎn)的控件不會(huì)被鍵盤遮擋住，然后用戶可以看見自己輸入的內(nèi)容。相比于 adjustResize 模式而言，它并不是很令人滿意，因?yàn)橛脩舯仨氷P(guān)閉輸入法來和被輸入法遮擋住的控件進(jìn)行交互。

adjustResize：

Activity的主窗口會(huì)重新調(diào)整大小來為輸入法騰出空間。

adjustUnspecified：

當(dāng)前模式并不會(huì)明確指定 Activity 使用adjustPan 或者 adjustResize ，系統(tǒng)會(huì)自動(dòng)選擇一個(gè)模式，選擇結(jié)果是，如果當(dāng)前 Activity 的 Window 中，有可以滾動(dòng)自身內(nèi)容的控件，比如 ScrollView，那么選擇結(jié)果就是 adjustResize，因?yàn)樗J(rèn)為滾動(dòng)可以使 Window 中的內(nèi)容即使在一個(gè)很小的區(qū)域中也可以被看見。Activity 的默認(rèn)模式就是這個(gè)模式。

adjustNoting：

Activity 的 Window 沒有任何變化。

兩種模式下，屏幕 – 主窗口 – 主窗口內(nèi)容 – 軟鍵盤 的關(guān)系如下：

具體效果如下：

沒有滾動(dòng)內(nèi)容，adjustPan：

沒有滾動(dòng)內(nèi)容，adjustResize：

沒有滾動(dòng)內(nèi)容，adjustUnspecified == adjustPan 

有滾動(dòng)內(nèi)容(ScrollView)，adjustPan

有滾動(dòng)內(nèi)容(ScrollView)，adjustResize

有滾動(dòng)內(nèi)容(ScrollView)，adjustUnspecified == adjustResize

輸入法軟鍵盤顯示控制系列：

該系列參數(shù)用來控制當(dāng)一個(gè)包含 Window 的事物(Activity、Dialog等)展示在屏幕最前端時(shí)，軟鍵盤的顯示或者隱藏策略。

stateUnspecified：

系統(tǒng)根據(jù)當(dāng)前具體情況，選擇相應(yīng)的模式。

stateUnchanged：

軟鍵盤保持它的上一個(gè)狀態(tài)(上一個(gè)Activity 或者 Dialog 在屏幕最前端時(shí)，軟鍵盤的狀態(tài))，不做變化，不管上一個(gè)狀態(tài)是顯示還是隱藏。

stateHidden：

當(dāng)用戶主動(dòng)進(jìn)入當(dāng)前界面時(shí)，軟鍵盤隱藏。離開上一個(gè) 界面，返回當(dāng)前界面，不能算作 “主動(dòng)進(jìn)入”。被動(dòng)進(jìn)入時(shí)，保持上一個(gè)狀態(tài)。

stateAlwaysHidden：

只要是用戶進(jìn)入該界面，就隱藏軟鍵盤，不管是主動(dòng)進(jìn)入(新啟動(dòng)該界面)，還是被動(dòng)進(jìn)入(離開上一個(gè)界面，返回到當(dāng)前界面)。

stateVisible：

當(dāng)用戶主動(dòng)進(jìn)入當(dāng)前界面時(shí)，顯示軟鍵盤。離開上一個(gè) 界面，返回當(dāng)前界面，不能算作 “主動(dòng)進(jìn)入”。被動(dòng)進(jìn)入時(shí)，保持上一個(gè)狀態(tài)。

stateAlwaysVisible：

只要是用戶進(jìn)入該界面，就顯示軟鍵盤，不管是主動(dòng)進(jìn)入(新啟動(dòng)該界面)，還是被動(dòng)進(jìn)入(離開上一個(gè)界面，返回到當(dāng)前界面)。

關(guān)于某些華為手機(jī)的一個(gè)Bug

今天遇到一個(gè)Bug，是這樣的，在某些華為手機(jī)上面，除了***次點(diǎn)擊輸入框，adjustPan 參數(shù)會(huì)生效(軟鍵盤可以正常彈起輸入框)，后面從第二次開始，怎么點(diǎn)擊，adjustPan 參數(shù)都無效。

布局模型大致如下：

<RelativeLayout 
xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:tools="http://schemas.android.com/tools" 
android:id="@+id/activity_main" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
tools:context="cn.hjf.inputtest.MainActivity"> 
  
<ScrollView 
android:layout_width="match_parent" 
android:layout_height="match_parent"> 
  
<LinearLayout 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
android:orientation="vertical"> 
  
<View 
android:layout_width="match_parent" 
android:layout_height="400dp" 
android:background="#2b532b"/> 
  
<EditText 
android:layout_width="90dp" 
android:layout_height="wrap_content" 
android:layout_gravity="center_vertical" 
android:background="@null" 
android:gravity="center" 
android:inputType="numberDecimal" 
android:maxLength="8" 
android:minWidth="60dp" 
android:padding="5dp" 
android:text="0.00"/>  

效果是這樣的：

經(jīng)過漫長(zhǎng)時(shí)間的排除(很辛苦)，終于找到了Bug的觸發(fā)臨界點(diǎn)，就是下面這兩句話：

android:gravity="center" 
android:inputType="numberDecimal"  

又經(jīng)過了漫長(zhǎng)時(shí)間的驗(yàn)證，得出一個(gè)結(jié)論：在某些華為機(jī)型上面，在這種布局模型下，EditText 中如果設(shè)置了 inputType 參數(shù)(不為 none)，那么，在 gravity 取值為某些值得時(shí)候，會(huì)導(dǎo)致該問題的發(fā)生。大致情況如下：

紅色表示失效，綠色表示有效(可以正常工作)。當(dāng)這兩個(gè)參數(shù)不指定的時(shí)候，可以工作，因?yàn)檫@兩個(gè)屬性默認(rèn)值的組合是可以工作的，上圖中的藍(lán)色塊。(備注：沒有完全匹配所有情況，如有相似情況，可以按需匹配，查看結(jié)果)

在源碼中可以找到這兩個(gè)屬性的默認(rèn)值：

attrs.xml

themes.xml

<item name="editTextStyle">@style/Widget.EditText</item> 

attrs.xml

<!-- The type of data being placed in a text field, used to help an 
input method decide how to let the user enter text.  The constants 
here correspond to those defined by 
{@link android.text.InputType}.  Generally you can select 
a single value, though some can be combined together as 
indicated.  Setting this attribute to anything besides 
<var>none</var> also implies that the text is editable. --> 
<attr name="inputType"> 
<!-- There is no content type.  The text is not editable. --> 
<flag name="none" value="0x00000000" />   

/** 
* Special content type for when no explicit type has been specified. 
* This should be interpreted to mean that the target input connection 
* is not rich, it can not process and show things like candidate text nor 
* retrieve the current text, so the input method will need to run in a 
* limited "generate key events" mode, if it supports it. Note that some 
* input methods may not support it, for example a voice-based input 
* method will likely not be able to generate key events even if this 
* flag is set. 
*/ 
public static final int TYPE_NULL = 0x00000000;  

一個(gè)需求

遇到一個(gè)需求，大致模型為：有一個(gè)界面，里面有一個(gè) 輸入框 和 兩個(gè)按鈕，分別控制輸入框中數(shù)字的加減，如下圖所示： 

[[195692]] 

每次輸入框數(shù)字變化，不管是手動(dòng)輸入還是按鈕控制，都會(huì)出發(fā)刷新工作，刷新時(shí)會(huì)彈出一個(gè)對(duì)話框。

然后需求是這樣的，當(dāng)手動(dòng)輸入的時(shí)候，這時(shí)觸發(fā)刷新時(shí)，輸入法是顯示的，但是對(duì)話框顯示然后消失后，輸入法就被隱藏了。當(dāng)用按鈕控制的時(shí)候，是沒問題的，因?yàn)檎麄€(gè)過程，輸入法都是隱藏的。所以需求就是，在對(duì)話框顯示然后消失后，輸入法能保持出發(fā)刷新時(shí)的狀態(tài)。

解決問題：當(dāng)把當(dāng)前 Activity 設(shè)置為 stateUnchanged 的時(shí)候，并沒有達(dá)到理想的效果，因?yàn)閐ialog所在的window，沒有設(shè)置該屬性，所以需要把dialog的window也設(shè)置為stateUnchanged，方法為：

getWindow().setSoftInputMode() 

然后就可以了。