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