軟鍵盤擋住輸入框問題的終極解決方案

做者:騰兒飛
連接:https://www.jianshu.com/p/306482e17080
來源:簡書java

前言

開發作得久了,總免不了會遇到各類坑。
而在Android開發的路上,『軟鍵盤擋住了輸入框』這個坑,可謂是一個曠日持久的巨坑——來來來,咱們慢慢看。android

入門篇

最基本的狀況,如圖所示:在頁面底部有一個EditText,若是不作任何處理,那麼在軟鍵盤彈出的時候,就有可能會擋住EditText。

對於這種狀況的處理其實很簡單,只須要在AndroidManifest文件中對activity設置:android:windowSoftInputMode的值adjustPan或者adjustResize便可,像這樣:佈局

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

通常來講,他們均可以解決問題,固然,adjustPanadjustResize的效果略有區別。測試

  • adjustPan是把整個界面向上平移,使輸入框露出,不會改變界面的佈局;
  • adjustResize則是從新計算彈出軟鍵盤以後的界面大小,至關因而用更少的界面區域去顯示內容,輸入框通常天然也就在內了。

↑↑↑ OK,這只是入門,基本上地球上全部的Android工程師都能搞定。
別急,看下面~this

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

上面的入門篇中,軟鍵盤是由原生的EditText觸發彈出的。而在H五、Hybrid幾乎已經成爲App標配的時候,咱們常常還會碰到的狀況是:軟鍵盤是由WebView中的網頁元素所觸發彈出的google

狀況描述

這時候,狀況就會變得複雜了:spa

  1. 首先,頁面是非全屏模式的狀況下,給activity設置adjustPan會失效。
  2. 其次,頁面是全屏模式的狀況,adjustPanadjustResize都會失效。

——解釋一下,這裏的全屏模式便是頁面是全屏的,包括Application或activity使用了Fullscreen主題、使用了『狀態色着色』、『沉浸式狀態欄』、『Immersive Mode』等等——總之,基本上只要是App本身接管了狀態欄的控制,就會產生這種問題。code

下面這個表格能夠簡單列舉了具體的狀況。orm

 

爲何說它是個坑?"issue 5497"

上面表格的這種狀況並不是是Google所指望的,理想的狀況固然是它們都能正常生效纔對——因此這實際上是Android系統自己的一個BUG。server

爲何文章開頭說這是個坑呢?
——由於這個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"問題的,使用步驟也是超級簡單:

  1. AndroidBug5497Workaround類複製到項目中
  2. 在須要填坑的activity的onCreate方法中添加一句AndroidBug5497Workaround.assistActivity(this)便可。

通過測試,基本在各個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 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的屏幕高度,纔會進行從新設置高度,基本能保證代碼只響應軟鍵盤的彈出。

總結

總結起來,就是這樣:

  1. 普通Activity(不帶WebView),直接使用adjustpan或者adjustResize
  2. 若是帶WebView:
    • a) 若是非全屏模式,可使用adjustResize
    • b) 若是是全屏模式,則使用AndroidBug5497Workaround進行處理。

OK,以上就是一段關於『軟鍵盤擋住輸入框』的爬坑之旅。

相關文章
相關標籤/搜索