Android软键盘挡住输入框的终极解决方案
前言
开发做得久了，总免不了会遇到各种坑。
而在android开发的路上，『软键盘挡住了输入框』这个坑，可谓是一个旷日持久的巨坑——来来来，我们慢慢看。
入门篇
最基本的情况，如图所示：在页面底部有一个edittext，如果不做任何处理，那么在软键盘弹出的时候，就有可能会挡住edittext。
对于这种情况的处理其实很简单，只需要在androidmanifest文件中对activity设置：android:windowsoftinputmode的值adjustpan或者adjustresize即可，像这样：
<activity android:name=".mainactivity" android:windowsoftinputmode="adjustpan" > ... </activity>
一般来说，他们都可以解决问题，当然，adjustpan跟adjustresize的效果略有区别。
adjustpan是把整个界面向上平移，使输入框露出，不会改变界面的布局；
adjustresize则是重新计算弹出软键盘之后的界面大小，相当于是用更少的界面区域去显示内容，输入框一般自然也就在内了。
↑↑↑ ok，这只是入门，基本上地球上所有的android工程师都能搞定。
别急，看下面~
加上webview试试看？坑来了……
上面的入门篇中，软键盘是由原生的edittext触发弹出的。而在h5、hybrid几乎已经成为app标配的时候，我们经常还会碰到的情况是：软键盘是由webview中的网页元素所触发弹出的。
情况描述
这时候，情况就会变得复杂了:
首先，页面是非全屏模式的情况下，给activity设置adjustpan会失效。
其次，页面是全屏模式的情况，adjustpan跟adjustresize都会失效。
——解释一下，这里的全屏模式即是页面是全屏的，包括application或activity使用了fullscreen主题、使用了『状态色着色』、『沉浸式状态栏』、『immersive mode』等等——总之，基本上只要是app自己接管了状态栏的控制，就会产生这种问题。
下面这个表格可以简单列举了具体的情况。
为什么说它是个坑？”issue 5497”
上面表格的这种情况并非是google所期望的，理想的情况当然是它们都能正常生效才对——所以这其实是android系统本身的一个bug。
为什么文章开头说这是个坑呢？
——因为这个bug从android1.x时代（2009年）就被报告了，而一直到了如今的android7.0（2016年）还是没有修复……/(ㄒoㄒ)/
可以说这不仅是个坑，而且还是个官方挖的坑~
“issue 5497”，详情传送门 ☞ issue 5497 - android -webview adjustresize windowsoftinputmode breaks when activity is fullscreen - android open source project - issue tracker - google project hosting
当然了，不管坑是谁挖的，最终还是要开发者来解决。
遇到坑之后，有两种方法可以过去：躲，或者填。
躲坑姿势
如前文所示，出现坑的条件是：带有webview的activity使用了全屏模式或者adjustpan模式。
那么躲坑的姿势就很简单了——
如果activity中有webview，就不要使用全屏模式，并且把它的windowsoftinputmode值设为adjustresize就好了嘛
怎么样，是不是很简单？
但总有些时候，是需要全屏模式跟webview兼得的，这时候，躲坑就不行了，我们需要一个新的填坑的姿势。幸好，开发者的智慧是无穷的，这个坑出现了这么多年，还是有人找到了一些解决方案的。
androidbug5497workaround
我个人认为最好的解决方案是这个：androidbug5497workaround，只需要一个神奇的androidbug5497workaround类。
看名字就知道，它是专门用来对付”5497”问题的，使用步骤也是超级简单：
把androidbug5497workaround类复制到项目中
在需要填坑的activity的oncreate方法中添加一句androidbug5497workaround.assistactivity(this)即可。
经过测试，基本在各个android版本上都可用，效果基本与设置了adjustresize相当。
看一个对比图：
来自我厂app的某个使用webview的全屏模式activity页面，从左到右分别是：没有软键盘的样式、软键盘挡住输入框的效果、以及使用androidbug5497workaround之后的最终效果。
它的原理是什么？
这个炫酷androidbug5497workaround类，其实并不是很复杂，只有几十行代码，先贴在这里：
public class androidbug5497workaround {
// for more information, see https://code.google.com/p/android/issues/detail?id=5497
// to use this class, simply invoke assistactivity() on an activity that already has its content view set.
public static void assistactivity (activity activity) {
new androidbug5497workaround(activity);
}
private view mchildofcontent;
private int usableheightprevious;
private framelayout.layoutparams framelayoutparams;
private androidbug5497workaround(activity activity) {
framelayout content = (framelayout) activity.findviewbyid(android.r.id.content);
mchildofcontent = content.getchildat(0);
mchildofcontent.getviewtreeobserver().addongloballayoutlistener(new viewtreeobserver.ongloballayoutlistener() {
public void ongloballayout() {
possiblyresizechildofcontent();
}
});
framelayoutparams = (framelayout.layoutparams) mchildofcontent.getlayoutparams();
}
private void possiblyresizechildofcontent() {
int usableheightnow = computeusableheight();
if (usableheightnow != usableheightprevious) {
int usableheightsanskeyboard = mchildofcontent.getrootview().getheight();
int heightdifference = usableheightsanskeyboard - usableheightnow;
if (heightdifference > (usableheightsanskeyboard/4)) {
// keyboard probably just became visible
framelayoutparams.height = usableheightsanskeyboard - heightdifference;
} else {
// keyboard probably just became hidden
framelayoutparams.height = usableheightsanskeyboard;
}
mchildofcontent.requestlayout();
usableheightprevious = usableheightnow;
}
}
private int computeusableheight() {
rect r = new rect();
mchildofcontent.getwindowvisibledisplayframe(r);
return (r.bottom - r.top);// 全屏模式下： return r.bottom
}
}
代码大致是做了这么几件事：
1.找到activity的根view
看一下入口的代码：
framelayout content = (framelayout) activity.findviewbyid(android.r.id.content); mchildofcontent = content.getchildat(0);
其中，第一行中的android.r.id.content所指的view，是android所有activity界面上开发者所能控制的区域的根view。
如果activity是全屏模式，那么android.r.id.content就是占满全部屏幕区域的。
如果activity是普通的非全屏模式，那么android.r.id.content就是占满除状态栏之外的所有区域。
其他情况，如activity是弹窗、或者7.0以后的分屏样式等，android.r.id.content也是弹窗的范围或者分屏所在的半个屏幕——这些情况较少，就暂且不考虑了。
我们经常用的setcontentview(view view)/setcontent(int layres)其实就是把我们指定的view或者layres放到android.r.id.content里面，成为它的子view。
所以，然后，第二行content.getchildat(0)获取到的mchildofcontent，其实也就是用以获取到我们用setcontentview放进去的view。
2.设置一个listener监听view树变化
mchildofcontent.getviewtreeobserver().addongloballayoutlistener({ //简化了写法
possiblyresizechildofcontent();
});
view.getviewtreeobserver()可以获取一个viewtreeobserver对象——这个对象是一个观察者，专门用以监听当前view树所发生的一些变化。这里所注册的addongloballayoutlistener，就是会在当前的view树的全局布局（globallayout）发生变化、或者其中的view可视状态有变化时，进行通知回调。
——『软键盘弹出』，则是会触发这个事件的一个源。 (软键盘弹出会使globallayout发生变化)
也就是说，现在能监听到『软键盘弹出』的事件了。
3.界面变化之后，获取”可用高度”
当软键盘弹出了之后，接下来的事情是获取改变之后的界面的可用高度（可以被开发者用以显示内容的高度）。
直接看代码：
private int computeusableheight() {
rect rect = new rect();
mchildofcontent.getwindowvisibledisplayframe(rect);
// rect.top其实是状态栏的高度，如果是全屏主题，直接 return rect.bottom就可以了
return (rect.bottom - rect.top);
}
view.getwindowvisibledisplayframe(rect rect)，这行代码能够获取到的rect——就是界面除去了标题栏、除去了被软键盘挡住的部分，所剩下的矩形区域——如图所示，红框中的区域。
rect区域示意图
也可以看出：
rect.top值，其实就是标题栏的高度。（实际上，这也常常被用作为获取标题栏高度的方法）
屏幕高度-rect.bottom，是软键盘的高度。（获取软键盘高度的方法也出现了）
这时，就有：
全屏模式下，可用高度 = rect.bottom
非全屏模式，可用高度 = rect.bottom - rect.top
4.最后一步，重设高度
我们计算出的可用高度，是目前在视觉效果上能看到的界面高度。但当前界面的实际高度是比可用高度要多出一个软键盘的距离的。
所以，最后一步，就是把界面高度置为可用高度——大功告成。
private void possiblyresizechildofcontent() {
int usableheightnow = computeusableheight();
if (usableheightnow != usableheightprevious) {
int usableheightsanskeyboard = mchildofcontent.getrootview().getheight();
int heightdifference = usableheightsanskeyboard - usableheightnow;
if (heightdifference > (usableheightsanskeyboard/4)) {
// keyboard probably just became visible
framelayoutparams.height = usableheightsanskeyboard - heightdifference;
} else {
// keyboard probably just became hidden
framelayoutparams.height = usableheightsanskeyboard;
}
mchildofcontent.requestlayout();
usableheightprevious = usableheightnow;
}
}
上面的代码里添加了一个”heightdifference > (usableheightsanskeyboard/4)”的判断，这是为了去除无谓的干扰。因为能触发ongloballayout事件的原因有很多，不止是软键盘的弹出变化，还包括各种子view的隐藏显示变化等，它们对界面高度的影响有限。加上了这个判断之后，只有界面的高度变化超过1/4的屏幕高度，才会进行重新设置高度，基本能保证代码只响应软键盘的弹出。
总结
总结起来，就是这样：
普通activity（不带webview），直接使用adjustpan或者adjustresize
如果带webview：
a) 如果非全屏模式，可以使用adjustresize
b) 如果是全屏模式，则使用androidbug5497workaround进行处理。
以上所述是小编给大家介绍的android软键盘挡住输入框的终极解决方案，希望对大家有所帮助