企业官网建设流程全解析

做Android开发的，十有八九都要跟状态栏和导航栏打交道。尤其到了Android 13，系统全面进入手势导航时代，厂家定制机型又五花八门，控制状态栏和导航栏的显隐、颜色、高度、交互区域，已经从“改几个Flag”变成了“一套Insets体系”。我前阵子正好把几个项目统一迁移到Android 13的适配方案，踩了不少坑，这篇就把状态栏和导航栏控制的完整思路、核心代码、以及调试时容易忽略的细节一次性讲清楚。主要内容围绕android13状态栏导航栏控制展开，包含从系统窗口机制原理，到沉浸模式、底部导航栏控制、动态隐藏与恢复的实操方案，还有我实测过的常见问题和排查思路。内容适合正在做Android 13适配、或者想理解系统级窗口控制机制的开发者参考，不需要你有太多基础，但至少用过Android Studio、写过Java或Kotlin。

1. 先搞清楚状态栏和导航栏控制的几种常见需求

1.1 沉浸模式与全屏切换

我接触的大多数需求，核心都是“让内容延伸到状态栏和导航栏底下”，也就是所谓的沉浸模式。视频播放器、阅读器、拍照界面、游戏，甚至一些带顶部大图详情页的应用，都希望界面看起来更满、更纯粹。

但沉浸模式又分好几种程度：一种是“内容延伸到系统栏下面，但系统栏仍然可见”，这种场景下状态栏通常是半透明或全透明，背景色和内容区域混合，视觉上更融合；另一种是“彻底隐藏系统栏”，等用户点击屏幕或滑动边缘时再短暂唤出，这种通常对应游戏和视频场景。

Android 13之前，很多人习惯用WindowInsetsController.hide()配合WindowInsets.Type.systemBars()来隐藏，或者用systemUiVisibility这个老API。到了Android 13，systemUiVisibility已经彻底废弃，官方推荐统一走WindowInsets。如果你还在用老的View.SYSTEM_UI_FLAG_FULLSCREEN或者View.SYSTEM_UI_FLAG_HIDE_NAVIGATION，编译能过，但实际效果在某些Android 13设备上会直接失效，这点要特别注意。

1.2 控制导航栏按钮显隐

导航栏控制比状态栏更敏感，因为涉及用户最基本的返回、主页、最近任务操作。系统对导航栏的隐藏策略明显更严格，尤其是在非手势导航模式下，三键导航的导航栏一旦隐藏，用户会失去明确的返回入口，所以某些场景下系统会强制保留导航栏，或者在你隐藏后自动重新显示。

我在项目里遇到过的情况主要有几种：

• 底部有横向滑动的轮播图或卡片列表，手指从底部向上滑时想隐藏导航栏，交互完成后再恢复；
• 横屏播放页面，希望底部导航栏隐藏，让视频画面完全铺满；
• 电子签名、拍照取景这类应用，需要排除所有系统干扰。

Android 13的具体表现是：如果你通过systemBars()隐藏全部系统栏，状态栏可以长时间隐藏，但导航栏在用户从底部上滑时必定会重新出现，这是系统级的用户保护机制。实测在手势导航模式下，隐藏导航栏的代码甚至可能不生效，因为Android 13对手势指示条的隐藏策略单独做了控制。

1.3 获取状态栏和导航栏高度

除了显隐控制，另一个高频需求是“获取状态栏和导航栏的高度”。典型场景包括：自定义标题栏要基于状态栏高度做padding、底部按钮区域要避开导航栏高度、对话框要调整位置避免被导航栏遮挡。

Android 13中，导航栏的高度会根据手势导航和三键导航变化。手势导航下，那条“横线指示条”区域的高度一般比三键导航小；而三键导航里的返回、主页、最近任务按钮区域，在设备上如果带物理按键，高度还可能变成0。所以千万别写死某个dp值，必须动态读取。

获取高度最常见的方式是ViewCompat.getRootWindowInsets(window.decorView)，然后getInsets(WindowInsets.Type.navigationBars()).bottom，这种方案在Android 13上依然有效。要注意的是，如果当前导航栏处于隐藏状态，返回的bottom值可能是0，这就意味着拿到的Insets是“当前可见系统栏的区域”，而不是“系统栏实际占用的区域”，两者很容易混淆。

2. Android 13上控制方式的选型与原理拆解

2.1 WindowInsets API 在 Android 13 的机制

Android 13里，系统窗口区域控制的核心是WindowInsetsController。它把系统栏按类型拆分：状态栏对应statusBars()，导航栏对应navigationBars()，两者合起来叫systemBars()。隐藏和显示都是对“类型”做操作，而不是直接对View做操作。

这个机制有个重要特点：Insets是分层的。状态栏和导航栏可以被系统拆分为多个Insets，比如IME键盘也是一个Insets类型（ime()）。当你使用WindowInsets.Type.systemBars()时，如果软键盘已经弹出，系统可能把IME区域也当作系统栏处理，导致界面底部多出一块空白，这也是我实际开发中经常遇到的问题。

Android 13还引入了WindowInsetsController.setSystemBarsBehavior()，用来控制隐藏后用户交互的行为。可取的值包括BEHAVIOR_SHOW_BARS_BY_SWIPE（滑动边缘显示）、BEHAVIOR_SHOW_BARS_BY_TOUCH（点击显示）、以及BEHAVIOR_DEFAULT。配合隐藏系统栏时，如果你希望用户轻扫系统栏区域才显示，就设置BEHAVIOR_SHOW_BARS_BY_SWIPE；如果希望点击任意区域就显示，就设置BEHAVIOR_SHOW_BARS_BY_TOUCH。

从行为上看，Android 13对手势导航下的底部横条（Indication Bar）控制比较特殊。即使使用navigationBars()去隐藏，在某些设备上也只是减少横条的背景范围，横线本身依然会以微弱透明度出现在屏幕底部。这是厂商在GesureNavigation上做的适配层导致的，app层往往无法完全消除。

2.2 为什么Android 13对“隐藏导航栏”更严格

很多朋友以为隐藏导航栏失败是代码写错了，其实很多时候是系统策略。Android 13开始，系统会强制保证“用户永远能通过一次滑动手势唤回导航栏”，意味着你调用了hide()之后，用户在底部上滑，导航栏必定重新出现。这个行为不受setSystemBarsBehavior影响，也不由你控制。

更深一层，Android 13的WindowInsets在计算时，会把“系统可能临时显示导航栏”的情况纳入布局。你即使隐藏了导航栏，insetsController返回的navigationBars区域也可能不是0，因为系统要为即将唤出的导航栏预留空间。这会导致一个经典问题：你隐藏导航栏后，底部Button栏依然多了一段padding，看起来像没隐藏成功。

针对这种情况，我一般会额外使用WindowInsets.Type.tappableElement()和WindowInsets.Type.displayCutout()来做精细控制，而不是只盯着navigationBars()。尤其是挖孔屏和刘海屏，cutout区域如果被当成系统栏处理，顶部高度会算错，状态栏透明后内容又被孔遮挡。

2.3 我选择哪种方案

我自己在Android 13项目里，通常不用老的WindowManager.LayoutParams.FLAG_FULLSCREEN，而是直接用WindowCompat.setDecorFitsSystemWindows(window, false)加WindowInsetsControllerCompat。这套组合的好处是：兼容性稳定，在Android 11、12、13上行为一致，并且能通过Listener实时监听Insets变化。

除非你说“只想隐藏导航栏，状态栏保留”，我才建议单独用navigationBars()去hide。但实际项目里，隐藏导航栏通常是和全屏一起出现的。我会把这两项封装在一个SystemBarController里，对外暴露enterFullscreen()和exitFullscreen()，内部处理所有Insets逻辑。这样页面调用起来只需要关心业务，不用关心系统层差异。

另外要提一下WindowCompat.getInsetsController(window, view)和window.decorView.windowInsetsController在Android 13上都能拿到WindowInsetsControllerCompat。如果你的项目用了AppCompat，建议优先用前者，因为它内部已经兼容了不同版本的差异，省得自己写if (Build.VERSION.SDK_INT >= 30)这种分支。

3. 核心实现：基于WindowInsets的沉浸模式与导航栏控制

3.1 基础代码结构

先给出一套可以直接用的基础代码。它实现了两个功能：全屏模式下状态栏和导航栏全部隐藏，内容延伸到底部；退出全屏后恢复系统默认样式。

class SystemBarController(private val window: Window) { private val controller: WindowInsetsControllerCompat by lazy { WindowCompat.getInsetsController(window, window.decorView) } fun enterFullscreen() { WindowCompat.setDecorFitsSystemWindows(window, false) controller.hide(WindowInsetsCompat.Type.systemBars()) controller.systemBarsBehavior = WindowInsetsControllerCompat.BEHAVIOR_SHOW_BARS_BY_SWIPE } fun exitFullscreen() { WindowCompat.setDecorFitsSystemWindows(window, true) controller.show(WindowInsetsCompat.Type.systemBars()) } fun setStatusBarColor(color: Int) { window.statusBarColor = color } fun setNavigationBarColor(color: Int) { window.navigationBarColor = color } }

我在项目里通常把setDecorFitsSystemWindows放在Activity.onCreate里先执行，然后根据页面状态决定是否调用enterFullscreen。这里有个细节：setDecorFitsSystemWindows(window, false)必须在setContentView之前调用，否则部分设备上布局已经按“适应系统栏”的模式测量过一次，后续切换会闪一下。

如果你只需要隐藏状态栏、保留导航栏，可以直接改成controller.hide(WindowInsetsCompat.Type.statusBars())。如果只需要隐藏导航栏，同理改成navigationBars()。这两个类型可以任意组合，也可以通过or运算组合，比如WindowInsetsCompat.Type.statusBars() or WindowInsetsCompat.Type.displayCutout()。

3.2 关键参数与计算过程

沉浸模式做完之后，最关键的就是padding计算。很多界面在切到全屏时，顶部和底部的布局需要动态调整，否则标题栏会被状态栏盖住，底部按钮会被导航栏顶起或遮住。

我在项目里统一用ViewCompat.setOnApplyWindowInsetsListener来处理：

ViewCompat.setOnApplyWindowInsetsListener(bottomActionBar) { view, insets -> val sysBars = insets.getInsets( WindowInsetsCompat.Type.systemBars() or WindowInsetsCompat.Type.displayCutout() ) val imeInsets = insets.getInsets(WindowInsetsCompat.Type.ime()) // 底部布局需要同时避开导航栏和输入法 view.updatePadding( left = sysBars.left, top = sysBars.top, right = sysBars.right, bottom = maxOf(sysBars.bottom, imeInsets.bottom) ) insets }

如果监听器返回的是insets，表示这个View已经处理过Insets，事件还会继续往父布局传；如果返回WindowInsetsCompat.CONSUMED，表示消费掉，后面父布局不再处理。这个选择很有讲究，如果你在根布局消费了，子布局的监听可能收不到。大多数时候我建议返回insets，让事件继续传递。

另一个容易被坑的点是：sysBars里包含的bottom，在手势导航和全屏隐藏导航栏后都是0，但导航栏实际区域仍然存在。这时你要是还在底部加了固定padding，反而会造成内容与导航栏之间多出空隙。解决办法是，在全屏状态下要单独存一个“系统栏未被隐藏时的真实高度”，比如在进入全屏前先读取一次，缓存起来。

3.3 手势边缘区域的注意事项

Android 13对手势导航的用户来说，屏幕左边缘和右边缘是返回手势的触发区。如果你的页面里存在左右滑动返回或者侧边抽屉，手势冲突会出现。特别是隐藏导航栏之后，系统手势触发区域不会变，你的自定义手势与系统手势会同时作用。

处理方式通常有两种：一是通过View.setSystemGestureExclusionRects，把某些区域排除在系统手势之外；二是通过WindowInsetsControllerCompat的setSystemGesturesEnabled，完全禁用系统手势边缘，但这样会让用户失去返回手势，一般不推荐。

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) { val exclusionRect = Rect(0, 0, view.width, view.height) view.rootView.setSystemGestureExclusionRects( listOf(android.graphics.Rect(0, 0, 200, 200)) ) }

这个代码会把距离屏幕左边缘200px的正方形区域从系统手势中“抠掉”。实际项目里，我不会全屏排除，只在有触摸交互的View上做局部排除。注意，Android 13对排除区域有一定限制，每个View的排除区域不能无限叠加，过多的排除区域会被系统忽略，所以最好只在必要View上设置。

还有一个细节：setSystemGestureExclusionRects只能在SDK >= Q的设备上使用，Android 13没问题，但如果你想兼容老设备，需要做版本判断。排除区域的坐标系是相对屏幕的，不是相对View的，所以我通常拿到View在屏幕上的绝对位置再计算Rect。

4. 常见问题与排查技巧实录

4.1 状态栏闪烁问题

全屏切换时状态栏出现“先隐藏，再重新显示”的闪烁，多半是setDecorFitsSystemWindows在多个时机被重复设置。我见过一种错误写法：在onResume和onWindowFocusChanged里都调用了enterFullscreen()，并且每次调用都执行setDecorFitsSystemWindows(window, false)，导致系统布局测量连续变更。

正确做法是把setDecorFitsSystemWindows放在onCreate里设置一次，然后只在需要切换全屏状态时调用hide()或show()。如果你的页面里存在多个Fragment，不要在Fragment的onResume里重复调用enterFullscreen，而是让Activity统一管理。

还有一种闪烁原因是：controller.hide()和controller.show()被连续调用。比如用户快速点击“全屏”和“退出全屏”按钮，操作没有节流，系统会把两个状态机指令交替执行。解决办法是加一层简单的状态判断，或者配合window.decorView.doOnPreDraw做过度动画控制。

4.2 导航栏重叠与布局错位

导航栏重叠是接入沉浸模式后最容易看见的问题。明明设置setDecorFitsSystemWindows(window, false)，页面的footer还是被导航栏遮住了。这是因为你没有给底部布局添加navigationBars的padding。

我在3.2节里用setOnApplyWindowInsetsListener，本质上就是在做这件事。但更隐蔽的问题是：有些页面不是由你直接控制padding，而是用了CoordinatorLayout、BottomSheet、RecyclerView这些系统控件，它们内部有自己的Insets处理逻辑。尤其BottomSheet在Android 13上默认会吸收navigationBars的Insets，导致你设置完updatePadding后又被覆盖。

我的经验是：根部布局用fitsSystemWindows，子布局手动控制padding，不要同时设置。比如底部按钮容器放在根部布局内，根部设置android:fitsSystemWindows="false"，然后只在按钮容器上设置setOnApplyWindowInsetsListener。这样不会出现双向传递的重复叠加。

如果页面顶部的标题栏需要避开状态栏，但状态栏背景又是透明，你需要在标题栏顶部加padding，同时确保标题栏背景色延伸到状态栏后面。这时候window.statusBarColor = Color.TRANSPARENT是必要的，否则状态栏会是系统色，而不是页面顶部的颜色。

4.3 Android 13上手势导航不生效

有朋友反馈，在Android 13上三键导航模式下隐藏导航栏有效，切到手势导航后，调用controller.hide(WindowInsetsCompat.Type.navigationBars())底部横线还是会显示。这其实是Android 13的预期表现。手势导航下，系统会保留那条“悬浮横条”作为导航指示，第三方应用很难完全隐藏。

如果你一定要隐藏这条横线，可以尝试把目标区域那条横线对应的View放到导航栏区域内，然后利用WindowInsets监听判断当前导航栏是否可见，再做视觉上的“压盖”。但我不推荐这个方案，因为用户在底部上滑时横线又会重新出现，而且界面会出现奇怪的遮挡效果。

更值得关注的是“导航栏区域被内容遮挡后点击事件失灵”的问题。当你隐藏导航栏后，内容延伸到了底部，但系统手势仍然在底部区域生效。如果底部是一个“发送消息”按钮，用户点击时很容易误触发“回到桌面”手势。这个问题第三方无法直接解决，只能在产品设计上避开底部极窄的触发区域，或者在按钮下方增加额外的安全区域。

4.4 底部弹窗键盘遮挡

弹窗、底部菜单、输入框在沉浸模式下被软键盘遮挡，是我排查最多的场景之一。WindowInsets.Type.ime()对应的是输入法区域，它和navigationBars()的bottom很容易产生叠加。在Android 13上，如果导航栏隐藏，IME弹出时系统会把IME的Insets上报为一个较大的bottom，如果你只处理navigationBars()，会漏掉输入法的区域。

我在项目里的通用处理是：底部所有需要避开键盘的View，用maxOf(sysBars.bottom, imeInsets.bottom)作为bottom padding。如果页面本身是滚动性质的（比如评论列表加输入框），建议使用WindowInsetsAnimationCompat来控制内容平移动画，这样键盘弹出时不会瞬间跳变。

有一个典型的误区：设置了android:windowSoftInputMode="adjustResize"之后，Activity根布局会随着键盘高度变化而resize，此时如果又用手动padding去加高度，就会出现双重偏移。正确做法是只保留adjustResize，然后在Insets监听里处理padding，不再额外修改尺寸。

4.5 状态栏背景异常变黑

Android 13的statusBarColor如果被设置成透明，部分设备上会出现状态栏背景变黑的问题，这通常和主题样式有关。Theme里如果用了windowDrawsSystemBarBackgrounds=false，应用就不会去绘制状态栏背景，系统会使用默认的黑色或者主题色兜底。

我推荐在Theme中显式声明：

<item name="android:windowDrawsSystemBarBackgrounds">true</item> <item name="android:statusBarColor">@android:color/transparent</item> <item name="android:navigationBarColor">@android:color/transparent</item>

如果你希望状态栏背景跟页面顶部颜色一致，就不要把statusBarColor写死为transparent，而是在运行时通过window.statusBarColor动态改变。这样既可以让状态栏透明后露出背景，也可以让状态栏变成一个纯净颜色，两种需求都能满足。

5. 状态栏导航栏控制方案的扩展思考

5.1 对华为、小米、OPPO等定制系统的适配差异

Android 13是开源系统，但国内主流厂商往往在系统界面上做二次定制。状态栏和导航栏的高度、回调时机、隐藏行为都可能与原生稍有不同。我发现的最典型差异是：某些定制ROM会默认开启“防误触”机制，即使你隐藏了导航栏，在屏幕底部仍然存在一个“热区”，碰一下就会唤出导航栏。

处理上，我无法改变ROM层策略，只能尽量在应用内把操作热区上移，或者提供退出全屏的明确入口。如果你发现代码在原生模拟器上正常，在真机上失效，优先怀疑厂商适配，不要盲目改代码。

另一个实际差异是导航栏高度。原生Android 13三键导航高度约48dp，而手势导航系统栏高度约24dp。但某些折叠屏和Pad设备，底部系统栏高度可能更大。所有涉及导航栏高度的dp值都必须动态读取，千万不要在dimens.xml里写死48dp。

5.2 后续扩展：动态区域划分配置

如果你接手的是一个对状态栏导航栏控制非常严格的项目，可以考虑做一个“动态区域配置”，把每个页面需要的系统栏行为抽象成注解或配置项，比如：

@RequiresSystemBar( statusBarMode = Mode.TRANSPARENT, navigationBarMode = Mode.FULLSCREEN_HIDE, behavior = Behavior.SWIPE_SHOW )

然后在BaseActivity里统一解析注解，将系统栏控制从页面代码中彻底剥离。这个方案适合页面多、需求杂、需要统一管理的项目。我实践下来，维护成本会下降不少，因为大部分页面只需要声明“我要什么模式”，而不需要背一整段Insets逻辑。

但要提醒的是：注解化配置很容易在Fragment场景下失效。因为Activity的生命周期控制的是整体窗口，而Fragment切换需要额外协调。如果你用了注解方案，最好在BaseActivity里维护一个Fragment当前系统栏模式的栈，切换时按栈顶模式还原。

5.3 无障碍与用户操作习惯的权衡

隐藏导航栏或状态栏，本质上降低了系统的可见性，对无障碍体验不友好。Android 13在无障碍模式下会自动阻止应用隐藏导航栏，即使你调用hide()，导航栏也会保持显示。正因为如此，我在项目中预留了一个开关，检测到系统无障碍服务开启或TalkBack运行时，自动跳过全屏逻辑。

实际测试中，这个开关能避免很多“用户返回不了、操作不了”的投诉。尤其是拍照、游戏、阅读器这类长时间全屏的页面，如果用户需要频繁操作系统UI，强制隐藏系统栏反而会带来负体验。产品上应该允许用户自定义是否自动隐藏，或者至少提供一个半透明的悬浮“退出全屏”按钮。

1. 直接隐藏状态栏和导航栏：用WindowInsetsControllerCompat的hide()方法，传入systemBars()类型。
2. 透明状态栏但保留导航栏：设置statusBarColor为透明，同时用setDecorFitsSystemWindows(window, false)让内容延伸，导航栏保留原状。
3. 获取高度做动态布局：通过ViewCompat.getRootWindowInsets读取statusBars()和navigationBars()的尺寸。
4. 处理输入法弹出：在监听器里把ime()类型与systemBars()合并计算padding。
5. 监听系统栏可见状态变化：使用WindowInsetsControllerCompat的addOnControllableInsetsChangedListener或isSystemBarVisible做UI联动。

最后分享一个我自己的习惯：所有系统栏控制逻辑，我都会放在独立的类里，不散落在Activity代码中。这样当厂商适配问题出现时，我只要打开SystemBarController这一个文件就能排查。而且类里面所有方法都尽量有明确的“行为注释”，标明“这是原生行为”还是“这是定制ROM适配”。这算不上多高级的技巧，但能让你在半年后回看代码时少掉一大把头发。