软键盘挡住输入框问题的终极解决方案
作者：騰兒飛
鏈接：https://www.jianshu.com/p/306482e17080
來源：簡書
前言
開發(fā)做得久了，總免不了會遇到各種坑。
而在Android開發(fā)的路上，『軟鍵盤擋住了輸入框』這個坑，可謂是一個曠日持久的巨坑——來來來，我們慢慢看。
入門篇
最基本的情況，如圖所示：在頁面底部有一個EditText，如果不做任何處理，那么在軟鍵盤彈出的時候，就有可能會擋住EditText。對于這種情況的處理其實很簡單，只需要在AndroidManifest文件中對activity設置：android:windowSoftInputMode的值adjustPan或者adjustResize即可，像這樣：
<activityandroid:name=".MainActivity"android:windowSoftInputMode="adjustPan" >... </activity>一般來說，他們都可以解決問題，當然，adjustPan跟adjustResize的效果略有區(qū)別。
- adjustPan是把整個界面向上平移，使輸入框露出，不會改變界面的布局；
- adjustResize則是重新計算彈出軟鍵盤之后的界面大小，相當于是用更少的界面區(qū)域去顯示內(nèi)容，輸入框一般自然也就在內(nèi)了。
↑↑↑ OK，這只是入門，基本上地球上所有的Android工程師都能搞定。
別急，看下面~
加上WebView試試看？坑來了……
上面的入門篇中，軟鍵盤是由原生的EditText觸發(fā)彈出的。而在H5、Hybrid幾乎已經(jīng)成為App標配的時候，我們經(jīng)常還會碰到的情況是：軟鍵盤是由WebView中的網(wǎng)頁元素所觸發(fā)彈出的。
情況描述
這時候，情況就會變得復雜了:
——解釋一下，這里的全屏模式即是頁面是全屏的，包括Application或activity使用了Fullscreen主題、使用了『狀態(tài)色著色』、『沉浸式狀態(tài)欄』、『Immersive Mode』等等——總之，基本上只要是App自己接管了狀態(tài)欄的控制，就會產(chǎn)生這種問題。
下面這個表格可以簡單列舉了具體的情況。
為什么說它是個坑？"issue 5497"
上面表格的這種情況并非是Google所期望的，理想的情況當然是它們都能正常生效才對——所以這其實是Android系統(tǒng)本身的一個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
當然了，不管坑是誰挖的，最終還是要開發(fā)者來解決。
遇到坑之后，有兩種方法可以過去：躲，或者填。
躲坑姿勢
如前文所示，出現(xiàn)坑的條件是：帶有WebView的activity使用了全屏模式或者adjustPan模式。
那么躲坑的姿勢就很簡單了——
如果activity中有WebView，就不要使用全屏模式，并且把它的windowSoftInputMode值設為adjustResize就好了嘛
怎么樣，是不是很簡單？?
填坑姿勢
但總有些時候，是需要全屏模式跟WebView兼得的，這時候，躲坑就不行了，我們需要一個新的填坑的姿勢。幸好，開發(fā)者的智慧是無窮的，這個坑出現(xiàn)了這么多年，還是有人找到了一些解決方案的。
AndroidBug5497Workaround
我個人認為最好的解決方案是這個：AndroidBug5497Workaround，只需要一個神奇的AndroidBug5497Workaround類。
看名字就知道，它是專門用來對付"5497"問題的，使用步驟也是超級簡單：
經(jīng)過測試，基本在各個Android版本上都可用，效果基本與設置了adjustResize相當。
它的原理是什么？
這個炫酷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 visibleframeLayoutParams.height = usableHeightSansKeyboard - heightDifference;} else {// keyboard probably just became hiddenframeLayoutParams.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也是彈窗的范圍或者分屏所在的半個屏幕——這些情況較少，就暫且不考慮了。
我們經(jīng)常用的setContentView(View view)/setContent(int layRes)其實就是把我們指定的View或者layRes放到android.R.id.content里面，成為它的子View。
所以，然后，第二行content.getChildAt(0)獲取到的mChildOfContent，其實也就是用以獲取到我們用setContentView放進去的View。
2.設置一個Listener監(jiān)聽View樹變化
mChildOfContent.getViewTreeObserver().addOnGlobalLayoutListener({ //簡化了寫法 possiblyResizeChildOfContent(); });View.getViewTreeObserver()可以獲取一個ViewTreeObserver對象——這個對象是一個觀察者，專門用以監(jiān)聽當前View樹所發(fā)生的一些變化。這里所注冊的addOnGlobalLayoutListener，就是會在當前的View樹的全局布局（GlobalLayout）發(fā)生變化、或者其中的View可視狀態(tài)有變化時，進行通知回調(diào)。
——『軟鍵盤彈出』，則是會觸發(fā)這個事件的一個源。 (軟鍵盤彈出會使GlobalLayout發(fā)生變化)
也就是說，現(xiàn)在能監(jiān)聽到『軟鍵盤彈出』的事件了。
3.界面變化之后，獲取"可用高度"
當軟鍵盤彈出了之后，接下來的事情是獲取改變之后的界面的可用高度（可以被開發(fā)者用以顯示內(nèi)容的高度）。
直接看代碼：
↑也可以看出：
- rect.top值，其實就是標題欄的高度。（實際上，這也常常被用作為獲取標題欄高度的方法）
- 屏幕高度-rect.bottom，是軟鍵盤的高度。（獲取軟鍵盤高度的方法也出現(xiàn)了）
這時，就有：
- 全屏模式下，可用高度 = rect.bottom
- 非全屏模式，可用高度 = rect.bottom - rect.top
4.最后一步，重設高度
我們計算出的可用高度，是目前在視覺效果上能看到的界面高度。但當前界面的實際高度是比可用高度要多出一個軟鍵盤的距離的。
所以，最后一步，就是把界面高度置為可用高度——大功告成。
上面的代碼里添加了一個"heightDifference > (usableHeightSansKeyboard/4)"的判斷，這是為了去除無謂的干擾。因為能觸發(fā)OnGlobalLayout事件的原因有很多，不止是軟鍵盤的彈出變化，還包括各種子View的隱藏顯示變化等，它們對界面高度的影響有限。加上了這個判斷之后，只有界面的高度變化超過1/4的屏幕高度，才會進行重新設置高度，基本能保證代碼只響應軟鍵盤的彈出。
總結(jié)
總結(jié)起來，就是這樣：
- a) 如果非全屏模式，可以使用adjustResize
- b) 如果是全屏模式，則使用AndroidBug5497Workaround進行處理。
OK，以上就是一段關于『軟鍵盤擋住輸入框』的爬坑之旅。
?
轉(zhuǎn)載于:https://www.cnblogs.com/Candicelijx/p/10955411.html
總結(jié)
以上是生活随笔為你收集整理的软键盘挡住输入框问题的终极解决方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
