本文由BarryZhang原創(chuàng)续扔，同時(shí)首發(fā)于diycode.cc、barryzhang.com 钠四，非商業(yè)轉(zhuǎn)載請(qǐng)注明作者和原文鏈接盗扒。
前言
開發(fā)做得久了，總免不了會(huì)遇到各種坑。
而在Android開發(fā)的路上侣灶，『軟鍵盤擋住了輸入框』這個(gè)坑习霹，可謂是一個(gè)曠日持久的巨坑——來來來，我們慢慢看炫隶。
入門篇
最基本的情況淋叶，如圖所示：在頁面底部有一個(gè)EditText，如果不做任何處理伪阶，那么在軟鍵盤彈出的時(shí)候煞檩，就有可能會(huì)擋住EditText。
對(duì)于這種情況的處理其實(shí)很簡單栅贴，只需要在AndroidManifest文件中對(duì)activity設(shè)置：android:windowSoftInputMode的值adjustPan或者adjustResize即可斟湃，像這樣：
<activity
android:name=".MainActivity"
android:windowSoftInputMode="adjustPan" >
...
</activity>
一般來說，他們都可以解決問題檐薯，當(dāng)然凝赛，adjustPan跟adjustResize的效果略有區(qū)別。
-
adjustPan是把整個(gè)界面向上平移坛缕，使輸入框露出墓猎，不會(huì)改變界面的布局； -
adjustResize則是重新計(jì)算彈出軟鍵盤之后的界面大小赚楚，相當(dāng)于是用更少的界面區(qū)域去顯示內(nèi)容毙沾，輸入框一般自然也就在內(nèi)了。
↑↑↑ OK宠页，這只是入門左胞，基本上地球上所有的Android工程師都能搞定。
別急举户，看下面~
加上WebView試試看烤宙？坑來了……
上面的入門篇中，軟鍵盤是由原生的EditText觸發(fā)彈出的俭嘁。而在H5躺枕、Hybrid幾乎已經(jīng)成為App標(biāo)配的時(shí)候，我們經(jīng)常還會(huì)碰到的情況是：軟鍵盤是由WebView中的網(wǎng)頁元素所觸發(fā)彈出的兄淫。
情況描述
這時(shí)候屯远，情況就會(huì)變得復(fù)雜了:
- 首先，頁面是
非全屏模式的情況下捕虽，給activity設(shè)置adjustPan會(huì)失效慨丐。 - 其次，頁面是
全屏模式的情況泄私，adjustPan跟adjustResize都會(huì)失效房揭。
——解釋一下备闲，這里的全屏模式即是頁面是全屏的，包括Application或activity使用了Fullscreen主題捅暴、使用了『狀態(tài)色著色』恬砂、『沉浸式狀態(tài)欄』、『Immersive Mode』等等——總之蓬痒，基本上只要是App自己接管了狀態(tài)欄的控制泻骤，就會(huì)產(chǎn)生這種問題。
下面這個(gè)表格可以簡單列舉了具體的情況梧奢。
為什么說它是個(gè)坑狱掂？"issue 5497"
上面表格的這種情況并非是Google所期望的，理想的情況當(dāng)然是它們都能正常生效才對(duì)——所以這其實(shí)是Android系統(tǒng)本身的一個(gè)BUG亲轨。
為什么文章開頭說這是個(gè)坑呢趋惨？
——因?yàn)檫@個(gè)BUG從Android1.x時(shí)代（2009年）就被報(bào)告了，而一直到了如今的Android7.0（2016年）還是沒有修復(fù)……/(ㄒoㄒ)/
可以說這不僅是個(gè)坑惦蚊，而且還是個(gè)官方挖的坑~
"issue 5497"器虾，詳情傳送門 ? Issue 5497 - android -WebView adjustResize windowSoftInputMode breaks when activity is fullscreen - Android Open Source Project - Issue Tracker - Google Project Hosting
當(dāng)然了，不管坑是誰挖的蹦锋，最終還是要開發(fā)者來解決兆沙。
遇到坑之后，有兩種方法可以過去：躲晕粪，或者填挤悉。
躲坑姿勢
如前文所示，出現(xiàn)坑的條件是：帶有WebView的activity使用了全屏模式或者adjustPan模式巫湘。
那么躲坑的姿勢就很簡單了——
如果activity中有WebView，就不要使用全屏模式昏鹃，并且把它的windowSoftInputMode值設(shè)為adjustResize就好了嘛
怎么樣尚氛，是不是很簡單？??
填坑姿勢
但總有些時(shí)候洞渤，是需要全屏模式跟WebView兼得的阅嘶，這時(shí)候，躲坑就不行了载迄，我們需要一個(gè)新的填坑的姿勢讯柔。幸好，開發(fā)者的智慧是無窮的护昧，這個(gè)坑出現(xiàn)了這么多年魂迄，還是有人找到了一些解決方案的。
AndroidBug5497Workaround
我個(gè)人認(rèn)為最好的解決方案是這個(gè)：AndroidBug5497Workaround惋耙，只需要一個(gè)神奇的AndroidBug5497Workaround類捣炬。
看名字就知道熊昌，它是專門用來對(duì)付"5497"問題的，使用步驟也是超級(jí)簡單：
- 把
AndroidBug5497Workaround類復(fù)制到項(xiàng)目中 - 在需要填坑的activity的onCreate方法中添加一句
AndroidBug5497Workaround.assistActivity(this)即可湿酸。
經(jīng)過測試婿屹，基本在各個(gè)Android版本上都可用，效果基本與設(shè)置了adjustResize相當(dāng)推溃。
看一個(gè)對(duì)比圖：
來自我廠App的某個(gè)使用WebView的全屏模式Activity頁面昂利，從左到右分別是：沒有軟鍵盤的樣式、軟鍵盤擋住輸入框的效果铁坎、以及使用AndroidBug5497Workaround之后的最終效果蜂奸。
它的原理是什么？
這個(gè)炫酷AndroidBug5497Workaround類厢呵，其實(shí)并不是很復(fù)雜窝撵，只有幾十行代碼，先貼在這里：
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界面上開發(fā)者所能控制的區(qū)域的根View。
- 如果Activity是
全屏模式寒砖，那么android.R.id.content就是占滿全部屏幕區(qū)域的赐劣。- 如果Activity是普通的
非全屏模式，那么android.R.id.content就是占滿除狀態(tài)欄之外的所有區(qū)域哩都。- 其他情況魁兼，如Activity是彈窗、或者7.0以后的分屏樣式等漠嵌，android.R.id.content也是彈窗的范圍或者分屏所在的半個(gè)屏幕——這些情況較少咐汞，就暫且不考慮了。
我們經(jīng)常用的setContentView(View view)/setContent(int layRes)其實(shí)就是把我們指定的View或者layRes放到android.R.id.content里面儒鹿，成為它的子View化撕。
所以，然后约炎，第二行content.getChildAt(0)獲取到的mChildOfContent植阴，其實(shí)也就是用以獲取到我們用setContentView放進(jìn)去的View。
2.設(shè)置一個(gè)Listener監(jiān)聽View樹變化
mChildOfContent.getViewTreeObserver().addOnGlobalLayoutListener({ //簡化了寫法
possiblyResizeChildOfContent();
});
View.getViewTreeObserver()可以獲取一個(gè)ViewTreeObserver對(duì)象——這個(gè)對(duì)象是一個(gè)觀察者圾浅，專門用以監(jiān)聽當(dāng)前View樹所發(fā)生的一些變化掠手。這里所注冊(cè)的addOnGlobalLayoutListener，就是會(huì)在當(dāng)前的View樹的全局布局（GlobalLayout）發(fā)生變化狸捕、或者其中的View可視狀態(tài)有變化時(shí)喷鸽，進(jìn)行通知回調(diào)。
——『軟鍵盤彈出』府寒，則是會(huì)觸發(fā)這個(gè)事件的一個(gè)源魁衙。 (軟鍵盤彈出會(huì)使GlobalLayout發(fā)生變化)
也就是說报腔，現(xiàn)在能監(jiān)聽到『軟鍵盤彈出』的事件了。
3.界面變化之后剖淀，獲取"可用高度"
當(dāng)軟鍵盤彈出了之后纯蛾，接下來的事情是獲取改變之后的界面的可用高度（可以被開發(fā)者用以顯示內(nèi)容的高度）。
直接看代碼：
private int computeUsableHeight() {
Rect rect = new Rect();
mChildOfContent.getWindowVisibleDisplayFrame(rect);
// rect.top其實(shí)是狀態(tài)欄的高度纵隔，如果是全屏主題翻诉，直接 return rect.bottom就可以了
return (rect.bottom - rect.top);
}
View.getWindowVisibleDisplayFrame(Rect rect)，這行代碼能夠獲取到的Rect——就是界面除去了標(biāo)題欄捌刮、除去了被軟鍵盤擋住的部分碰煌，所剩下的矩形區(qū)域——如圖所示，紅框中的區(qū)域绅作。
↑也可以看出：
- rect.top值芦圾，其實(shí)就是標(biāo)題欄的高度。（實(shí)際上俄认，這也常常被用作為獲取標(biāo)題欄高度的方法）
- 屏幕高度-rect.bottom个少，是軟鍵盤的高度。（獲取軟鍵盤高度的方法也出現(xiàn)了）
這時(shí)眯杏，就有：
-
全屏模式下夜焦，可用高度= rect.bottom - 非
全屏模式，可用高度= rect.bottom - rect.top
4.最后一步岂贩，重設(shè)高度
我們計(jì)算出的可用高度茫经，是目前在視覺效果上能看到的界面高度。但當(dāng)前界面的實(shí)際高度是比可用高度要多出一個(gè)軟鍵盤的距離的萎津。
所以卸伞，最后一步，就是把界面高度置為可用高度——大功告成锉屈。
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;
}
}
上面的代碼里添加了一個(gè)"heightDifference > (usableHeightSansKeyboard/4)"的判斷瞪慧，這是為了去除無謂的干擾。因?yàn)槟苡|發(fā)OnGlobalLayout事件的原因有很多部念，不止是軟鍵盤的彈出變化，還包括各種子View的隱藏顯示變化等氨菇，它們對(duì)界面高度的影響有限儡炼。加上了這個(gè)判斷之后，只有界面的高度變化超過1/4的屏幕高度查蓉，才會(huì)進(jìn)行重新設(shè)置高度乌询，基本能保證代碼只響應(yīng)軟鍵盤的彈出。
總結(jié)
總結(jié)起來豌研，就是這樣：
- 普通Activity（不帶WebView）妹田，直接使用
adjustpan或者adjustResize - 如果帶WebView：
- a) 如果非
全屏模式唬党，可以使用adjustResize - b) 如果是
全屏模式，則使用AndroidBug5497Workaround進(jìn)行處理鬼佣。
- a) 如果非
OK驶拱，以上就是一段關(guān)于『軟鍵盤擋住輸入框』的爬坑之旅。
另外晶衷，希望這篇文章能對(duì)你有所幫助蓝纲。
最近開始整了一個(gè)微信公眾號(hào)，用以分享一些 Android 相關(guān)以及不相關(guān)的干貨晌纫，既然都看到這里了税迷，何不長按/掃碼關(guān)注一下？
【 不只Android】
有用的鏈接：
https://code.google.com/p/android/issues/detail?id=5497
http://stackoverflow.com/a/19494006
https://developer.android.com/reference/android/view/ViewTreeObserver.html
關(guān)于作者 :
http://www.barryzhang.com
https://barryhappy.github.io
