企业官网建设流程全解析

做Android开发这些年，软键盘绝对是最容易让人血压飙升的东西之一。尤其是当页面结构从“一个Activity包一个页面”变成“一个Activity装了好几个Fragment”之后，麻烦就更明显了：你在当前Fragment的输入框里敲字，系统直接按整个Activity的window来调整尺寸，于是相邻Fragment、底部操作栏、甚至顶部的标题栏，全都跟着键盘一起“跳”上去。这篇文章就是来聊这个经典问题的根治思路：让弹出键盘只影响当前正在输入的Fragment，其他兄弟Fragment纹丝不动。从底层原因、方案选型、手写代码，到线上才能踩到的坑，我尽量一次性拆干净。适合正在改造Fragment化页面、或者被键盘弹出“全局搬家”折磨过的Android开发参考。

1. 问题复盘：为什么键盘弹出后，整个界面都跟着遭殃

1.1 现象复现：一个Fragment敲字，整个Activity都被重新布局

先描述一下最典型的场景。应用主页是底部Tab结构，MainActivity持有一个Fragment容器，里面装了首页Fragment、消息Fragment、我的Fragment。每个Fragment都有自己的布局，其中消息Fragment里有一个输入框和一个RecyclerView。这时候你在消息Fragment的输入框里打字，软键盘弹出来，会发生什么？

如果你的Application没有做过特殊处理，默认情况下整个窗口会被压缩。也就是说，首页Fragment、我的Fragment的布局也会被重新测量、重新布局，整个Activity的content区域高度变小了，底部Tab栏会被顶到键盘上方，其他Fragment里的RecyclerView也跟着“缩”了一截。等你收起键盘，布局又变回来。整个过程中页面疯狂跳变，视觉上就是“整个界面都在动”。

很多开发者一开始会把锅甩给Fragment，以为是Fragment的问题，其实这里有个关键认知要纠正：软键盘弹出时，系统调整的是Activity的window，也就是整个窗口，不是某一个Fragment的布局。Fragment在Android里只是一个容器化的视图管理层，它没有自己独立的window，也没有自己的windowSoftInputMode。所以你在任何Fragment里输入，键盘弹出，受影响的永远是这个Activity的整体界面。

1.2 追根究底：windowSoftInputMode跟Fragment没关系

android:windowSoftInputMode这个属性，看名字就知道它作用于window。它放在Activity或主题的配置里，由WindowManager负责解析和执行。它支持的几个值你们都眼熟：adjustResize、adjustPan、adjustNothing、stateHidden、stateAlwaysHidden等，控制的是软键盘弹出和收起时整个window的尺寸或位置怎么变化。

但Fragment并没有类似的属性位。你无法在Fragment上声明“我这个Fragment用adjustResize那个用adjustNothing”，因为所有Fragment都住在同一个window里。这也是问题的根源：系统层面只认window，不认Fragment。

所以，如果你在布局文件里给根布局设置了android:fitsSystemWindows="true"，并且Activity用了adjustResize，那么键盘弹出时，整个window的可用高度变小，系统bars区域和ime区域会通过WindowInsets通知下来，所有子View都会跟着重新布局。没有做过滤的话，无论哪个Fragment在输入，所有Fragment都会响应这次尺寸变化。结果是：A Fragment在输入，B Fragment的布局也“缩水”了，看起来特别奇怪。

1.3 adjustResize和adjustPan的局限

先说说大家最常用的两种模式，以及它们的局限。

adjustResize的思路是：键盘弹出后，系统直接压缩window的可用高度，让布局重新测量。这种方式在单个页面的场景下挺好用：输入框被顶上去，页面底部内容进入键盘上方区域，用户能看清自己输入的内容。但在Fragment多实例共存的场景下，它是“一刀切”，所有Fragment一起resize，并不是只处理当前输入的那个。

adjustPan则更粗暴：键盘弹出后，整个window向上平移，直到焦点View可见为止。这种方式在页面结构简单时也不错，但在ScrollView、RecyclerView、多Fragment组合布局下非常容易产生“页面被顶飞”的问题，而且输入框可能在屏幕中间，导致上半部分完全移出屏幕。也不适合精确控制。

结论就是：如果你想要键盘只影响当前Fragment，就必须跳出系统默认行为，自己接管“键盘高度变化”的通知，然后只对需要变化的Fragment做布局调整。

2. 方案选型：三种主流思路的对比与取舍

2.1 用adjustPan硬扛：治标不治本

最早我试过直接把Activity设置成adjustPan，看看能不能“凑合”用。实测下来，在简单页面还能忍，一旦遇到多Fragment加嵌套滚动布局，问题一堆。

adjustPan做的是对整个window进行平移。假设当前Fragment的EditText位于页面下部，键盘弹出后系统会把整个window往上推，直到EditText可见。由于window整体平移，其他Fragment也跟着移动；而且如果Activity里有自定义的底部栏、悬浮按钮，它们会被一并推到键盘上方，显得非常违和。用adjustPan的时间越长，越觉得这不是在解决问题，只是把问题挪了个地方。

2.2 用adjustResize加全局padding：能用，但误伤队友

有人会想，那我在根布局上监听WindowInsets，然后统一给根布局加paddingBottom，这样不就把键盘高度让出来了吗？可以，但这同样会作用于所有Fragment，不是“只影响当前Fragment”。

如果你只有一个Fragment，这个方案完全够用，没必要搞复杂。但我们的前提是多个Fragment共存，底部的Tab栏通常也需要保持固定。全局padding会导致Tab栏也被顶上去，反而难以控制。所以在多Fragment场景下，目标要拆得很细：全局window不变，只让当前Fragment的内容区域避开键盘。

2.3 用adjustNothing加手动处理：精准、可控、不误伤

最终我选择的路子是：Activity设置adjustNothing，完全关闭系统自动调整能力，然后自己在Fragment层监听输入法高度变化，只对当前可见、正在交互的Fragment做布局填充。

好处很明显：

• 其他Fragment完全不会感知到键盘弹出，布局稳定。
• 当前Fragment可以自由决定怎么处理键盘高度，比如给根布局加padding、给RecyclerView加margin、或者滚动到指定位置。
• 不会和fitsSystemWindows、状态栏透明等复杂情况互相干扰。

缺点也是有的：所有事情都要自己写，而且需要处理Fragment可见性判断、监听器的注册和销毁、低版本兼容这些细节。不过这些细节也就是今天文章的核心。

2.4 三种方案直观对比

3. 核心实现：基于WindowInsets的精准处理

3.1 第一步：在Manifest中关掉系统自动调整

在AndroidManifest.xml里，找到承载Fragment的Activity，把windowSoftInputMode设置为adjustNothing|stateAlwaysHidden。

<activity android:name=".MainActivity" android:windowSoftInputMode="adjustNothing|stateAlwaysHidden" />

stateAlwaysHidden的目的是：进入页面时不要自动弹出键盘，避免启动瞬间的布局抖动。如果你的页面希望进入即聚焦输入框，可以去掉它，但大多数业务场景还是建议保留。

这一步做完之后，你会发现键盘弹出时整个window完全不动了，输入框会被键盘盖住。别慌，这正是我们需要的“不被系统乱改”的初始状态，接下来所有控制都交给自己。

3.2 第二步：用WindowInsetsCompat监听输入法高度

Android 11（API 30）之后，系统提供了稳定的WindowInsets.Type.ime()，可以直接拿到输入法的高度。配合AndroidX里的WindowInsetsCompat，可以在向后兼容的写法里使用。这里要说明一下，我在实际项目里最小支持到API 21，一直用这套写法，没有出现兼容性崩溃，但低版本在个别ROM上拿不会ime insets，需要配合第4节的兜底方案。

核心代码逻辑是在目标Fragment的根布局上注册一个OnApplyWindowInsetsListener，从中取出ime类型的insets高度，然后给根布局设置对应的paddingBottom。

// ViewEditFragment.kt class ViewEditFragment : Fragment() { private var _binding: FragmentViewEditBinding? = null private val binding get() = _binding!! override fun onCreateView( inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle? ): View { _binding = FragmentViewEditBinding.inflate(inflater, container, false) return binding.root } override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) handleImeInsets(view) } private fun handleImeInsets(view: View) { ViewCompat.setOnApplyWindowInsetsListener(view) { v, insets -> // 只处理当前可见且处于Resumed状态的Fragment if (isVisible && isResumed) { val imeInsets = insets.getInsets( WindowInsetsCompat.Type.ime() or WindowInsetsCompat.Type.systemBars() ) v.updatePadding(bottom = imeInsets.bottom) } insets } } override fun onDestroyView() { // 避免View复用后监听器还挂着 ViewCompat.setOnApplyWindowInsetsListener(binding.root, null) _binding = null super.onDestroyView() } }

这段代码的核心就一行：v.updatePadding(bottom = imeInsets.bottom)。当键盘弹出时，imeInsets.bottom就是键盘高度，当前Fragment的根布局底部会增加一块等于键盘高度的padding；键盘收起时imeInsets.bottom变为0，padding自动归零。由于监听器只在当前Fragment的根布局上注册，而且我们加了isVisible && isResumed的判断，所以其他Fragment不会受任何影响。

3.3 第三步：为什么加isVisible和isResumed双重判断

这一步很容易被忽略，但恰恰是“只影响当前Fragment”的关键。

Fragment的onViewCreated注册监听器后，如果Fragment被切换走了，比如被replace、hide、或者放进ViewPager2里切换到了别的页，它的View仍然存在，监听器也不会自动移除。如果不做任何判断，键盘弹出时即使这个Fragment已经不可见，它的根布局也会跟着加padding。虽然用户看不见，但一旦切回来，页面底部会留一大块空白，体验非常差。

所以我在监听器里加了两个条件：

• isVisible：判断Fragment当前是否处于Visible状态，包括它的View是否已经attach且可见。
• isResumed：判断Fragment是否处于Resumed生命周期。在多Fragment叠加、或者需要和Activity交互的场景下，这个判断能过滤掉处于后台、非交互状态的Fragment。

如果你用的是ViewPager2，它默认会预加载相邻Fragment，这些Fragment处于STARTED或CREATED状态，isResumed为false，所以不会被误处理。这是我实测过的最稳妥的双保险。

3.4 第四步：处理底部导航栏和透明状态栏

如果你的页面是沉浸式设计，底部有NavigationBar区域，直接updatePadding(bottom = imeInsets.bottom)会漏掉导航栏的高度。上面代码里我已经做了处理：

val imeInsets = insets.getInsets( WindowInsetsCompat.Type.ime() or WindowInsetsCompat.Type.systemBars() )

把ime和systemBars取或后，取到的header就是两个区域合并后的总高度，imeInsets.bottom里就包含了在窗口底部出现的ime高度和系统导航栏高度。这样即使你的根布局延伸到了导航栏后面，padding也能正确覆盖到底。

这里有个经验之谈：不要单独用WindowInsetsCompat.Type.ime()，因为在高版本Android上，如果页面没有延伸到系统栏后面，ime insets可能不包含导航栏高度，导致底部差一截。合并取一次更稳妥。

4. 兼容方案：没有WindowInsets时的兜底策略

4.1 老版本和碎片化ROM用ViewTreeObserver

WindowInsets.Type.ime()在API 30以上非常好用，但在API 30以下，尤其是一些深度定制的ROM上，拿到的ime insets可能不准，或者根本收不到回调。这时候我建议用传统方案兜底：通过ViewTreeObserver.OnGlobalLayoutListener监听全局布局变化，根据可见显示区域的高度差算出键盘高度。

核心逻辑是：键盘弹出时，window的可见显示区域顶部不变，底部被键盘遮挡，所以可见区域高度变小。用根View的高度减去可见显示区域的bottom，差值就是键盘高度。

class CompatEditFragment : Fragment() { private var _binding: FragmentCompatEditBinding? = null private val binding get() = _binding!! private val globalLayoutListener = ViewTreeObserver.OnGlobalLayoutListener { handleGlobalLayoutChange() } override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) view.viewTreeObserver.addOnGlobalLayoutListener(globalLayoutListener) } private fun handleGlobalLayoutChange() { if (!isVisible || !isResumed) return val rootView = binding.root val rect = Rect() rootView.getWindowVisibleDisplayFrame(rect) val screenHeight = rootView.rootView.height val keyboardHeight = screenHeight - rect.bottom if (keyboardHeight > 0) { binding.root.updatePadding(bottom = keyboardHeight) } else { binding.root.updatePadding(bottom = 0) } } override fun onDestroyView() { binding.root.viewTreeObserver.removeOnGlobalLayoutListener(globalLayoutListener) _binding = null super.onDestroyView() } }

注意，这里我用了一个阈值判断，有些执行者喜欢写成keyboardHeight > screenHeight * 0.15才认为是键盘弹出，避免导航栏、状态栏变化导致误判。具体阈值可以根据页面实际元素调整，我习惯用这个比例，能在绝大多数机器上过滤掉底部导航条的干扰。

这个方案的缺点是每次布局变化都会回调，性能上略吃亏，但只要监听器只挂在当前Fragment，页面结构不复杂，实测完全没问题。如果追求极致流畅，还可以在回调里加一个防抖，避免同一帧内重复设置padding。

4.2 键盘高度缓存：避免每次重复测量

无论用哪种监听方式，键盘高度其实在同一个页面上往往是固定的。与其每次键盘弹出都重新测量、重新计算，不如缓存一下。

我的做法是维护一个全局的KeyboardHeightProvider，用ViewModel或者单例都行，核心是保存键盘高度值。第一次测量到后存起来，后续这次弹起直接使用缓存。

object KeyboardHeightHolder { @Volatile var keyboardHeight: Int = 0 }

在handleImeInsets或者globalLayout回调里，每次拿到imeInsets.bottom时，同步写一下缓存：

if (imeInsets.bottom > 0) { KeyboardHeightHolder.keyboardHeight = imeInsets.bottom }

这样多个Fragment切换时，新Fragment切入瞬间就可以先用缓存高度做布局调整，等监听到最新高度再校正。键盘弹出动画期间也不会出现明显的延迟跳变。

4.3 处理键盘动画中途的“抖动”

还有一种典型问题：键盘弹出过程中，高度是逐渐增加的。如果监听器每帧都触发，padding也就会跟着一帧一帧变，理论上这其实能实现细腻的跟随动画。但在部分低端机上，布局重新测量比键盘动画慢，会出现“界面一抖一抖”的情况。

我踩过这个坑之后，做了一个简单策略：以50毫秒为窗口做节流，每次收到ime高度变化时记录时间戳，如果距离上次处理不到50毫秒就忽略，超过就直接设置padding。这样布局更新的频率会明显减少，绝大多数设备上肉眼看不出差别，但掉帧感会缓解很多。

如果用WindowInsets方案，其实系统已经帮我们做了大部分帧同步，这个问题不太明显；但在ViewTreeObserver兜底方案里，节流是很有必要的。

5. 实操中常见的坑与排查技巧

5.1 问题速查表

5.2 Fragment切换时监听器失效，怎么精准控制

如果你用的是show/hide来切换Fragment，那么被hide的Fragment的isVisible会变为false，监听器里的判断会阻止它做padding，没问题。如果你用的是replace，旧的Fragment会走onDestroyView，我们在onDestroyView里移除了监听器，也清空了binding，没问题。如果你用的是ViewPager2，相邻页面由于预加载机制存在，它们处于可见状态但不在Resumed状态，所以isResumed判断会起到关键作用。这三种情况我都实际验证过，放心用。

还有一个小坑是：Fragment在onCreateView里创建View时，如果它在后台被重建，bind到View上的监听器可能收不到最新的insets。这时候可以在onStart里主动调一下rootView.requestApplyInsets()，强制系统重新下发一次insets。这个操作不会带来明显开销，能避免很多“切回来布局不对”的诡异问题。

5.3 全屏模式和刘海屏的差异

如果Activity是全屏模式，或者decorView设置了systemUiVisibility为沉浸式，WindowInsets的收取方式会发生变化。有些手机上，ime insets会和系统栏insets分开返回，合并获取就更加必要。还有一些机型在全屏下用ViewTreeObserver方案测算时，getWindowVisibleDisplayFrame返回的可见区域顶部可能不是0，计算键盘高度时要用screenHeight - rect.bottom，不要用rect.top参与计算，否则会在刘海屏上多算一块高度。这里不再展开所有case，但记住一条原则：先确保自己页面的fitsSystemWindows和状态栏处理方式在全App是统一的，再叠加键盘逻辑，不然很容易两者相互干扰。

5.4 监听器泄漏和重复注册问题

这个问题最常见的是把OnGlobalLayoutListener加到了Activity的rootView上，然后Activity一直被ViewModel或单例引用，导致无法释放。我强烈建议监听器只注册在Fragment自己的根布局上，并且在onDestroyView里移除。如果某个流程需要在Activity级做统一处理，记得也要在onDestroy里移除。

还有一种重复注册的场景：Fragment的onCreateView被系统重建多次，比如配置变更、进入后台再回前台时View重建。如果你没有在onDestroyView里把监听器置空，新的View会叠加旧的监听器，导致同样的padding被设置两次。设置同一数值倒不至于崩，但如果监听器里还有滚动逻辑，就可能出现“每次弹键盘页面都会跳一下”。所以必须养成在onDestroyView里统一清理绑定的习惯。

5.5 用工具检查布局层级

如果实在排查不出来，我教大家一个土办法：在键盘弹出前后，用Android Studio的Layout Inspector抓两次布局，比对根View的高度和padding差异。这个方法能直接把某个Fragment的padding变化暴露出来，快速定位是哪个监听器在作怪。我排查多个Fragment互相干扰的问题时，基本靠这一招就能锁定目标。

6. 最后分享一点我的使用体验

我目前把adjustNothing加WindowInsets改成默认方案，并把ViewTreeObserver作为低版本兜底，整个方法抽成了一个BaseImeFragment基类，任何Fragment想支持键盘避让，只要继承并传入需要调整的根布局就行。

实际跑了一段时间后，最明显的感受是：以前那种键盘一弹、页面整个“搬家”的体验彻底消失了，只有正在输入的Fragment会做出响应，底部的Tab栏稳定得一笔，用户几乎感受不到其他页面的存在。这套方案不依赖第三方库，也没有魔法，理解原理之后半小时就能写完，稳定性反而比乱七八糟的开源库更可控。

如果你正被类似的Fragment键盘问题困扰，可以按这个思路试一遍。我踩过的那些坑，希望你不需要重新踩一遍。