导航 Original Version

[

开发者文档

Implementing Effective Navigation

](http://developer.android.com/training/implementing-navigation/index.html)
导航是用户体验中至关重要的一环，没有什么比不一致或者错误的导航更加困扰用户的了。Android 3.0 对系统的全局导航行为做出了较大的改变。根据向上 (Up) 和返回 (Back) 的设计原则，仔细考虑你的应用程序行为，使得你的应用可以做出准确一致的导航。

Android 2.3 以及更早版本的系统使用设备上的返回键在应用内导航。Android 3.0 引入了操作栏之后，第二种导航方式就出现了: 向上按钮，它由应用图标和向左的箭头组成。

向上 vs. 返回

“向上”按钮用来在应用内，根据应用的逻辑层级进行导航。举例来说，屏幕 A 显示了一个条目列表，点击其中一个条目到达屏幕 B (显示该条目的详细信息)，那么屏幕 B 应当提供一个“向上”按钮，让用户可以回到屏幕 A。

如果某个屏幕已经是该应用的顶层了 (例如，应用的主页)，那不需要“向上”按钮。

系统的“返回”键则用于按照切换历史返回到之前的屏幕。这种导航基于当前的状态，而不是基于应用的逻辑层级。

如果之前的屏幕就是逻辑层次的上一层，那么“返回”和“向上”的行为是一样的。不过和“向上”不同的是，“返回”可能回到“主屏幕”或者其他的应用，“向上”回到的屏幕总是在你的应用中。

除了屏幕之间的导航，“返回”键还支持一些其他导航行为:

• “返回”键可以关闭弹出窗口 (对话框或者弹出信息)
• “返回”键可以关闭上下文操作栏，还可以清除当前的选择
• “返回”键可以关闭屏幕键盘 (IME)

应用内的导航

导航到有多个入口的屏幕

有时，某个屏幕在应用的逻辑结构中的位置并不固定，可以从多个的方进入该屏幕，例如设置页面就可以从应用中的任何位置进入。这种情况下，“向上”按钮会回到之前的屏幕，行为和“返回”完全一致。

在屏幕中切换试图

同一屏幕中的视图切换不会影响“向上”和“返回”按钮的行为，因为视图的切换不会影响当前屏幕在你应用中的位置，也不会影响屏幕的导航历史。

例如:

• 通过标签或者左右滑动切换视图
• 使用下拉菜单切换视图
• 过滤列表
• 对列表进行排序
• 调整显示特性 (例如缩放)

在同级屏幕之间导航

如果你的应用可以从一个列表进入其中某个条目的详细信息页面，那么应当考虑提供在相邻条目的详细信息页面之间的直接导航。例如在 Gmail 应用中，通过左右滑动邮件对话视图，可以在相同收件箱的上一条和下一条邮件对话之间导航。由于是在同一个屏幕中变换视图，所以这样的操作不会影响“向上”和“返回”的行为。

但是要注意到，浏览“相关”但不相邻的详细信息时，“向上”和“返回”的行为会发生变化。例如，在 Play 商店中浏览同一开发者的其他应用或者同一位歌手的不同专辑。这样的操作会导致屏幕历史发生变化，那么“返回”按钮就会回到上一个浏览的条目，而不是条目列表。“向上”按钮则仍然会回到条目列表。

你还可以使“向上”的行为根据当前的页面内容变化，使它更加聪明 (译者: 更加复杂了-_-)。我们扩展一下之前 Play 商店的例子，如果用户从一本图书的详细信息页面跳转到某部电影。这时“向上”应当返回到电影列表而不是之前的图书列表。

从主屏幕或者通知进入你的应用

你可以通过主屏幕或者通知让你的用户直接进入应用的深层次屏幕。例如 Gmail 的收件箱小部件和新消息通知都可以跳过收件箱，直接进入会话视图。

这两种情况下，都按照下面的指导处理“向上”:

• 如果目标屏幕一般都通过应用的某个特定屏幕进入，那么“向上”应当返回那个屏幕。
• 其他情况下，向上都应当返回顶层屏幕，比如应用的首页。
  对于“返回”按钮，你应当在任务栈中插入一些屏幕，使导航行为更合理，可以通过“返回”一直回到应用的主屏幕。这样可以使用户在退出应用前可以返回到应用的主屏幕。

例如，Gmail 的窗口小部件提供了一个按钮可以直接进入撰写屏幕。“向上”和“返回”都会先让用户回到收件箱，“返回”还可以一直回到主屏幕。

间接通知

当你的应用需要同时通知多条信息时，可以通过单条通知将用户带入一个列表屏幕。这个屏幕列出所有的事件，并且可以让用户直接进入应用。这种通知叫做间接通知。

不同于标准的 (直接) 通知，在间接通知的列表屏幕按“返回”键将回到开启通知之前的屏幕。一旦用户触摸通知进入应用后，“向上”和“返回”的行为应当和之前的指导一样: 在应用中导航，而不是跳回到之前的屏幕。

例如，用户在 Gmail 应用中收到了日历应用的间接通知。通过通知进入列表屏幕后，触摸“返回”将回到 Gmail 应用。如果用户触摸了某条事件，从而进入了日历应用的详细信息屏幕，此时“向上”和“返回”都会回到日历应用的顶层视图。

弹出通知

弹出通知跳过通知抽屉，直接将通知呈现在用户面前。不要滥用这种通知，除非用户必须立刻对信息做出响应时，才使用弹出通知。例如，Hangouts 应用使用弹出通知告知用户有来自朋友的视频聊天邀请，如果不做出响应的话，邀请将会很快失效。

弹出通知的导航行为和间接通知比较接近。“返回”可以关闭当前的弹出邀请。如果用户从弹出通知进入了应用，“向上”和“返回”都应当按照之前的指导，在应用中导航。

应用间的导航

Android 系统一个基础的优势就在于应用之间有能力互相调用，用户可以直接从一个应用进入另一个应用。例如，一个应用需要捕捉照片时，将会进入相机应用，相机应用再将拍摄的照片返回给该应用。这样既可以避免开发者的重复劳动，也能保证用户体验的一致性。

为了理解应用间的导航，必须了解一下 Android 的框架体系。

Activity, Task 和 Intent

Android 系统中，activity 这个应用组件定义了一个包含信息和用户能够执行的所有相关操作的屏幕。你的应用就是一些 activity 的集合，包括了你编写的 activity 和从其他应用中复用的 activity。

Task 用于表示用户完成一个任务需要执行的 activity 队列。一个 task 可以只使用来自同一个应用的 activity，或者也可以使用来自不同应用的 activity。

Intent 作为一种机制，表示一个应用希望其他应用帮助它完成一个操作。应用中的 activity 可以向系统告知自己可以响应哪些 intent。例如比较常见的 intent “分享”，用户安装的许多应用可能都可以响应这个 intent 完成操作。

例子: 在支持分享的应用之间导航

为了了解 activity, task 和 intent 如何一起工作，我们来观察一个应用如何通过其他应用分享内容。例如，从主屏幕启动 Play 商店应用后，将会开始一个新的 Task A (如下图所示)。在 Play 商店中浏览并进入了一本图书的详细信息屏幕后，用户仍然处于同一个 task 之中，只是通过 activity 扩展了它。触摸分享，将会弹出一个列表，显示了其他应用注册的可以响应 Share intent 的 activity。

当用户选择通过 Gmail 分享后，Gmail 的撰写 activity 将会被加入 Task A，此时仍然没有创建新的 task。如果 Gmail 此时在后台已经有 task 在运行的话，将没有任何影响。

在撰写 activity 中，发送消息或者触摸“返回”后，用户将回到图书详细信息 activity 中。如果一直触摸“返回”，将在 Play 商店中导航，直至返回主屏幕。

不过，如果在撰写 activity 触摸了“向上”，那么表示用户想留在 Gmail 应用中。此时将会显示 Gmail 的会话列表，同时启动一个新的 Task B。新的 Task 的顶层总是主屏幕，所以在会话列表一直触摸“返回”将会回到主屏幕，而不会回到 Play 商店。

Task A 将被保持在后台，用户可能待会儿还会回到 Play 应用商店。如果 Gmail 已经有个在后台运行的 task 的话，那么会被 Task B 取代，以保持新的用户操作状态。

当你的应用注册了响应某些 intent，并且直接进入应用的深层次 activity，请参考上面的“从主屏幕或者通知进入你的应用”，处理“向上”导航。