Este artículo presenta principalmente la explicación detallada de las propiedades de windowSoftInputMode en Android. Este artículo ofrece un resumen detallado de las 9 propiedades de windowSoftInputMode. Los amigos que lo necesitan pueden consultar
En el artículo anterior, presenté brevemente cómo darse cuenta de que el teclado virtual no aparece automáticamente. El método utilizado es configurar el atributo android: windowSoftInputMode. Entonces, ¿qué hace exactamente este atributo y qué función tiene? El artículo de hoy es para explorar el papel de android: atributo windowSoftInputMode.
En primer lugar, podemos ver su función de forma intuitiva a partir del nombre de este atributo, este atributo se utiliza para configurar el modo interactivo del teclado en pantalla de la ventana.
El atributo android: windowSoftInputMode tiene un total de 9 valores, que son:
stateUnspecified ， stateUnchanged ， stateHidden ， stateAlwaysHidden ， stateVisible ， stateAlwaysVisible ， AdjustUnspecified ， AdjustResize ， AdjustPan。
Cuando configuramos la propiedad, podemos elegir uno de estos 9 valores, o podemos configurarlo en forma de "estado ... | ajustar". Entonces, ¿cómo afectan estos valores a la interacción entre el teclado virtual y la ventana? A continuación, probaremos estos 9 valores uno por uno y cómo afectan la pantalla del teclado virtual.
1.stateUnspecified
Chino significa estado no especificado. Cuando no configuramos el atributo android: windowSoftInputMode, el software usa este modo interactivo de forma predeterminada. El sistema adoptará el modo de visualización de teclado virtual correspondiente de acuerdo con la interfaz, por ejemplo, cuando solo hay texto y botones en la interfaz El teclado virtual no se abrirá automáticamente porque no es necesario introducir datos. Entonces, cuando aparece un cuadro de entrada que ha ganado el foco en la interfaz, ¿el teclado virtual aparecerá automáticamente? ¡Esto no necesariamente es cierto! Por ejemplo, en el diseño de la interfaz a continuación, el teclado en pantalla no aparece automáticamente.
Es decir, de forma predeterminada, en esta situación de interfaz, el sistema no está seguro de si el usuario necesita un teclado en pantalla, por lo que no aparecerá automáticamente. Pero, ¿por qué no necesariamente? Esto se debe a que si estamos fuera de este diseño, envolvemos el anterior
ScrollView, el teclado virtual aparecerá automáticamente.
De la siguiente manera, en este archivo de diseño, el teclado virtual aparecerá automáticamente
<LinearLayout xmlns: android = "http://schemas.android.com/apk/res/android"
xmlns: tools = "http://schemas.android.com/tools"
android: layout_width = "match_parent"
android: layout_height = "match_parent"
android: orientación = "vertical">
<ScrollView
android: layout_width = "match_parent"
android: layout_height = "match_parent">
<LinearLayout
android: layout_width = "match_parent"
android: layout_height = "wrap_content"
android: orientación = " vertical ">
< Botón
android: layout_width = "match_parent"
android: layout_height = "wrap_content"
android: onClick = "toOther"
android: text = "跳转" />
<EditText
android: layout_width = "match_parent"
android: layout_height = "wrap_content" />
</LinearLayout>
</ScrollView>
</LinearLayout>
De hecho, esta es una forma muy extraña de juzgar. Por lo tanto, podemos concluir que cuando la propiedad se establece en stateUnspecified, el sistema no muestra el teclado en pantalla de forma predeterminada, pero cuando la interfaz del cuadro de entrada enfocado necesita desplazarse, el teclado en pantalla aparecerá automáticamente. En cuanto a por qué es necesario enfatizar el cuadro de entrada que necesita obtener el enfoque, esto se debe a que si el cuadro de entrada no obtiene el enfoque, el teclado en pantalla no aparecerá automáticamente. Una de las soluciones para hacer que la interfaz no aparezca automáticamente, el teclado en pantalla está en el archivo xml , Configure un cuadro de control sin entrada para obtener el enfoque, evitando así que el teclado aparezca.
2.stateUnchanged
中文的意思就是状态不改变的意思，我们应该怎么理解这句话呢？其实很好理解，就是说，当前界面的软键盘状态，取决于上一个界面的软键盘状态。举个例子，假如当前界面键盘是隐藏的，那么跳转之后的界面，软键盘也是隐藏的；如果当前界面是显示的，那么跳转之后的界面，软键盘也是显示状态。
3.stateHidden
顾名思义，如果我们设置了这个属性，那么键盘状态一定是隐藏的，不管上个界面什么状态，也不管当前界面有没有输入的需求，反正就是不显示。因此，我们可以设置这个属性，来控制软键盘不自动的弹出。
4.stateAlwaysHidden
这个属性也可以让软键盘隐藏，但是我暂时还不知道和stateHidden属性的区别，本来想去stackOverFlow上问一下的，但是，Great Wall，呵呵呵...祝愿病魔早日战胜方校长
5.stateVisible
设置为这个属性，可以将软键盘召唤出来，即使在界面上没有输入框的情况下也可以强制召唤出来。
6.stateAlwaysVisible
这个属性也是可以将键盘召唤出来，但是与stateVisible属性有小小的不同之处。举个例子，当我们设置为stateVisible属性，如果当前的界面键盘是显示的，当我们点击按钮跳转到下个界面的时候，软键盘会因为输入框失去焦点而隐藏起来，当我们再次回到当前界面的时候，键盘这个时候是隐藏的。但是如果我们设置为stateAlwaysVisible，我们跳转到下个界面，软键盘还是隐藏的，但是当我们再次回来的时候，软键盘是会显示出来的。所以，这个Always就解释了这个区别，不管什么情况到达当前界面(正常跳转或者是上一个界面被用户返回)，软键盘都是显示状态。
说到这里，我联想到了上面的stateHidden和stateAlwaysHidden，我估计区别也是这样的，就是说，stateAlwaysHidden无论如何都是隐藏的，但是如果在跳转到下个界面的时候，软键盘被召唤出来了，那么当下个界面被用户返回的时候，键盘应该是不会被隐藏的，但是，我还没有找到能够跳转到下个界面，还让当前界面软键盘不消失的方法，所以暂时不能验证。
7.adjustUnspecified
从这个属性开始，就不是设置软键盘的显示与隐藏模式了，而是设置软键盘与软件的显示内容之间的显示关系。当你跟我们没有设置这个值的时候，这个选项也是默认的设置模式。在这中情况下，系统会根据界面选择不同的模式。如果界面里面有可以滚动的控件，比如ScrowView，系统会减小可以滚动的界面的大小，从而保证即使软键盘显示出来了，也能够看到所有的内容。如果布局里面没有滚动的控件，那么软键盘可能就会盖住一些内容，我们从下面的图中可以看出差别。
没有滚动控件，软键盘下面的布局都被遮挡住了，若想修改，只能隐藏软键盘，然后选择。而且，重点注意一下上面的布局，当我们选择的输入框偏下的时候，上面的标题栏和布局被软键盘顶上去了。记住这个特征，因为后面有个属性和这个的效果不一样。
布局里面有滑动控件，系统会自动的缩小整个界面的大小，因此，我们可以软键盘上面的小区域中显示所有的输入框。
这就是两中显示模式之间的差别。
8.adjustResize
这个属性表示Activity的主窗口总是会被调整大小，从而保证软键盘显示空间。
我们先看显示效果。
注意观察这个上面的标题栏和按钮，设置为adjustResize属性之后，对于没有滑动控件的布局，虽然还是不能选择所有的输入框，但是，窗口的显示方式发生了变化，默认属性时，整个布局是被顶上去了，但是设置为adjustResize属性，布局的位置并没有发生什么变化，这就是最大的区别。
而对于有滑动控件的布局来说，显示效果和默认是一样的。
9.adjustPan
如果设置为这个属性，那么Activity的屏幕大小并不会调整来保证软键盘的空间，而是采取了另外一种策略，系统会通过布局的移动，来保证用户要进行输入的输入框肯定在用户的失业范围里面，从而让用户可以看到自己输入的内容。对于没有滚动控件的布局来说，这个其实就是默认的设置，如果我们选择的位置偏下，上面的标题栏和部分控件会被顶上去。但是对于有滚动控件的布局来说，则不太一样，我们看下面的效果图。
首先，这是软键盘没有弹出的时候，有滚动控件的显示范围，最下面显示的是9.
当我们点击5这个输入框，我们会发现下面的现象。
最上面只能够显示到按钮，标题栏已经不能看到了。
而最下面也只能滑动到8，下面的内容也不能够滑动了。
因此，我们就能够理解这个属性的作用了。
通过以上的实验，我们可以得出结论，如果我们不设置"adjust..."的属性，对于没有滚动控件的布局来说，采用的是adjustPan方式，而对于有滚动控件的布局，则是采用的adjustResize方式。
了解了上面的这些知识之后，我们就可以根据自己的需求设置不同的方式了。而且，关于如何使得界面加载的时候不显示软键盘，我们也有了一个很清楚的认识。
转载来自:http://www.jb51.net/article/56043.htm