来源：http://developer.android.com/intl/zh-cn/design/patterns/navigation.html
统一、连贯的导航是整体用户体验的重要一环。大概没有什么比不一致不连贯的导航更能给用户带来麻烦的了。Android3.0针对全局导航引入了重要的更新。严格按照返回和向上的引导逻辑会使应用对你的用户来说更加自然和可靠。
Android 2.3和以前的系统，依靠系统的返回按钮在应用内提供导航。随着Actionbar在Android 3.0中的引入，第二种导航机制也被加入到系统中：向上按钮——由应用图标和向左箭头组成。
向上 vs. 返回
向上按钮用来在App中基于界面的层级关系导航。举个栗子，如果界面A显示了一个条目列表，选择一个条目将打开屏幕B（展示条目的详情），那么界面B需要提供一个返回界面A的向上按钮。
如果一个界面是应用的顶级页面（也就是主页），那么它不应该展示向上按钮。
系统的返回按钮用来在用户看到的一系列界面中，按照时间顺序向前导航（从新到旧）。通常是基于界面之间暂时的关系，而不是应用的层级结构。
如果前一个看到的界面，也是当前界面的父级页面，点击返回按钮和点击向上按钮有同样的效果——这是通常的情况。然而， 和向上按钮可以保证用户在应用内导航不同的是，返回按钮可以让用户返回到主页或者别的App。
返回按钮还提供一些和页面导航没有直接联系的操作。
- 关闭浮动窗口（对话框，弹出框）
- 关闭上下文ActionBar并且移除选中项目的高亮效果
- 隐藏输入法键盘
应用内导航
导航到有多个入口的界面
有的界面并不是在App层级上有一个着直接的入口，而是可以在多个地方进入——比如从任意界面都可以进入的设置界面。这种情况下，向上按钮应该返回指定的页面，行为和返回按钮保持一致。
在页面内改变视图
改变屏幕的视图选项并不改变向上和返回的行为：界面仍然在相同的应用层级中显示，不会创建新的导航历史。
试图改变的例子有：
- 使用标签或者左右滑动切换视图
- 使用下拉菜单切换视图（或者可展开标签）
- 筛选列表
- 排序列表
- 改变显示状态（比如缩放）
- 在同级页面之间导航
当你的App提供列表到多个详情页面的导航时，提供连续item之间的切换方式通常是有必要的。例如，在Gmail中，可以方便地通过左右滑动来查看同一个收件箱中的前一个、后一个会话。就像在页面内更改视图状态时一样，这类导航不改变向上和返回的行为。
然而，有一种值得关注的例外情况，多个关联的页面不在同一个列表中组织——比如，当在Play商店中浏览同一个开发者的App，或者同一个艺术家的专辑时。这种情况下，随着打开链接回创建浏览历史，导致返回按钮会沿着之前的路径一步步返回。向上按钮则应该绕过这些相关页面，直接返回最后浏览的概览页面（Container Screen）。
通过详情页面的信息，你可以让向上按钮的行为更加智能。拓展一下上面的Play商店的例子，想想一下用户从图书导航到了相关的电影详情页面。这种情况下，向上按钮可以导航到用户不曾去过的页面（电影概览页面）。
从启动器插件和通知栏导航到你的App
你可以使用桌面插件或者通知让用户直接进入层级更深的页面。例如，Gmail的收件箱插件和新邮件通知都可以跳过收件箱收件箱首页，直接把用户带入会话页面。
对于上面两种情况，按照如下方式响应向上按钮：
- 如果正常情况下目标页面总是从一个特定页面导航进入的，向上按钮应该返回到那个特定页面。
否则，向上按钮应该返回应用的顶级页面（比如首页）。 - 对于返回按钮，你应该在任务返回栈中插入直到顶级页面的所有上级页面，以便让导航更加自然。这样处理会允许那些忘记自己是如何进入到应用的用户可以在页面不存在的情况下依然可以返回到顶级页面。
间接通知
当你的应用需要同时展示多个任务的信息时，可以使用一个简单的通知来引导用户到一个独立的页面。这个页面汇总这些任务，并且为用户提供深入应用内部的路径。这种类型的通知被称作间接通知（indirect notification）。
和标准通知（直接）不同，在间接通知打开的独立页面中按下返回按钮，将带用户返回到通知的触发页面（kyleduo: 触发任务的页面）——不会在回退栈中插入页面。一旦用户从独立页面进入应用，向上和返回的行为就像在处理标准通知一样，上面提到的，在应用内导航，而不是在返回到独立页面。
例如，假设一个用户在Gmail中收到了一个来自日历应用的间接通知。点击通知打开了展示多个事件的间接页面。从间接页面中点击返回按钮带用户返回到Gmail应用。在间接页面中点击一个事件将把用户带离间接页面并进入完整的日历应用来展示事件细节。在事件详情页面中，向上和返回按钮将导航到日历应用的顶级页面。
弹出式通知
弹出式通知脱离通知栏，直接展示到用户面前。它们用的不多，而且应该仅在急需及时响应并且有必要打断用户的上下文操作时才谨慎使用。例如，Talk应用使用这种形式来向用户提示视频通话邀请，邀请会在几秒后自动清除。
按照导航的行为约定，弹出通知和间接通知的间接页面有同样的处理方式。返回键关闭弹出式通知。如果用户通过导航页面进入到了通知的应用，向上和返回按钮按照直接通知一样在应用内导航。
应用间导航
Android系统的一个基础优势就是应用可以激活其他应用，给用户直接从一个应用导航到另一个的能力。例如，一个需要拍照的应用可以激活相机应用，相机应用会将照片返回给相关应用。这对开发者和用户而言都是极大的便利，开发者可以轻松的利用其他应用的代码，对用户来说，他们可以在完成相同任务时享受一致的体验。
在理解应用间导航之前，了解下面要说的Android框架行为是很重要的。
Activities，tasks和intents
在Android中，Activity是定义页面信息和用户相关操作的应用组件。你的应用是一个Activity的集合，包括你自己创建的Activity和你利用的其他应用的Activity。
Task是用户为了完成某个目标打开的一系列Activity。一个Task可以仅仅利用一个应用里的Activity或者利用多个应用里的Activity。
Intent是为了让一个应用它在需要其他应用协助完成工作时发出信号的机制。应用的Activity能声明他们可以响应的intent。通常，例如“分享”的intent，用户应该有很多的应用可以响应这个请求。
实例：在应用间导航来支持分享
为了理解Activity，Task和Intent是如何协同工作的，考虑一个允许用户通过其他应用分享的应用。举个例子，从启动器启动Play商店新建了一个Task A。在进入了一个推荐书籍的详情页面之后，用户在同一个Task内，通过新增Activity扩展了Task。触发分享动作后弹出了一个对话框，列出注册了可以处理分享动作的其他应用。
当用户选择Gmail进行分享时，Gmail的编辑Activity被加入到Task A中——没有新建Task。如果Gmail还有自己的Task在后台运行，不会对其有影响。
从编辑页面发送分享信息或者按返回键将会返回书籍详情页面。随后继续按下返回键会返回Play商店并在应用内返回，直到返回启动器。
然而，点击编辑页面的向上按钮，用户表明了停留在Gmail中的意愿。所以会显示Gmail的会话列表页面，并且一个新的Task B随之被创建。新的Task总是以主界面作为Task的根，所以这个时候按返回键的话会回到主界面。
Task A在后台被保留，用户可能在随后返回（比如通过最近使用的应用列表）。如果Gmail已经有了一个后台Task，这个后台Task会被Task B替换——先前的上下文为了用户的新目标被丢弃了。
如果你的应用声明了使用Activity响应其他应用的Intent，参考 从启动器插件和通知栏导航到你的App 来提供向上导航。