前言

開發(fā)做得久了，總免不了會遇到各種坑沥寥。
而在Android開發(fā)的路上，『軟鍵盤擋住了輸入框』這個坑柠座，可謂是一個曠日持久的巨坑——來來來邑雅，我們慢慢看。

入門篇

Base

最基本的情況妈经，如圖所示：在頁面底部有一個EditText淮野，如果不做任何處理，那么在軟鍵盤彈出的時候吹泡，就有可能會擋住EditText骤星。
對于這種情況的處理其實很簡單，只需要在AndroidManifest文件中對activity設(shè)置：android:windowSoftInputMode的值adjustPan或者adjustResize即可爆哑，像這樣：

<activity
    android:name=".MainActivity"
    android:windowSoftInputMode="adjustPan"  >
    ...
</activity>

一般來說洞难，他們都可以解決問題，當(dāng)然揭朝，adjustPan跟adjustResize的效果略有區(qū)別队贱。

• adjustPan是把整個界面向上平移色冀，使輸入框露出，不會改變界面的布局柱嫌；
• adjustResize則是重新計算彈出軟鍵盤之后的界面大小锋恬，相當(dāng)于是用更少的界面區(qū)域去顯示內(nèi)容，輸入框一般自然也就在內(nèi)了慎式。

↑↑↑ OK伶氢，這只是入門，基本上地球上所有的Android工程師都能搞定瘪吏。

別急癣防，看下面~

加上WebView試試看？坑來了……

上面的入門篇中掌眠，軟鍵盤是由原生的EditText觸發(fā)彈出的蕾盯。而在H5、Hybrid幾乎已經(jīng)成為App標配的時候蓝丙，我們經(jīng)常還會碰到的情況是：軟鍵盤是由WebView中的網(wǎng)頁元素所觸發(fā)彈出的级遭。

情況描述

這時候，情況就會變得復(fù)雜了:

1. 首先渺尘，頁面是非全屏模式的情況下挫鸽，給activity設(shè)置adjustPan會失效。
2. 其次鸥跟，頁面是全屏模式的情況丢郊，adjustPan跟adjustResize都會失效。

——解釋一下医咨，這里的全屏模式即是頁面是全屏的枫匾，包括Application或activity使用了Fullscreen主題、使用了『狀態(tài)色著色』拟淮、『沉浸式狀態(tài)欄』干茉、『Immersive Mode』等等——總之，基本上只要是App自己接管了狀態(tài)欄的控制很泊，就會產(chǎn)生這種問題角虫。

下面這個表格可以簡單列舉了具體的情況。

表格

為什么說它是個坑撑蚌？"issue 5497"

上面表格的這種情況并非是Google所期望的上遥，理想的情況當(dāng)然是它們都能正常生效才對——所以這其實是Android系統(tǒng)本身的一個BUG。

為什么文章開頭說這是個坑呢争涌？
——因為這個BUG從Android1.x時代（2009年）就被報告了粉楚，而一直到了如今的Android7.0（2016年）還是沒有修復(fù)……/(ㄒoㄒ)/

可以說這不僅是個坑，而且還是個官方挖的坑~

"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就好了嘛

怎么樣单默，是不是很簡單？??

20130927092846557

填坑姿勢

但總有些時候忘瓦，是需要全屏模式跟WebView兼得的搁廓，這時候，躲坑就不行了耕皮，我們需要一個新的填坑的姿勢境蜕。幸好，開發(fā)者的智慧是無窮的凌停，這個坑出現(xiàn)了這么多年粱年，還是有人找到了一些解決方案的。

AndroidBug5497Workaround

我個人認為最好的解決方案是這個：AndroidBug5497Workaround罚拟，只需要一個神奇的AndroidBug5497Workaround類逼泣。

看名字就知道，它是專門用來對付"5497"問題的舟舒，使用步驟也是超級簡單：

1. 把AndroidBug5497Workaround類復(fù)制到項目中
2. 在需要填坑的activity的onCreate方法中添加一句AndroidBug5497Workaround.assistActivity(this)即可。

經(jīng)過測試嗜憔，基本在各個Android版本上都可用秃励，效果基本與設(shè)置了adjustResize相當(dāng)。
看一個對比圖：

效果對比圖

來自我廠App的某個使用WebView的全屏模式Activity頁面吉捶，從左到右分別是：沒有軟鍵盤的樣式夺鲜、軟鍵盤擋住輸入框的效果、以及使用AndroidBug5497Workaround之后的最終效果呐舔。

它的原理是什么币励？

這個炫酷AndroidBug5497Workaround類，其實并不是很復(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也是彈窗的范圍或者分屏所在的半個屏幕——這些情況較少，就暫且不考慮了编整。

我們經(jīng)常用的setContentView(View view)/setContent(int layRes)其實就是把我們指定的View或者layRes放到android.R.id.content里面舔稀，成為它的子View。

所以闹击，然后镶蹋，第二行content.getChildAt(0)獲取到的mChildOfContent，其實也就是用以獲取到我們用setContentView放進去的View赏半。

2.設(shè)置一個Listener監(jiān)聽View樹變化

mChildOfContent.getViewTreeObserver().addOnGlobalLayoutListener({ //簡化了寫法
        possiblyResizeChildOfContent();
});

View.getViewTreeObserver()可以獲取一個ViewTreeObserver對象——這個對象是一個觀察者贺归，專門用以監(jiān)聽當(dāng)前View樹所發(fā)生的一些變化。這里所注冊的addOnGlobalLayoutListener断箫，就是會在當(dāng)前的View樹的全局布局（GlobalLayout）發(fā)生變化拂酣、或者其中的View可視狀態(tài)有變化時，進行通知回調(diào)仲义。

——『軟鍵盤彈出』婶熬，則是會觸發(fā)這個事件的一個源。

(軟鍵盤彈出會使GlobalLayout發(fā)生變化)

也就是說埃撵，現(xiàn)在能監(jiān)聽到『軟鍵盤彈出』的事件了赵颅。

3.界面變化之后，獲取"可用高度"

當(dāng)軟鍵盤彈出了之后暂刘，接下來的事情是獲取改變之后的界面的可用高度（可以被開發(fā)者用以顯示內(nèi)容的高度）饺谬。
直接看代碼：

    private int computeUsableHeight() {
        Rect rect = new Rect();
        mChildOfContent.getWindowVisibleDisplayFrame(rect);
        // rect.top其實是狀態(tài)欄的高度，如果是全屏主題谣拣，直接 return rect.bottom就可以了
        return (rect.bottom - rect.top);
    }

View.getWindowVisibleDisplayFrame(Rect rect)募寨，這行代碼能夠獲取到的Rect——就是界面除去了標題欄、除去了被軟鍵盤擋住的部分森缠，所剩下的矩形區(qū)域——如圖所示拔鹰，紅框中的區(qū)域。

Rect區(qū)域示意圖

↑也可以看出：

• rect.top值贵涵，其實就是標題欄的高度列肢。（實際上恰画，這也常常被用作為獲取標題欄高度的方法）
• 屏幕高度-rect.bottom，是軟鍵盤的高度例书。（獲取軟鍵盤高度的方法也出現(xiàn)了）

這時锣尉，就有：

• 全屏模式下，可用高度

  = rect.bottom

• 非全屏模式决采，可用高度

  = rect.bottom - rect.top

4.最后一步自沧，重設(shè)高度

我們計算出的可用高度，是目前在視覺效果上能看到的界面高度树瞭。但當(dāng)前界面的實際高度是比可用高度要多出一個軟鍵盤的距離的拇厢。
所以，最后一步晒喷，就是把界面高度置為可用高度——大功告成孝偎。

    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)"的判斷，這是為了去除無謂的干擾凉敲。因為能觸發(fā)OnGlobalLayout事件的原因有很多衣盾，不止是軟鍵盤的彈出變化，還包括各種子View的隱藏顯示變化等爷抓，它們對界面高度的影響有限势决。加上了這個判斷之后，只有界面的高度變化超過1/4的屏幕高度蓝撇，才會進行重新設(shè)置高度果复，基本能保證代碼只響應(yīng)軟鍵盤的彈出。

總結(jié)

總結(jié)起來渤昌，就是這樣：

1. 普通Activity（不帶WebView）虽抄，直接使用adjustpan或者adjustResize

2. 如果帶WebView：

   • a) 如果非全屏模式，可以使用adjustResize
   • b) 如果是全屏模式独柑，則使用AndroidBug5497Workaround進行處理迈窟。

OK，以上就是一段關(guān)于『軟鍵盤擋住輸入框』的爬坑之旅忌栅。

有用的鏈接：
https://code.google.com/p/android/issues/detail?id=5497
http://stackoverflow.com/a/19494006
https://developer.android.com/reference/android/view/ViewTreeObserver.html