EN

Android Bottom Navigation 规范一:使用方法

字数统计: 1.6k阅读时长: 5 min
2016/04/05
loading

Android 官方在 2016 年 3 月更新了 Bottom navigation 设计规范,所谓设计规范就是告诉开发者和设计师要如何去设计和使用某一个组件。不过这次 Bottom navigation 的发布,让许多人大跌眼镜,毕竟 Bottom navigation 这样的组件,在之前的 MD 设计语言中可是只字未提,当时 Android 与 iOS 常见的导航布局也有差异:iOS 应用常用底部标签栏,Android 的旧指南则建议避免这种布局。这是设计建议的变迁,不是两个平台的能力限制,也不是所有 iOS 应用都必须使用底栏。

本文是 Android Bottom navigation 的第一篇文章,主要介绍 Bottom navigation 的使用,以及 Bottom navigation 小变迁。

版本说明(2026-10-13 核查):下文图片与 Do/Don’t 属于 Material Design 1(M1)的历史规范,不应整套用于今天的 Material 3(M3)。官方更新记录确认 Bottom navigation 于 2016 年 3 月加入。第 6 节补充当前组件、窗口适配和状态管理;设计语言版本不等于 Android 系统版本。

1 Android 之前的关于底栏的设计规范

Google 之前对于底栏的设计规范

2. 微信的改版

上上一次 Bottom navigation 在 Android 圈引起轩然大波还是微信的改版。原文把这段变化归到 5.2 版本;下面保留当时收集的两张界面图。图片能显示顶栏与底栏的差异,但不能单凭它们确认具体发布版本、测试范围或“迅速换回”的时间线。

测试改版的微信

改版后的微信

3 Google + 的改版

而上一次 Bottom navigation 在 Android 圈引起轩然大波的就是 Google Plus 的改版。Google 在 2015 年 11 月 17 日发布了新版介绍,下面是原文保留的历史界面:

Google + 的改版

反正打脸啪啪啪,不过规则是用来遵守的,你看微信没有遵守,活的比 Google + 好几百倍了。

4. Bottom navigation 设计规范

闲话说完了我们就来看看官方发布的 Bottom navigation 的设计规范,毕竟对于我们广大程序员来说,设计方面的能力还是没有专业的设计师强的,有一些规范我们做出来的东西不至于太难看。

4.1 Bottom navigation 使用

M1 的 Bottom navigation 主要面向移动端,为顶层目的地提供直接入口;较大显示区域可采用侧面导航。这里的 Navigation bar 是应用内组件,不是 Android 系统的返回/Home 按钮栏或手势导航区域。

The bottom navigation bar on mobile
Left navigation on a larger display, such as tablet or desktop

4.1.1 使用时机

Bottom navigation 的使用时机:

  • 三到五个同样重要的顶级功能界面
  • 需要经常直接访问的顶层目的地

“任意位置”不表示登录、编辑或全屏任务等所有页面都必须显示底栏;M1 本身也排除了邮件撰写这类专注于单个任务的界面。

[Do and Don’t] 1. 少于三个入口时先检查内容层级

M1 建议少于三个目的地时考虑 Tabs,并不是按数量机械替换。两个入口若是在同一内容范围中切换分类,Tabs 更合适;先判断它们是不是独立的顶层目的地。

Do.The bottom navigation bar exposes the three to five top-level destinations of an app.

Don't. If there are fewer than three destinations, consider using tabs instead.

[Do and Don’t] 2. 超出的入口另行组织,不横向滚动底栏

M1 页面一处写“超过六个目的地时提供其他入口”,另一处明确底栏最多五项;不要据此理解为六项也合规。超出五项时应重新分组,或用抽屉等其他入口承接,不把底栏变成横向滚动菜单。

Do. Views are fixed in a bottom navigation bar.

Don't.Avoid scrollable content in the bottom navigation bar.

[Do and Don’t] 3. 保持三到五个主要入口

过多入口会挤压点击目标,不只是看起来拥挤。下面保留 M1 的五项与六项对照图;它们的配色、标签显示方式不是当前 M3 的统一模板。

Do. Use up to five top-level destinations in a bottom navigation bar.

Don't. Avoid using more than five destinations in bottom navigation as tap targets will be situated too close to one another.

5. Bottom navigation 与 tabs

Bottom navigation 与 Tabs 可以共存,但应表达清楚的层级。例如底栏切换“首页、收藏、个人”,收藏页内部的 Tabs 再切换不同收藏类型;不要让两套控件竞争同一组页面,或让顶部分类悄悄改变底栏的目的地。

Tabs 用于组织相关内容,也能直接点击;滑动切页需要额外的 Pager 等实现,不是 Tab 控件天然提供的行为。是否支持滑动不是区分两者的唯一依据。可参考当前 Compose Tabs 文档。

6. 2026 年补充:实现时如何选择

  • 组件。 M3 的 NavigationBar / NavigationBarItem用于 Compose;View 项目可用 Material Components 的 BottomNavigationView。3–5 个同等重要、保持一致的顶层目的地仍是官方建议。不要混用 M2 与 M3 的导入或把库版本当作系统 API level。
  • 窗口。 按当前应用窗口判断,不按“平板/手机”或横竖屏名称写死。NavigationSuiteScaffold 来自 material3-adaptive-navigation-suite;它从 1.0.0-alpha07 起转入 Material3 1.3.0 系列版本线,1.3.0 于 2024-09-04 发布。发布记录可用于核对项目依赖。当前自适应指南所述默认策略在宽或高为 compact、或 tabletop 姿态时使用底栏,其余使用 rail;drawer 需要按信息架构定制,组件不会仅因设备是平板就自动切过去。
  • 导航状态。 控件显示选中项,不等于已管理页面返回栈。切换目的地时应让选中状态与实际导航一致,并决定是否恢复各自的浏览位置。Jetpack Navigation 2.4.0 起支持多返回栈保存与恢复;View 的相应 setupWithNavController() 集成与 Compose 中自行配置导航不是同一段接线。仅用 rememberSaveable 保存选中序号不能代替返回栈。

样式与交互的历史规则见本系列第二篇,阅读时同样区分 M1 旧图和现代组件。

关于我 && 博客

下面是个人的介绍和相关的链接,期望与同行的各位多多交流,三人行,则必有我师!

  1. 博主个人介绍 :里面有个人的微信和微信群链接。
  2. 本博客内容导航 :个人博客内容的一个导航。
  3. 个人整理和搜集的优秀博客文章 - Android 性能优化必知必会 :欢迎大家自荐和推荐 (微信私聊即可)
  4. Android性能优化知识星球:付费社群已于 2026 年停止运营,不再招收新成员;此处保留历史介绍。

一个人可以走的更快 , 一群人可以走的更远

微信扫一扫

CATALOG
  1. 1. 1 Android 之前的关于底栏的设计规范
  2. 2. 2. 微信的改版
  3. 3. 3 Google + 的改版
  4. 4. 4. Bottom navigation 设计规范
    1. 4.1. 4.1 Bottom navigation 使用
      1. 4.1.1. 4.1.1 使用时机
        1. 4.1.1.1. [Do and Don’t] 1. 少于三个入口时先检查内容层级
        2. 4.1.1.2. [Do and Don’t] 2. 超出的入口另行组织,不横向滚动底栏
        3. 4.1.1.3. [Do and Don’t] 3. 保持三到五个主要入口
  5. 5. 5. Bottom navigation 与 tabs
  6. 6. 6. 2026 年补充:实现时如何选择
  • 关于我 && 博客