☰
Android Activity 完全指南:单屏组件、生命周期与导航机制
2026/10/3 17:13:20 网站建设 项目流程
  • 文档
  • 教程
  • 知识库

【免费下载链接】developer-roadmap

Interactive roadmaps, guides and other educational content to help developers grow in their careers.

项目地址:https://gitcode.com/GitHub_Trending/de/developer-roadmap
点击查看免费下载

Activity 是 Android 应用中带有用户界面的单个屏幕,也是几乎所有 App 交互的起点。本文以 developer-roadmap 仓库的 Android 路线图 为骨架,系统讲解 Activity 的定义与职责、由操作系统托管的生命周期回调、任务与返回栈的导航机制,以及通过 Intent 启动 Activity 的显式/隐式两种方式,帮助你理解并正确处理这一核心组件,构建稳定可靠的应用。

读完本文,你将掌握:Activity 在 Android 四大组件中的定位、六大生命周期回调的执行时机与正确用法、多屏导航与返回栈行为、显式与隐式 Intent 的启动方式,以及 Fragment、Jetpack Navigation 等现代实践对 Activity 开发方式的演进。

Activity 是什么:Android 应用中的"单屏"

在 Android 的组件模型里,Activity 代表应用中一个带有用户界面的单个屏幕(single screen)。它是用户与 App 交互的基本单元——用户看到的登录页、列表页、详情页,通常都是一个 Activity。

Activity 的核心特征可以从三个方面理解:

  1. 一个 Activity 对应一个屏幕:每个 Activity 承载一套独立的界面与交互逻辑,可以独立启动、独立销毁;
  2. 应用由多个 Activity 组成:App 通常包含多个 Activity,用户在它们之间导航切换,形成完整的业务流程;
  3. 生命周期由操作系统管理:Activity 从创建到销毁要经历一系列由系统调度、开发者无法完全控制的状态变迁,正确处理这些状态是构建稳定应用的前提。

这也是 Android 路线图将 Activity 列为 Android 开发者必修基础的原因——它是理解整个应用架构的入口。

Activity 在应用组件体系中的位置

Android 应用并非只有 Activity 一种构建块。按照 App Components 文档的划分,四大核心组件各司其职,且每一种都有自己的生命周期,都由 Android 系统统一托管:

组件职责是否有界面
Activity呈现单个用户界面屏幕,承载交互有
Service在后台执行耗时任务(播放音乐、下载文件、处理数据),无用户界面无
Broadcast Receiver响应系统级或应用级广播事件无
Content Provider管理结构化数据的访问,跨应用共享数据无

Activity 是其中唯一"看得见摸得着"的交互组件:用户看到的界面、点击、滚动都发生在 Activity 的视图层级中。而 Service 用于处理用户不直接感知的后台任务(如播放音乐、下载文件),Content Provider 则用于跨应用共享数据(如系统通讯录、日历、媒体库都是通过内容提供者暴露数据的)。

理解这一分工很重要:不要把所有逻辑都塞进 Activity。界面展示交给 Activity,后台任务交给 Service,跨进程数据共享交给 Content Provider,这样每个组件的生命周期职责才清晰可控。

Activity 生命周期:状态与回调

Activity 生命周期是 Activity从创建到销毁经历的一组状态与回调集合。这是 Activity 机制中最关键的部分,也是 Activity LifeCycle 文档反复强调的重点。

六大核心回调

生命周期涉及的关键回调包括:

  • onCreate:Activity 首次创建时调用。在这里完成界面布局、初始化成员变量、绑定数据等一次性设置;
  • onStart:Activity 即将对用户可见时调用;
  • onResume:Activity 获得焦点、可以接收用户输入时调用,是应用与用户交互的主要状态;
  • onPause:Activity 部分可见、即将失去焦点时调用(例如有对话框弹出或新 Activity 启动);
  • onStop:Activity 完全不可见时调用;
  • onDestroy:Activity 被销毁前调用,用于释放资源。

为什么正确实现回调如此重要

生命周期回调的价值在于让应用优雅地应对系统随时可能触发的中断。最典型的场景是:

  • 电话呼入:来电界面会覆盖当前 Activity,触发 onPause → onStop,应用需要在这里保存未提交的用户输入、暂停动画或释放独占资源;
  • 屏幕旋转:配置变化默认会导致 Activity 销毁并重建,整个过程会走完 onPause → onStop → onDestroy,再重新走 onCreate → onStart → onResume,如果不在 onSaveInstanceState 等时机保存状态,旋转后用户填写的表单数据就会丢失;
  • 后台切换:用户按 Home 键切到其他应用,Activity 进入 stopped 状态但进程仍存活,需要确保资源占用合理、数据安全。

正确实现这些回调,能确保应用在处理电话呼入、屏幕旋转等中断时不会丢失数据、不会崩溃、不会出现资源泄漏。反过来说,如果开发者忽略生命周期处理,最常见的后果就是:界面状态在旋转后消失、后台任务在 Activity 销毁后仍在占用资源、内存泄漏导致应用被系统回收。

多 Activity 导航:任务与返回栈

一个应用通常包含多个 Activity,用户在它们之间前进、后退,形成完整的操作流。支撑这套导航行为的底层机制是任务(Task)与返回栈(Back Stack)。

按照 Tasks & Backstack 文档的说明:

  • 任务是用户为达成某个目标而交互的一组 Activity 的集合;
  • 返回栈记录这些 Activity 被打开的顺序;
  • 当用户按下返回键时,Activity按相反顺序从栈中弹出(后进先出)。

举例来说:用户从列表页 A 点击进入详情页 B,再进入编辑页 C,返回栈自底向上为 A → B → C。此时按返回键,先弹出 C 回到 B,再弹出 B 回到 A。栈空时返回键会退出应用(或回到上一个任务)。

理解任务与返回栈对构建可预测的导航流程至关重要:

  • 返回行为是否符合用户直觉(例如从详情页返回应回到列表页,而不是退出应用);
  • 使用launchMode(如 singleTop、singleTask)或 Intent flag(如 FLAG_ACTIVITY_NEW_TASK、FLAG_ACTIVITY_CLEAR_TOP)控制 Activity 在栈中的复用与清理行为;
  • 深链接(deep link)从外部直接打开栈内深处的页面时,返回路径如何构造。

用 Intent 启动 Activity

Activity 之间如何通信与跳转?答案是Intent(意图)。按照 Intent 文档的定义:

Intent 是 Android 中用于组件之间运行时晚期绑定(late runtime binding)的软件机制,可用于 Activity、Content Provider、Service 等组件。它本质上是一个被动的数据结构,保存着对某项操作的抽象描述,请求 Android 系统去执行。

Intent 本身不执行任何操作,它只是"描述要做的事",真正干活的是系统与目标组件。根据是否显式指定目标组件,Intent 分为两种:

显式 Intent(Explicit Intent)

显式 Intent 主要用于应用自身边界内部(同一 App 内的组件跳转)。它明确指定要响应该 Intent 的目标组件,调用方式包括:

  • setComponent(ComponentName)
  • setClass(Context, Class)
  • setClassName(String, String)

由于目标已写死,显式 Intent 不需要系统解析,直接交给 Intent 中指定的那个组件处理。典型用法就是在 App 内部启动某个 Activity、启动 Service、发送广播:

// 启动同一应用内的另一个 Activity Intent intent = new Intent(this, DetailActivity.class); startActivity(intent);

对应 Kotlin 写法为Intent(this, DetailActivity::class.java),本质同样是调用setClass语义指定目标组件。这部分内容在 Explicit Intents 文档中有详细说明。

隐式 Intent(Implicit Intent)

隐式 Intent 不显式指定目标组件,而是描述"想做什么",由系统去查找合适的组件来响应请求。系统会拿设备上所有已安装应用在AndroidManifest.xml中声明的<intent-filter>与该隐式 Intent 进行匹配,找到能够处理它的 Activity(或 Service、Receiver)。

典型场景是"打开一个网页""调用相机拍照""分享文本"等跨应用操作——你的 App 不需要知道谁来实现,系统会找到最合适的那个:

// 打开网页:不指定浏览器,由系统匹配安装了浏览器的应用 Intent intent = new Intent(Intent.ACTION_VIEW); intent.setData(Uri.parse("https://example.com")); startActivity(intent);

隐式 Intent 的核心价值在于解耦:发起方只声明意图(action、data、category),接收方通过清单文件声明自己能处理什么,双方无需互相认识。详细机制见 Implicit Intents 文档。

Manifest 注册与 Intent Filter

无论哪种组件,要能被系统识别都必须先在AndroidManifest.xml中声明。对于 Activity 而言,注册至少需要:

<application> <activity android:name=".MainActivity" /> <activity android:name=".DetailActivity"> <!-- intent-filter 声明该 Activity 能响应的隐式 Intent --> <intent-filter> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.DEFAULT" /> <data android:scheme="https" /> </intent-filter> </activity> </application>

其中Intent Filter 用于声明组件能接收哪些类型的 Intent。按照 Intent Filters 文档,它定义在AndroidManifest.xml中,描述组件支持的:

  • action:组件能执行的动作(如 ACTION_VIEW、ACTION_SEND);
  • data:组件能处理的 URI 类型与 MIME 类型;
  • category:组件的分类信息(如 DEFAULT、BROWSABLE)。

系统正是依靠这些 intent-filter 声明,来判断哪些 Activity 或 Service 能响应某个隐式 Intent。如果一个组件没有任何 intent-filter,它只能被显式 Intent 或同应用内的隐式调用启动;如果多个应用声明了能处理同一 Intent,系统会弹出"选择应用"对话框让用户决定(或由系统按默认偏好处理)。

现代实践:Fragment、Navigation Components 与 Compose

理解了 Activity 的基础机制后,还需要了解它在现代 Android 开发中的演进形态——这同样是路线图 Android 开发基础 之后的重要内容。

Fragment:可复用的界面片段

Fragment 代表应用中可复用的 UI 片段,它定义并管理自己的布局、拥有自己的生命周期、能处理自己的输入事件。关键约束是:

Fragment 不能独立存在,必须由 Activity 或其他 Fragment 托管;Fragment 的视图层级会作为(或挂载到)宿主视图层级的一部分。

Fragment 让一个 Activity 可以在不同屏幕尺寸下复用界面模块(例如手机上一屏显示一个 Fragment,平板上同一 Activity 并排显示两个 Fragment)。不过 Fragment 也有自己的生命周期,与宿主的生命周期需要联动处理。详见 Fragments 文档。

Jetpack Navigation Components:导航的标准化

Navigation Components 是 Android Jetpack 的一部分,用于简化应用内导航的实现。按照 Navigation Components 文档,它帮助你遵循最佳实践、处理深链接、在深层与条件导航中提供一致的体验,并自动处理许多常见任务(如在不同设备上正确处理 Up 与 Back 行为)。

它由三个关键部分组成:

  • Navigation graph:以 XML 资源描述导航关系图(哪些目的地、如何跳转);
  • NavHost:承载导航内容的容器(通常就是宿主 Activity 里的一个 Fragment 容器);
  • NavController:在 NavHost 中管理目的地之间的跳转与状态。

在实际项目中,常见组合是:一个 MainActivity 作为 NavHost 容器,内部用多个 Fragment 作为导航目的地,由 NavController 管理跳转。此时 Activity 的"单屏"职责被进一步抽象——它更多是容纳导航的宿主,具体界面由 Fragment 呈现。

Jetpack Compose 与 Activity

如果使用 Jetpack Compose(声明式 UI 方案,路线图中也有对应的 jetpack-compose 专题),Activity 依然存在,但职责更纯粹:在onCreate中调用setContent挂载 Compose 界面树,屏幕内容由 Composable 函数描述,导航由 Compose Navigation 处理。无论技术栈如何演进,Activity 作为界面宿主的地位、生命周期机制和启动方式这些基础概念都不会过时。

学习与实践建议

如果你刚开始接触 Activity,建议按以下路径推进(与 Android 路线图 的编排一致):

  1. 打好基础:掌握 Kotlin/Java 基础、面向对象 与 Gradle 构建;
  2. 动手写第一个 App:参考 Create a Basic Hello World App,在 Android Studio 中新建项目、编写一个简单 Activity、在模拟器或真机上运行,理解项目结构、构建流程与 UI 和代码的连接方式;
  3. 吃透生命周期:亲手在六个回调中打日志,观察打电话、旋转屏幕、按 Home 键时回调的触发顺序;
  4. 理解导航:用显式 Intent 做多屏跳转,再对照 Tasks & Backstack 验证返回行为;
  5. 再引入 Fragment 与 Navigation Components,最后过渡到 Compose 或 MVVM 等架构模式。

小结

Activity 是 Android 应用最基础的交互单元:一个屏幕、一套界面、一个由操作系统托管的生命周期。本文围绕 developer-roadmap 的 Android 路线图 梳理了它的完整知识链条——从组件定位(Activity、Service、Broadcast Receiver、Content Provider 四大组件)、六大生命周期回调的正确处理,到任务与返回栈的导航机制、显式/隐式 Intent 的启动方式与 Manifest 中的 intent-filter 声明,再到 Fragment 与 Navigation Components 的现代实践。

把握住"生命周期由系统管理、正确回调避免数据丢失、Intent 是组件间通信的抽象描述"这三条主线,你就能搭建出稳定、可预测、经得起系统中断考验的 Android 应用,并顺畅地进入 Fragment、Compose、架构模式等后续学习阶段。

  • 文档
  • 教程
  • 知识库

【免费下载链接】developer-roadmap

Interactive roadmaps, guides and other educational content to help developers grow in their careers.

项目地址:https://gitcode.com/GitHub_Trending/de/developer-roadmap
点击查看免费下载

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询