簡(jiǎn)介面向Android開(kāi)發(fā)者的軟鍵盤(pán)遮擋問(wèn)題技術(shù)文檔以PDF形式系統(tǒng)匯總了5種實(shí)用解法覆蓋登錄、注冊(cè)、多輸入表單等典型場(chǎng)景。文檔首先深入解析系統(tǒng)adjustResize與adjustPan的工作機(jī)制結(jié)合非透明狀態(tài)欄、沉浸式狀態(tài)欄、ScrollView嵌套、全屏模式等條件說(shuō)明各自?xún)?yōu)缺點(diǎn)、注意事項(xiàng)與失效情況隨后介紹fitsSystemWindows屬性、自定義View監(jiān)聽(tīng)鍵盤(pán)狀態(tài)動(dòng)態(tài)調(diào)整布局、第三方庫(kù)等方案并針對(duì)多輸入框場(chǎng)景給出上下滑動(dòng)的處理思路每種方法都配有適用場(chǎng)景和坑點(diǎn)提醒便于開(kāi)發(fā)者按需選型。特別是對(duì)全屏或沉浸式狀態(tài)欄下adjustResize失效的原因、fitsSystemWindows的padding覆蓋問(wèn)題都有清晰說(shuō)明。資源為單個(gè)PDF文件包體約1004KB可離線(xiàn)查閱已有2533人學(xué)習(xí)下載適合初、中級(jí)Android開(kāi)發(fā)者在需要優(yōu)化輸入體驗(yàn)時(shí)參考。 搞Android開(kāi)發(fā)的人十個(gè)里得有九個(gè)被軟鍵盤(pán)坑過(guò)。你以為改個(gè)windowSoftInputMode就完事了結(jié)果在不同機(jī)型上跑出來(lái)完全兩種效果有的輸入框被頂上去了有的界面直接變形還有的鍵盤(pán)干脆把整個(gè)布局蓋死提交按鈕怎么也夠不著。這個(gè)問(wèn)題看著小處理不好特別影響體驗(yàn)尤其是登錄、聊天、評(píng)論這類(lèi)強(qiáng)輸入場(chǎng)景用戶(hù)一打字就被擋住第一反應(yīng)就是卸載。這篇文章我把實(shí)際項(xiàng)目中驗(yàn)證過(guò)的五種方法整理出來(lái)了從最基本的windowSoftInputMode配置到ScrollView包裹、底部輸入欄動(dòng)態(tài)補(bǔ)償、沉浸式布局適配再到應(yīng)急用的DecorView強(qiáng)制resize方案每種方法都會(huì)說(shuō)明原理、適用場(chǎng)景、完整步驟和踩坑點(diǎn)。不管你是剛接觸Android沒(méi)多久的新手還是被鍵盤(pán)遮擋問(wèn)題折磨過(guò)的老開(kāi)發(fā)都可以在這篇文章里找到對(duì)應(yīng)的解法。1. 先搞清楚軟鍵盤(pán)遮擋的根本原因別急著搜代碼1.1 鍵盤(pán)彈出本質(zhì)上是一次窗口尺寸變化很多人一遇到鍵盤(pán)遮擋輸入框第一反應(yīng)就是上網(wǎng)復(fù)制一段代碼貼上去結(jié)果要么沒(méi)效果要么引入了新的布局問(wèn)題。我建議你先停下來(lái)想明白一件事軟鍵盤(pán)彈出時(shí)系統(tǒng)到底對(duì)你的Activity做了什么。在Android里鍵盤(pán)彈出導(dǎo)致的界面行為本質(zhì)上是系統(tǒng)在調(diào)整應(yīng)用窗口的可見(jiàn)區(qū)域。當(dāng)windowSoftInputMode配置為adjustResize時(shí)系統(tǒng)會(huì)壓縮Activity的可用高度然后重新觸發(fā)布局當(dāng)配置為adjustPan時(shí)系統(tǒng)不壓縮窗口而是直接平移整個(gè)窗口內(nèi)容把焦點(diǎn)所在控件盡量頂?shù)芥I盤(pán)上方。所以這個(gè)問(wèn)題的本質(zhì)不是鍵盤(pán)擋住了輸入框而是窗口尺寸變了之后你的布局沒(méi)有按照預(yù)期的邏輯重新擺放。你的布局根節(jié)點(diǎn)如果是LinearLayout壓縮后高度變小底部?jī)?nèi)容自然被頂出屏幕如果根布局是ScrollView內(nèi)容是可以滾動(dòng)的輸入框大概率能通過(guò)滾動(dòng)顯現(xiàn)出來(lái)如果你用了adjustPan但界面是復(fù)雜層級(jí)平移效果就會(huì)非常奇怪。1.2 為什么同一個(gè)配置在不同手機(jī)上表現(xiàn)不一樣這是最讓人頭疼的地方。同樣的代碼在原生安卓8上正常在國(guó)產(chǎn)定制系統(tǒng)上就失靈。原因有兩點(diǎn)第一部分國(guó)產(chǎn)ROM對(duì)鍵盤(pán)彈出有自己的窗口管理邏輯系統(tǒng)級(jí)的adjustResize觸發(fā)時(shí)機(jī)不穩(wěn)定甚至個(gè)別系統(tǒng)版本會(huì)忽略應(yīng)用配置的adjustResize標(biāo)記。第二如果你的Activity啟用了WindowTranslucentStatus或WindowTranslucentNavigation這類(lèi)沉浸式窗口特性adjustResize的行為就會(huì)被進(jìn)一步干擾鍵盤(pán)彈出時(shí)系統(tǒng)可能只resize了一部分區(qū)域?qū)е螺斎肟蛞廊槐簧w住。所以我的建議是不要只依賴(lài)系統(tǒng)配置優(yōu)先考慮布局層面的適配。系統(tǒng)配置是基礎(chǔ)布局結(jié)構(gòu)才是決定性的。接下來(lái)每種方法我都會(huì)把這兩個(gè)層面的處理一起來(lái)講。2. 方法一windowSoftInputMode配置——最基礎(chǔ)的手段也最容易用錯(cuò)2.1 adjustResize和adjustPan到底怎么選先說(shuō)結(jié)論如果你的界面是可滾動(dòng)的ScrollView、RecyclerView、NestedScrollView等用adjustResize最合適如果界面是固定布局、沒(méi)有滾動(dòng)容器且只有一個(gè)輸入框在屏幕中上部可以用adjustPan。adjustResize的意思是鍵盤(pán)彈出時(shí)系統(tǒng)把窗口的高度縮小然后重新調(diào)用onMeasure和onLayout。如果你的布局能夠響應(yīng)高度變化比如底部控件設(shè)置了alignParentBottom或者整個(gè)頁(yè)面是ScrollView輸入框就能通過(guò)滾動(dòng)露出來(lái)。adjustPan則不做尺寸壓縮而是直接平移整個(gè)窗口。它的實(shí)現(xiàn)比較粗糙遇到復(fù)雜的相對(duì)布局經(jīng)常把不該頂上去的內(nèi)容也頂上去視覺(jué)上很突兀。我一般建議凡是能不用adjustPan就別用。它適合那些極其簡(jiǎn)單、只有一個(gè)EditText、不需要多控件聯(lián)動(dòng)的頁(yè)面。實(shí)際項(xiàng)目中這種頁(yè)面太少了所以adjustPan更多時(shí)候是備選方案。2.2 配置了沒(méi)效果多半是這幾個(gè)原因你可能會(huì)遇到這種情況明明在AndroidManifest.xml里給Activity配了android:windowSoftInputModeadjustResize結(jié)果鍵盤(pán)一彈輸入框照樣被擋住。第一個(gè)原因是你的Activity對(duì)象是AppCompatActivity而且布局根節(jié)點(diǎn)是CoordinatorLayout或者ConstraintLayout這兩個(gè)容器在某些版本下對(duì)高度變化的傳遞是滯后的尤其當(dāng)你使用了fitsSystemWindowstrue時(shí)系統(tǒng)會(huì)把resize后的高度和狀態(tài)欄高度混在一起算結(jié)果就是布局沒(méi)有按預(yù)期壓縮。第二個(gè)原因是主題配置。如果你在主題里設(shè)置了windowFullscreentrue或者windowNoTitletrue在某些系統(tǒng)版本上adjustResize會(huì)失效。解決方法是不要直接開(kāi)全屏而是用WindowInsets去隱藏狀態(tài)欄。第三個(gè)原因是很多開(kāi)發(fā)者喜歡在onCreate里對(duì)根布局動(dòng)態(tài)做高度賦值比如ViewGroup.LayoutParams.MATCH_PARENT。這個(gè)操作沒(méi)問(wèn)題但如果你在鍵盤(pán)彈出后又手動(dòng)修改了布局高度就會(huì)和系統(tǒng)的resize形成競(jìng)爭(zhēng)最終行為不可預(yù)測(cè)。!-- AndroidManifest.xml 中的Activity配置示例 -- activity android:name.MainActivity android:windowSoftInputModeadjustResize /如果你確認(rèn)了這三個(gè)問(wèn)題都不存在adjustResize還是沒(méi)效果那直接跳到方法三用手動(dòng)監(jiān)聽(tīng)鍵盤(pán)高度去補(bǔ)償那是最穩(wěn)的。3. 方法二用ScrollView/NestedScrollView包一層讓輸入框自己滾上來(lái)3.1 核心思想可滾動(dòng)容器天然適應(yīng)鍵盤(pán)如果你的頁(yè)面不是聊天那種底部固定輸入欄而是表單、發(fā)布頁(yè)這類(lèi)內(nèi)容式布局我的建議是直接把根布局換成ScrollView或NestedScrollView配合adjustResize。原理不復(fù)雜窗口高度被鍵盤(pán)壓縮后ScrollView的內(nèi)容高度依然大于可視高度它就會(huì)變成可滾動(dòng)狀態(tài)。用戶(hù)點(diǎn)擊輸入框時(shí)輸入框會(huì)自動(dòng)滾動(dòng)到可見(jiàn)區(qū)域而且系統(tǒng)還會(huì)自動(dòng)把你焦點(diǎn)所在的位置滾動(dòng)到鍵盤(pán)上方體驗(yàn)非常自然。實(shí)際項(xiàng)目里我更推薦NestedScrollView而不是老舊的ScrollView原因是它能更好地配合AppBarLayout、RecyclerView這些現(xiàn)代組件做嵌套滾動(dòng)而且對(duì)adjustResize的高度變化響應(yīng)更及時(shí)。!-- NestedScrollView包裹表單布局的典型結(jié)構(gòu) -- androidx.core.widget.NestedScrollView android:layout_widthmatch_parent android:layout_heightmatch_parent android:fillViewporttrue LinearLayout android:layout_widthmatch_parent android:layout_heightwrap_content android:orientationvertical !-- 一堆輸入控件 -- EditText ... / Button ... / /LinearLayout /androidx.core.widget.NestedScrollViewfillViewport這個(gè)屬性要記住設(shè)成true否則當(dāng)布局內(nèi)容高度小于屏幕高度時(shí)NestedScrollView里的子布局只有wrap_content高度底部會(huì)露出一片空白或者背景色。3.2 實(shí)操中的坑焦點(diǎn)滾動(dòng)不完全用ScrollView方案時(shí)有一個(gè)很典型的坑鍵盤(pán)彈出后輸入框確實(shí)滾上來(lái)了但滾動(dòng)位置不對(duì)輸入框只露了一半另一半還是被鍵盤(pán)遮住。這個(gè)問(wèn)題的根因是焦點(diǎn)滾動(dòng)發(fā)生在窗口resize之前。你可以給輸入框設(shè)置android:scrollbarStyle或者在代碼里做一次延遲滾動(dòng)editText.setOnFocusChangeListener((v, hasFocus) - { if (hasFocus) { v.postDelayed(() - { Rect rect new Rect(); editText.getWindowVisibleDisplayFrame(rect); int[] location new int[2]; editText.getLocationInWindow(location); int bottom location[1] editText.getHeight(); int visibleBottom rect.bottom; if (bottom visibleBottom) { scrollView.smoothScrollBy(0, bottom - visibleBottom 20); } }, 200); } });本質(zhì)上就是等鍵盤(pán)完全彈出后再手動(dòng)計(jì)算輸入框底部和可視區(qū)域的差距做一次scrollBy覆蓋系統(tǒng)的滾動(dòng)。這里還有一個(gè)隱藏細(xì)節(jié)getLocationInWindow獲取的是相對(duì)窗口的坐標(biāo)不是相對(duì)屏幕的。如果Activity本身處于分屏或者懸浮窗狀態(tài)坐標(biāo)會(huì)有偏差但你用getWindowVisibleDisplayFrame去算可視區(qū)域就不會(huì)差太多。我的實(shí)際經(jīng)驗(yàn)是NestedScrollView方案對(duì)大多數(shù)內(nèi)容式頁(yè)面已經(jīng)夠用。但如果你用的是RecyclerView作為根布局還需要額外處理在RecyclerView外部包一層NestedScrollView并設(shè)置RecyclerView.setNestedScrollingEnabled(false)否則在鍵盤(pán)彈出時(shí)RecyclerView內(nèi)部滾動(dòng)會(huì)和外層NestedScrollView搶滾動(dòng)事件體驗(yàn)很割裂。4. 方法三底部輸入欄專(zhuān)項(xiàng)處理——聊天、評(píng)論場(chǎng)景的正確姿勢(shì)4.1 為什么底部固定輸入框用adjustPan會(huì)翻車(chē)如果你的頁(yè)面是聊天、評(píng)論區(qū)、直播彈幕那種底部固定輸入欄上面是一堆列表內(nèi)容這時(shí)候用adjustPan極其痛苦——鍵盤(pán)一彈整個(gè)頁(yè)面被平移頂部?jī)?nèi)容劃過(guò)屏幕底部輸入欄雖然可能被頂上來(lái)但列表和輸入欄的視覺(jué)關(guān)系完全錯(cuò)位。這種情況的標(biāo)準(zhǔn)解法是adjustResize 動(dòng)態(tài)監(jiān)聽(tīng)鍵盤(pán)高度 給底部容器設(shè)置paddingBottom。4.2 用OnGlobalLayoutListener監(jiān)聽(tīng)鍵盤(pán)高度我的做法是在onCreate里給根布局注冊(cè)一個(gè)ViewTreeObserver.OnGlobalLayoutListener每次布局變化時(shí)判斷鍵盤(pán)是否彈出并記錄鍵盤(pán)高度。private boolean isKeyboardVisible; private int keyboardHeight; private ViewTreeObserver.OnGlobalLayoutListener globalLayoutListener new ViewTreeObserver.OnGlobalLayoutListener() { Override public void onGlobalLayout() { Rect r new Rect(); rootView.getWindowVisibleDisplayFrame(r); int screenHeight rootView.getRootView().getHeight(); int heightDiff screenHeight - r.bottom; if (heightDiff dp2px(100)) { // 鍵盤(pán)彈出 if (!isKeyboardVisible) { isKeyboardVisible true; keyboardHeight heightDiff; applyKeyboardHeight(true); } } else { // 鍵盤(pán)收起 if (isKeyboardVisible) { isKeyboardVisible false; keyboardHeight 0; applyKeyboardHeight(false); } } } };100dp這個(gè)閾值要注意有些手機(jī)底部有手勢(shì)導(dǎo)航條靜止?fàn)顟B(tài)下的heightDiff也可能有幾十像素閾值太小了會(huì)誤判。這也是我在多個(gè)機(jī)型上踩完坑調(diào)試出來(lái)的經(jīng)驗(yàn)值。4.3 paddingBottom補(bǔ)償法的完整代碼拿到鍵盤(pán)高度后直接給底部輸入欄容器設(shè)置paddingBottom輸入欄就會(huì)“懸浮”在鍵盤(pán)上方。private void applyKeyboardHeight(boolean show) { ViewGroup.MarginLayoutParams params (ViewGroup.MarginLayoutParams) bottomBar.getLayoutParams(); if (show) { params.bottomMargin keyboardHeight; } else { params.bottomMargin 0; } bottomBar.setLayoutParams(params); }你可能會(huì)問(wèn)為什么不用layoutParams.height加到輸入欄原有高度上而要用paddingBottom因?yàn)楹芏噍斎霗谑怯斜尘吧闹苯痈母叨葧?huì)把背景拉得很長(zhǎng)看著不協(xié)調(diào)。paddingBottom改的是內(nèi)容區(qū)高度背景區(qū)域跟著整體變大但輸入按鈕、EditText這些子控件的排版不會(huì)變視覺(jué)上只是輸入欄整體被頂高了一截正好等于鍵盤(pán)高度觀感是最好的。另外如果你的輸入欄本身有背景圓角或者陰影加paddingBottom之后背景會(huì)覆蓋鍵盤(pán)頂部區(qū)域這其實(shí)是想要的視覺(jué)效果輸入欄和鍵盤(pán)連成一片更貼近iOS樣式。但如果你的鍵盤(pán)是深色模式背景色不匹配視覺(jué)上會(huì)形成一條明顯的分界色帶這種情況可以考慮給鍵盤(pán)頂部加一條和輸入欄背景同色的線(xiàn)。還有一個(gè)細(xì)節(jié)需要緩存keyboardHeight如果每次布局變化都重新計(jì)算并設(shè)置會(huì)造成界面抖動(dòng)視覺(jué)效果很差。5. 方法四沉浸式布局下的軟鍵盤(pán)問(wèn)題——fitsSystemWindows的坑與解法5.1 沉浸式布局為什么讓鍵盤(pán)問(wèn)題更嚴(yán)重現(xiàn)在的應(yīng)用基本都會(huì)做沉浸式就是讓內(nèi)容延伸到狀態(tài)欄和導(dǎo)航欄下方整體更美觀。但沉浸式布局和軟鍵盤(pán)簡(jiǎn)直是天敵組合。正常模式下系統(tǒng)給窗口的可用區(qū)域已經(jīng)扣除狀態(tài)欄和導(dǎo)航欄adjustResize壓縮時(shí)計(jì)算相對(duì)正確。一旦啟用沉浸式窗口本身就延伸到狀態(tài)欄后面adjustResize的計(jì)算起點(diǎn)變了再加上fitsSystemWindows在不同父容器上的行為不一致結(jié)果就是鍵盤(pán)彈出后輸入框被頂?shù)搅艘粋€(gè)預(yù)料之外的位置。我自己遇到過(guò)最典型的情況用CoordinatorLayout作為根布局設(shè)置了fitsSystemWindowstrue鍵盤(pán)彈起后界面上方多了一塊黑色區(qū)域下方輸入框照樣被蓋住排查了很久才發(fā)現(xiàn)是系統(tǒng)狀態(tài)欄和resize邏輯在打架。5.2 一個(gè)通用的鍵盤(pán)監(jiān)聽(tīng)工具類(lèi)遇到這種情況我建議拋開(kāi)系統(tǒng)resize邏輯直接用代碼做全局補(bǔ)償。你可以把監(jiān)聽(tīng)器掛到DecorView上因?yàn)镈ecorView是整個(gè)窗口的根節(jié)點(diǎn)它收到的布局變化是最準(zhǔn)確的。public class KeyBoardHeightHelper { private final View mRootView; private final OnKeyBoardVisibledListener mListener; private boolean mIsKeyBoardVisible; public KeyBoardHeightHelper(View rootView, OnKeyBoardVisibledListener listener) { this.mRootView rootView; this.mListener listener; mRootView.getViewTreeObserver().addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() { Override public void onGlobalLayout() { checkKeyBoardState(); } }); } private void checkKeyBoardState() { Rect rect new Rect(); mRootView.getWindowVisibleDisplayFrame(rect); int visibleHeight rect.height(); // 假設(shè)鍵盤(pán)收起時(shí)可視高度接近根視圖高度 if (visibleHeight mRootView.getHeight() - dp2px(100)) { if (!mIsKeyBoardVisible) { mIsKeyBoardVisible true; int keyboardHeight mRootView.getHeight() - visibleHeight - getNavBarHeight(); mListener.onKeyBoardVisibled(keyboardHeight); } } else { if (mIsKeyBoardVisible) { mIsKeyBoardVisible false; mListener.onKeyBoardDismiss(); } } } }這套邏輯在沉浸式布局下依然穩(wěn)定因?yàn)樗灰蕾?lài)系統(tǒng)是否觸發(fā)resize而是直接監(jiān)聽(tīng)可視區(qū)域的高度變化。拿到高度后你可以動(dòng)態(tài)給底部菜單、發(fā)送按鈕區(qū)域設(shè)置bottomMargin或者給整個(gè)內(nèi)容區(qū)的paddingBottom加高。5.3 別忘了導(dǎo)航欄高度沉浸式布局里還有一個(gè)容易被忽視的點(diǎn)windowVisibleDisplayFrame的可視區(qū)域高度已經(jīng)避開(kāi)了導(dǎo)航欄。如果用戶(hù)在手機(jī)啟用了手勢(shì)導(dǎo)航底部還會(huì)有一塊手勢(shì)條區(qū)域。你的鍵盤(pán)高度如果直接用rootView.getHeight() - visibleHeight去算會(huì)把導(dǎo)航欄高度也包含進(jìn)去導(dǎo)致輸入欄被頂?shù)锰叩撞柯冻鲆粭l背景。最好在計(jì)算鍵盤(pán)高度時(shí)減掉導(dǎo)航欄高度。先判斷是否存在導(dǎo)航欄再獲取高度然后注冊(cè)一個(gè)OnApplyWindowInsetsListener去動(dòng)態(tài)獲取。這個(gè)思路說(shuō)起來(lái)簡(jiǎn)單但很多項(xiàng)目是在這上面翻過(guò)車(chē)的。6. 方法五應(yīng)急用的DecorView強(qiáng)制resize方案6.1 什么時(shí)候需要用這個(gè)方案有些頁(yè)面實(shí)在太頑固以上方法都試過(guò)之后還有問(wèn)題。比如頁(yè)面里混合了WebView、第三方SDK的彈窗、或者多個(gè)EditText在不同層級(jí)adjustResize完全失效鍵盤(pán)高度監(jiān)聽(tīng)又因?yàn)槟承㏒DK內(nèi)部也修改了窗口布局導(dǎo)致沖突。這時(shí)候我建議用終極方案直接監(jiān)聽(tīng)鍵盤(pán)彈出手動(dòng)修改根布局高度。6.2 這個(gè)方法的核心思路這個(gè)方法的核心不是改layoutParams而是自己模擬一次窗口resize。具體做法是監(jiān)聽(tīng)鍵盤(pán)高度然后把根布局高度強(qiáng)制設(shè)置成“原始高度 - 鍵盤(pán)高度”。// 先在onCreate時(shí)記錄原始高度 private int mRootHeight -1; private void applyRootHeight(boolean isShow, int keyboardHeight) { if (mRootHeight -1) { mRootHeight rootView.getHeight(); } ViewGroup.LayoutParams params rootView.getLayoutParams(); if (isShow) { params.height mRootHeight - keyboardHeight; } else { params.height ViewGroup.LayoutParams.MATCH_PARENT; } rootView.setLayoutParams(params); }注意rootView最好不要是DecorView本身而是你布局文件里的最外層容器。對(duì)DecorView動(dòng)手風(fēng)險(xiǎn)比較高而且很多系統(tǒng)彈窗的邏輯也會(huì)關(guān)聯(lián)到它。6.3 一個(gè)必須避開(kāi)的坑死循環(huán)強(qiáng)制設(shè)置高度是有副作用的你改了高度會(huì)再次觸發(fā)onGlobalLayout然后又進(jìn)入監(jiān)聽(tīng)回調(diào)再改高度形成死循環(huán)。解決思路是加一個(gè)防抖標(biāo)記private boolean isResizing; Override public void onGlobalLayout() { if (isResizing) return; Rect rect new Rect(); rootView.getWindowVisibleDisplayFrame(rect); int visibleHeight rect.height(); if (visibleHeight screenHeight - dp2px(100)) { if (!isKeyBoardShow) { isKeyBoardShow true; isResizing true; applyRootHeight(true, screenHeight - visibleHeight); rootView.post(() - isResizing false); } } else { if (isKeyBoardShow) { isKeyBoardShow false; isResizing true; applyRootHeight(false, 0); rootView.post(() - isResizing false); } } }用post延遲重置標(biāo)志位這樣既能在重置后接受新的狀態(tài)變化又不會(huì)在同一次布局循環(huán)里反復(fù)觸發(fā)高度修改。這個(gè)方案是最后手段有很明顯的局限性你在onCreate里記錄的mRootHeight如果在Activity重建、旋轉(zhuǎn)、多窗口切換時(shí)不在onCreate里重新獲取高度就是錯(cuò)的。所以這些場(chǎng)景下務(wù)必在onResume里重新賦值。7. 五種方法怎么選一個(gè)實(shí)戰(zhàn)向的對(duì)比與建議7.1 適用場(chǎng)景對(duì)比表格方法核心原理最佳使用場(chǎng)景風(fēng)險(xiǎn)點(diǎn)windowSoftInputMode系統(tǒng)級(jí)resize/pan簡(jiǎn)單頁(yè)面、系統(tǒng)樣式的表單頁(yè)碎片化環(huán)境下容易失效ScrollView包裹滾動(dòng)容器適應(yīng)高度長(zhǎng)表單、發(fā)布頁(yè)、設(shè)置頁(yè)滾動(dòng)關(guān)聯(lián)復(fù)雜時(shí)有滾動(dòng)沖突OnGlobalLayoutListener paddingBottom監(jiān)聽(tīng)鍵盤(pán)高度手動(dòng)補(bǔ)償聊天、評(píng)論、底部輸入欄鍵盤(pán)高度計(jì)算要排除導(dǎo)航欄fitsSystemWindows 手動(dòng)補(bǔ)償繞過(guò)系統(tǒng)resize直接處理沉浸式、全屏布局坑多歷史包袱重DecorView強(qiáng)制resize手動(dòng)模擬系統(tǒng)resize混合復(fù)雜布局的應(yīng)急方案容易死循環(huán)要加防抖7.2 我自己項(xiàng)目里的選擇習(xí)慣我做新項(xiàng)目的時(shí)候有個(gè)固定套路能滾動(dòng)的頁(yè)面優(yōu)先用ScrollView方案底部固定輸入欄用OnGlobalLayoutListener監(jiān)聽(tīng)方案沉浸式布局干脆兩個(gè)一起上——最外層監(jiān)聽(tīng)鍵盤(pán)高度 整個(gè)內(nèi)容區(qū)做padding補(bǔ)償。windowSoftInputMode這個(gè)配置我甚至很少改因?yàn)樗淮_定性太強(qiáng)。有一次我在一個(gè)頁(yè)面上把a(bǔ)djustResize改成adjustNothing鍵盤(pán)彈出后輸入框被擋住了但因?yàn)槲矣帽O(jiān)聽(tīng)器做了padding反而界面沒(méi)有任何變化鍵盤(pán)彈收都很自然那之后我越來(lái)越傾向于把布局主動(dòng)權(quán)掌握在自己手里。另外補(bǔ)充一個(gè)很多人不知道的點(diǎn)監(jiān)聽(tīng)鍵盤(pán)高度的時(shí)候如果你在onResume里注冊(cè)監(jiān)聽(tīng)、onPause里銷(xiāo)毀鍵盤(pán)彈出動(dòng)畫(huà)期間觸發(fā)的是中間態(tài)高度會(huì)有一次明顯跳動(dòng)。我后來(lái)都把監(jiān)聽(tīng)放在onCreate里一直掛著直到Activity銷(xiāo)毀才移除中間態(tài)高度雖然也有但因?yàn)殒I盤(pán)彈出很快用戶(hù)肉眼幾乎感知不到。7.3 最后排查鍵盤(pán)問(wèn)題的通用步驟如果你現(xiàn)在手上正好在排查這類(lèi)問(wèn)題我提供一個(gè)通用排查順序確認(rèn)Activity的windowSoftInputMode配置優(yōu)先adjustResize。檢查根布局結(jié)構(gòu)盡量使用可滾動(dòng)容器或通過(guò)padding方式補(bǔ)償。檢查是否有沉浸式標(biāo)記或第三方SDK修改了窗口屬性。用adb shell dumpsys window查看當(dāng)前窗口是否有softInputMode和resize相關(guān)的異常信息。真機(jī)多機(jī)型測(cè)試不要只在模擬器上驗(yàn)證國(guó)產(chǎn)ROM的差異超出你想象。我在實(shí)際開(kāi)發(fā)中還有一個(gè)習(xí)慣就是鍵盤(pán)相關(guān)的邏輯盡量收斂到一個(gè)工具類(lèi)里不要散落在各個(gè)Activity的onGlobalLayout回調(diào)中。工具類(lèi)會(huì)在內(nèi)部處理高度緩存、防抖、生命周期自動(dòng)注銷(xiāo)這種定式比每次臨時(shí)寫(xiě)一遍要穩(wěn)得多也更容易復(fù)用。最后想說(shuō)的是軟鍵盤(pán)問(wèn)題沒(méi)有一個(gè)代碼模板能覆蓋所有場(chǎng)景。真正有用的是理解了鍵盤(pán)彈出和窗口布局的關(guān)系再根據(jù)你頁(yè)面的具體結(jié)構(gòu)去選對(duì)應(yīng)的姿勢(shì)。用對(duì)一次就能在后續(xù)項(xiàng)目里少踩很多坑。本文還有配套的精品資源點(diǎn)擊獲取